blairell

ok, so im not saying its impossible to keep things object oriented but i dont know java or how to use max's scripting abilities. they also start to look quite ugly when i see patches that do use them.

as im starting to want to keep everything more object oriented, and being able to have functions which dynamicly create and delete instances of objects im finding max msp is starting to hurt.

i realise max msp is concept driven, but its not very object oriented firendly and im thing of ditching it and moving over to supercollider.

for those of you that do use supercollider, what would you think about this decision? what are the pros and cons? would i really mis max that much? max's object oriented limitations are wanting me to ditch it.

ok, so im not saying its impossible to keep things object oriented but i dont know java or how to use max's scripting abilities.  they also start to look quite ugly when i see patches that do use them.

for those of you that do use supercollider, what would you think about this decision?  what are the pros and cons?  would i really mis max that much?  max's object oriented limitations are wanting me to ditch it.


object-orientation-max-isnt-good-at-it

you should take a look at the object oriented programming with max 

On Jan 3, 2008, at 3:14 AM, blairell wrote:

> ok, so im not saying its impossible to keep things object oriented 

> but i dont know java or how to use max's scripting abilities. they 

> also start to look quite ugly when i see patches that do use them.

> as im starting to want to keep everything more object oriented, and 

> being able to have functions which dynamicly create and delete 

> instances of objects im finding max msp is starting to hurt.

> i realise max msp is concept driven, but its not very object 

> oriented firendly and im thing of ditching it and moving over to 

> for those of you that do use supercollider, what would you think 

> about this decision? what are the pros and cons? would i really 

> mis max that much? max's object oriented limitations are wanting me 

you should take a look at the object oriented programming with max  
thread. :)

>
> ok, so im not saying its impossible to keep things object oriented  
> but i dont know java or how to use max's scripting abilities.  they  
> also start to look quite ugly when i see patches that do use them.
>
> as im starting to want to keep everything more object oriented, and  
> being able to have functions which dynamicly create and delete  
> instances of objects im finding max msp is starting to hurt.
>
> i realise max msp is concept driven, but its not very object  
> oriented firendly and im thing of ditching it and moving over to  
> supercollider.
>
> for those of you that do use supercollider, what would you think  
> about this decision?  what are the pros and cons?  would i really  
> mis max that much?  max's object oriented limitations are wanting me  
> to ditch it.


I've read a few, dont know which one you are refereing to. is this the one your refering to?

https://cycling74.com/forums/index.php?t=msg&goto=78726&rid=5199&S=4c031bf5012d8ceee51c4ed70d5af242&srch=object+oriented+programming+with+max#msg_78726

I know some of the tricks like using #0,#1,#2 etc and using instantiated patchers. but this isn't ideal for all situations.

lets say i have a sequencer, and i have a patch for each track. what if i want another track? and i want that instance created upon the execution of some other function like "new track"? then i start getting into ugly code that doesn't become readable anymore.

max just doesn't seem to be inherently made with nice looking logical, understandable object orientation in mind.

im keen to know what people think of supercollider if anyone here is using it.

I've read a few, dont know which one you are refereing to. is this the one your refering to?
https://cycling74.com/forums/index.php?t=msg&goto=78726&rid=5199&S=4c031bf5012d8ceee51c4ed70d5af242&srch=object+oriented+programming+with+max#msg_78726

I know some of the tricks like using #0,#1,#2 etc and using instantiated patchers.  but this isn't ideal for all situations.  

lets say i have a sequencer, and i have a patch for each track.  what if i want another track? and i want that instance created upon the execution of some other function like "new track"?  then i start getting into ugly code that doesn't become readable anymore.

im keen to know what people think of supercollider if anyone here is using it.


https://cycling74.com/forums/index.php?t=msg&th=25272&start=0&rid=0&S=6bc17f0fd0e897fcb6a32801e8ab41ed

JohnPitCairn and Mattijs are building something that will be useful to a good few Max users who want to use OO-style programming. Interesting to see how it develops, but I hope something like this will be integrated into a new version of Max.

Quote: Bas van der Graaff wrote on Thu, 03 January 2008 13:22

----------------------------------------------------

> JohnPitCairn and Mattijs are building something that will be useful to a good few Max users who want to use OO-style programming. Interesting to see how it develops, but I hope something like this will be integrated into a new version of Max.

We're currently testing our oo externals with a select group of max users that have experience with object-oriented programming. If you're interested I could email you the current version of our objects, the help patch and a proof of concept patch.

Quote: Bas van der Graaff wrote on Thu, 03 January 2008 13:22
----------------------------------------------------
> JohnPitCairn and Mattijs are building something that will be useful to a good few Max users who want to use OO-style programming. Interesting to see how it develops, but I hope something like this will be integrated into a new version of Max.
----------------------------------------------------

I have recently switched from Max to SuperCollider. I don't see too many cons to be honest.

- NO copy protection, use it however you want on as many machines as you want.

- Cross-platform - it runs well on Linux as well as OSX and Windows.

- For small tasks I think it is quicker to use Max.

- Currently you can not load VSTs or AUs in SC. Not a problem on Linux or OSX where you can just use JACK anyway, but it is an issue on Windows.

I'm sure there are lots more of both that could be mentioned.

I have recently switched from Max to SuperCollider. I don't see too many cons to be honest. 

Obvious Pros:
- NO copy protection, use it however you want on as many machines as you want.
- Open source.
- Built with OO programming in mind.
- Scales well, unlike Max I think.
- Cross-platform - it runs well on Linux as well as OSX and Windows.

Cons:
- For small tasks I think it is quicker to use Max.
- Currently you can not load VSTs or AUs in SC. Not a problem on Linux or OSX where you can just use JACK anyway, but it is an issue on Windows.

I don't know much about Supercollider, but from what i've seen from it, it's much like C#. This would mean developing takes more time, bugs are more easily found and systems tend to be more robust.

However, max is very good at prototyping, which is where i find others lack. It takes zero time to set something up, and the library of audio, video & gl objects lets you use media faster than anywhere else. Only when your projects get bigger, max patchers need more planning, documentation and cleaning up and the advantage is kinda lost.

But i don't want to change this into a tool discussion, there's better places for that. OO, or even functions with returns would certainly be an addon...

Let me just say, that ive been testing these objects, and once they 

are up to full running speed they will be nothing short of legendary. 

My max patching has been somewhat re-invigorated, to the point where 

ive almost all but forgotten about Quartz Composer. That says a lot 

Ive been prototyping some things with them and it REALLY makes working 

with Max a Joy (again)- the best of patching/prototyping but now OO 

methods and calls, that you can define and use, with namespaces. Now 

if we could only find that elusive "jit.gl.texture - error unbinding 

Mad Props to Mattijs and John. :) Im stoked.

On Jan 3, 2008, at 7:42 AM, Mattijs Kneppers wrote:

> Quote: Bas van der Graaff wrote on Thu, 03 January 2008 13:22

> ----------------------------------------------------

>> JohnPitCairn and Mattijs are building something that will be useful 

>> to a good few Max users who want to use OO-style programming. 

>> Interesting to see how it develops, but I hope something like this 

>> will be integrated into a new version of Max.

> We're currently testing our oo externals with a select group of max 

> users that have experience with object-oriented programming. If 

> you're interested I could email you the current version of our 

> objects, the help patch and a proof of concept patch.

> Hard- and software for interactive audiovisual sampling

Let me just say, that ive been testing these objects, and once they  
are up to full running speed they will be nothing short of legendary.  
My max patching has been somewhat re-invigorated, to the point where  
ive almost all but forgotten about Quartz Composer. That says a lot  
for a jaded power user like me.

Ive been prototyping some things with them and it REALLY makes working  
with Max a Joy (again)- the best of patching/prototyping but now OO  
methods and calls, that you can define and use, with namespaces. Now  
if we could only find that elusive "jit.gl.texture - error unbinding  
texture" bug ;)

>
> Quote: Bas van der Graaff wrote on Thu, 03 January 2008 13:22
> ----------------------------------------------------
>> JohnPitCairn and Mattijs are building something that will be useful  
>> to a good few Max users who want to use OO-style programming.  
>> Interesting to see how it develops, but I hope something like this  
>> will be integrated into a new version of Max.
> ----------------------------------------------------
>
> Hi blairell,
>
> We're currently testing our oo externals with a select group of max  
> users that have experience with object-oriented programming. If  
> you're interested I could email you the current version of our  
> objects, the help patch and a proof of concept patch.
>
> Mattijs
> --
> SmadSteck - http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling


> lets say i have a sequencer, and i have a patch for each track. what

> if i want another track? and i want that instance created upon the

> execution of some other function like "new track"? then i start

> getting into ugly code that doesn't become readable anymore.

This specific scenario is not really a problem in Max, I would do it 

(and have done it) with scripting bpatchers, and it wouldn't be ugly...

But the question if SuperCollider would fit your needs better is much 

more a question of taste, if you prefer "lines of codes" thinking more 

than the visual data flow model, Supercollider is for you, if its the 

data flow, you just have to dig a bit deeper into Max. You won't learn 

blairell schrieb:
> lets say i have a sequencer, and i have a patch for each track.  what
> if i want another track? and i want that instance created upon the
> execution of some other function like "new track"?  then i start
> getting into ugly code that doesn't become readable anymore.

This specific scenario is not really a problem in Max, I would do it 
(and have done it) with scripting bpatchers, and it wouldn't be ugly...
But the question if SuperCollider would fit your needs better is much 
more a question of taste, if you prefer "lines of codes" thinking more 
than the visual data flow model, Supercollider is for you, if its the 
data flow, you just have to dig a bit deeper into Max. You won't learn 
this within some months...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


> Ive been prototyping some things with them and it REALLY makes working

> with Max a Joy (again)- the best of patching/prototyping but now OO

> methods and calls, that you can define and use, with namespaces. Now

> if we could only find that elusive "jit.gl.texture - error unbinding

I'm sure your patch is massive :) but if you could possibly find a

way to post an as reduced as possible while still exhibiting the error

> Ive been prototyping some things with them and it REALLY makes working
> with Max a Joy (again)- the best of patching/prototyping but now OO
> methods and calls, that you can define and use, with namespaces. Now
> if we could only find that elusive "jit.gl.texture - error unbinding
> texture" bug ;)

I'm sure your patch is massive :)  but if you could possibly find a
way to post an as reduced as possible while still exhibiting the error
patch, it'd be appreciated.

Not an issue. Its pretty straightforward. You can use poly to manage 

the basic logic for a sequencer track, make a new 'voice', and 

abstract out your UI away from your poly~ internals in a way that is 

easy to script and manage multiple instances of.

One of the things it took me a while to fully grok is separating ones 

UI from programmatic-al underpinnings. LITERALLY separate. You can do 

various workarounds without scripting such as having say

a set of buttons/number box detailing WHICH INSTANCE or TRACK NUMBER 

you are editing. Your ONE SINGLE UI SET then updates to reflect the 

state of that instance number within the poly.

or you could do this with multiple tracks, say you have enough screen 

real-estate for 5 trakc UI's, but you want to have 'n' tracks in your 

patch. Do the above, but when you 'scroll' down to the 10th track, the 

banks simply display 5 - 10, you dont NEED 'n' UI elements. Thats bad 

programming, bloated overhead, and poorly optimized. Plus it makes it 

This sort of UI design is where Javascript SHINES - scripting a la 

thispatcher, but with procedural coding principles.

ive just redone my custom GUI objects with javascript, and my module 

loading system as well. it makes life much better.

On Jan 3, 2008, at 12:00 PM, Stefan Tiedje wrote:

>> lets say i have a sequencer, and i have a patch for each track. what

>> if i want another track? and i want that instance created upon the

>> execution of some other function like "new track"? then i start

>> getting into ugly code that doesn't become readable anymore.

> This specific scenario is not really a problem in Max, I would do it 

> (and have done it) with scripting bpatchers, and it wouldn't be 

> But the question if SuperCollider would fit your needs better is 

> much more a question of taste, if you prefer "lines of codes" 

> thinking more than the visual data flow model, Supercollider is for 

> you, if its the data flow, you just have to dig a bit deeper into 

> Max. You won't learn this within some months...

Not an issue. Its pretty straightforward. You can use poly to manage  
the basic logic for a sequencer track, make a new 'voice', and  
abstract out your UI away from your poly~ internals in a way that is  
easy to script and manage multiple instances of.

One of the things it took me a while to fully grok is separating ones  
UI from programmatic-al underpinnings. LITERALLY separate. You can do  
various workarounds without scripting such as having say

a set of buttons/number box detailing WHICH INSTANCE or TRACK NUMBER  
you are editing. Your ONE SINGLE UI SET then updates to reflect the  
state of that instance number within the poly.

or you could do this with multiple tracks, say you have enough screen  
real-estate for 5 trakc UI's, but you want to have 'n' tracks in your  
patch. Do the above, but when you 'scroll' down to the 10th track, the  
banks simply display 5 - 10, you dont NEED 'n' UI elements. Thats bad  
programming, bloated overhead, and poorly optimized. Plus it makes it  
that much harder to change anything.

This sort of UI design is where Javascript SHINES - scripting a la  
thispatcher, but with procedural coding principles.

ive just redone my custom GUI objects with javascript, and my module  
loading system as well. it makes life much better.

> blairell schrieb:
>> lets say i have a sequencer, and i have a patch for each track.  what
>> if i want another track? and i want that instance created upon the
>> execution of some other function like "new track"?  then i start
>> getting into ugly code that doesn't become readable anymore.
>
> This specific scenario is not really a problem in Max, I would do it  
> (and have done it) with scripting bpatchers, and it wouldn't be  
> ugly...
> But the question if SuperCollider would fit your needs better is  
> much more a question of taste, if you prefer "lines of codes"  
> thinking more than the visual data flow model, Supercollider is for  
> you, if its the data flow, you just have to dig a bit deeper into  
> Max. You won't learn this within some months...
>
> Stefan
>
> -- 
> Stefan Tiedje------------x-------
> --_____-----------|--------------
> --(_|_ ----|-----|-----()-------
> -- _|_)----|-----()--------------
> ----------()--------www.ccmix.com
>


Sure. I actually have a very limited max patcher based prototype of 

the oo objects, which dont have proper namespaces, public/private 

methods, etc , but shows the principle of working with oo.method and 

oo.call. I have to go in and clean some things out, but ill post it in 

a bit :) I dont want to go sharing the oo externals on the list, but 

On Jan 3, 2008, at 12:15 PM, Wesley Smith wrote:

>> Ive been prototyping some things with them and it REALLY makes 

>> with Max a Joy (again)- the best of patching/prototyping but now OO

>> methods and calls, that you can define and use, with namespaces. Now

>> if we could only find that elusive "jit.gl.texture - error unbinding

> I'm sure your patch is massive :) but if you could possibly find a

> way to post an as reduced as possible while still exhibiting the error

Sure. I actually have a very limited max patcher based prototype of  
the oo objects, which dont have proper namespaces, public/private  
methods, etc , but shows the principle of working with oo.method and  
oo.call. I have to go in and clean some things out, but ill post it in  
a bit :) I dont want to go sharing the oo externals on the list, but  
im sure Mattijs and John clear that up.

>> Ive been prototyping some things with them and it REALLY makes  
>> working
>> with Max a Joy (again)- the best of patching/prototyping but now OO
>> methods and calls, that you can define and use, with namespaces. Now
>> if we could only find that elusive "jit.gl.texture - error unbinding
>> texture" bug ;)
>
> I'm sure your patch is massive :)  but if you could possibly find a
> way to post an as reduced as possible while still exhibiting the error
> patch, it'd be appreciated.
>
> thanks,
> wes


Quote: vade wrote on Thu, 03 January 2008 18:52

> Sure. I actually have a very limited max patcher based prototype of 

> the oo objects, which dont have proper namespaces, public/private 

> methods, etc , but shows the principle of working with oo.method and 

> oo.call. I have to go in and clean some things out, but ill post it in 

> a bit :) I dont want to go sharing the oo externals on the list, but 

> im sure Mattijs and John clear that up.

That's right, we're still changing things that make the objects non-backwards compatible so we refrain from posting them on the list just yet.

Vade's abstractions implement one aspect of the oo objects, the idea of returning info from a method to a caller address. A rudimentary example of a patcher based way to do this also comes with max in jitter-examples/video/quicktime/jit.qt.movie-multi-head.pat.

> Mad Props to Mattijs and John. :) Im stoked.

Quote: vade wrote on Thu, 03 January 2008 18:52
----------------------------------------------------
> Sure. I actually have a very limited max patcher based prototype of  
> the oo objects, which dont have proper namespaces, public/private  
> methods, etc , but shows the principle of working with oo.method and  
> oo.call. I have to go in and clean some things out, but ill post it in  
> a bit :) I dont want to go sharing the oo externals on the list, but  
> im sure Mattijs and John clear that up.

Quote: vade wrote on Thu, 03 January 2008 09:25

> One of the things it took me a while to fully grok is separating ones 

> UI from programmatic-al underpinnings. LITERALLY separate.

I have been getting better about this kind of separation, but one thing I still struggle with is how the pattr system fits in.

It's too easy to attach pattr objects to GUI objects, but in the long run that makes it difficult to change the patch's UI.

So it seemed to make more sense that pattr objects would be attached to the logic of the patch, but then I run into another problem: I cleanup and restructure my patches as part of ongoing development. This usually involves encapsulation/decapsulation, but that affects the path to my pattr objects and then my preset save files no longer work. I'd have to write a pattrstorage .xml upgrade tool each time my patch structure changes to fix the paths. Yuck! I think I could use Jeremy Bernstein's pattrmarker object as a workaround (haven't tried this yet), but that approach still sounds like unnecessary maintanence work.

So I have been thinking there are 3 layers of independent "code" in a big Max application:

1. The logic that does the number crunching, synthesizing, video mixing, etc

3. The storage to maintain patch state, save/load, interpolate

This is more or less in line with the Model-View-Controller pattern found in many OO GUIs. The logic is the controller, the GUI is the view, and the pattr system is the model.

I am starting to prefer putting all my pattrs at the same level as the pattrstorage (or if there is an "array of objects" in my patch I use a poly~ containing a bunch of pattrs). But managing the messaging between the 3 layers is a serious PITA. I had the chance to try Mattijs and John's OO objects and it's going to help a lot with this. I agree with vade - these guys deserve some mad props :)

Anyone have any thoughts or suggestions on how the pattr system should fit into the separation of GUI from logic?

Quote: vade wrote on Thu, 03 January 2008 09:25
----------------------------------------------------
>
> One of the things it took me a while to fully grok is separating ones  
> UI from programmatic-al underpinnings. LITERALLY separate. 

I have been getting better about this kind of separation, but one thing I still struggle with is how the pattr system fits in. 

So I have been thinking there are 3 layers of independent "code" in a big Max application:
1. The logic that does the number crunching, synthesizing, video mixing, etc
2. The GUI to control the logic
3. The storage to maintain patch state, save/load, interpolate

This is more or less in line with the Model-View-Controller pattern found in many OO GUIs. The logic is the controller, the GUI is the view, and the pattr system is the model. 

Anyone have any thoughts or suggestions on how the pattr system should fit into the separation of GUI from logic? 

1. the poly~ method is a good idea, i never even considered it because of its assumed use for dsp but that may work. lets say i have-

how would i change the number of instances (using the voices message) without loosing all the information contained in the subpatches (they seem to reset upon sending the "voices" message)? would i have to save and load them with coll/pattr?

2. as for pattr, well i have refrained from using it because the load/save issue is a problem if the variables change (as adamj mentioned). thats why I've just stuck with coll, because i usually can plan ahead my data structure and symbols fairly easily.

3. what about creating guis in supercollider, is it simple/possible? im contemplating getting a compact touchscreen/wacom cintiq and developing a gui for it. could be a great replacement for the lemur (though sadly no multitouch, its touch accuracy/fine control would be better)

1. the poly~ method is a good idea, i never even considered it because of its assumed use for dsp but that may work.  lets say i have-
"poly~ poly_loadme 8"
how would i change the number of instances (using the voices message) without loosing all the information contained in the subpatches (they seem to reset upon sending the "voices" message)?  would i have to save and load them with coll/pattr?

2. as for pattr, well i have refrained from using it because the load/save issue is a problem if the variables change (as adamj mentioned).  thats why I've just stuck with coll, because i usually can plan ahead my data structure and symbols fairly easily.

3. what about creating guis in supercollider, is it simple/possible?  im contemplating getting a compact touchscreen/wacom cintiq and developing a gui for it.  could be a great replacement for the lemur (though sadly no multitouch, its touch accuracy/fine control would be better)

oh yes, and has there been any mention of oo in max 5?

despite max's brilliant capabilities, i find it strange that oo capabilities hasn't been integrated into max more easily with all the fiddling about we all seem to be doing.

oh yes, and has there been any mention of oo in max 5?
despite max's brilliant capabilities, i find it strange that oo capabilities hasn't been integrated into max more easily with all the fiddling about we all seem to be doing.


Quote: blairell wrote on Thu, 03 January 2008 17:47

> 1. the poly~ method is a good idea, i never even considered it because of its assumed use for dsp but that may work. lets say i have-

> how would i change the number of instances (using the voices message) without loosing all the information contained in the subpatches (they seem to reset upon sending the "voices" message)? would i have to save and load them with coll/pattr?

Yeah. Changing the number of voices is like deleting the poly~ and creating a brand new one. So you either need to create a poly with the maximum number of voices up front and not change the voices (maybe inefficient), or save and restore the state like you are thinking.

> 2. as for pattr, well i have refrained from using it because the load/save issue is a problem if the variables change (as adamj mentioned). thats why I've just stuck with coll, because i usually can plan ahead my data structure and symbols fairly easily.

The nicest thing about pattr is you can interpolate between arbitrary presets with arbitrary sets of your pattr variables. That can be used for all sorts of cool things.

Others have suggested adding the pattr system in at the very end when the patch is mostly complete. But I always have a new feature idea and never "complete" my patches, so coming up with a way to avoid changing pattr paths is an issue for me. It's not impossible, just requires extra planning and effort.

> 3. what about creating guis in supercollider, is it simple/possible? im contemplating getting a compact touchscreen/wacom cintiq and developing a gui for it. could be a great replacement for the lemur (though sadly no multitouch, its touch accuracy/fine control would be better)

I don't know too much about supercollider, but I don't think it does GUIs. I think people usually communicate with a separate GUI component using OSC. Like this: 

You could similarly build a GUI in Max and communicate back and forth with supercollider using OSC. A hybrid approach like that might be a really good idea if you like coding in supercollider and have already invested time into learning Max. You may want to check on supercollider forums or start a new supercollider thread here and see if anyone else has done this.

Quote: blairell wrote on Thu, 03 January 2008 17:47
----------------------------------------------------
> 1. the poly~ method is a good idea, i never even considered it because of its assumed use for dsp but that may work.  lets say i have-
> "poly~ poly_loadme 8"
> how would i change the number of instances (using the voices message) without loosing all the information contained in the subpatches (they seem to reset upon sending the "voices" message)?  would i have to save and load them with coll/pattr?
>

> 2. as for pattr, well i have refrained from using it because the load/save issue is a problem if the variables change (as adamj mentioned).  thats why I've just stuck with coll, because i usually can plan ahead my data structure and symbols fairly easily.

object orientation - max isn't good at it