object orientation - max isn't good at 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.
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.
you should take a look at the object oriented programming with max
thread. :)
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
> 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.
it's this one:
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.
----------------------------------------------------
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
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'm sure there are lots more of both that could be mentioned.
John
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
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 ;)
Its bliss.
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.
> ----------------------------------------------------
>
> 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
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
> 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
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.
On Jan 3, 2008, at 12:00 PM, Stefan Tiedje wrote:
> 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
im sure Mattijs and John clear that up.
On Jan 3, 2008, at 12:15 PM, Wesley Smith wrote:
>> 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.
Thanks again vade for your kind words :)
Mattijs
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
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.
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?
-Adam
Thanks for all the replies guys.
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.
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?
>
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: http://www.sciss.de/swingOSC/
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.
-Adam
ahh ok. thanks adam. primarily i've been using a lemur which couldn't be more perfect for osc communication with supercollider. if only the damn thing would accept osc instructions to create or alter gui objects on it though. it must happen eventually!
and as for mattijs and johns work, I've had a bit of a read of that thread- it appears to be very promising... if i was to play around with your externals and integrate them into my patches now would i loose compatibility with future patches? if so ill be patient.
I've been using supercollider for a few months. It does do GUIs, and you can do a lot of nifty complicated stuff with them. However, Max is much much faster for setting up basic GUIs. Setting up a GUI in supercollider isn't much (or at all) easier than setting up a GUI with Swing in Java. It takes a considerable amount of time.
I do like the object oriented features of supercollider a lot, as well as the ability to dynamically create components as needed. However I still find myself going to max to do a lot of things. However this may simply be because I'm so comfortable with it.
Here is an example from a supercollider tutorial. It creates a slider with a range of 0.0 to 1.0. It outputs to supercollider's print window-
(
var w, slid;
w=SCWindow("My Window", Rect(100,500,200,200));
//A 200 by 200 window appears at screen co-ordinates (100, 500)
slid=SCSlider(w,Rect(10,10,150,40));
slid.action_({slid.value.postln;});
w.front;
)
Not incredibly complicated, but still a lot more work than dragging an icon onto a patcher window!
> Not incredibly complicated, but still a lot more work than dragging
> an icon onto a patcher window!
depends wether you need to find space in patcher, resize, change
inspector parameters, make connection, adjust position.
hmm still faster probably ; )
as for the oo objects, i've tried them a bit, they're very promising
indeed. especially for large projects. elegant too...
now to find some time to build a nice large patch with them : )
as for pattr, i just drop it in at the end as others mentioned.
the gui interpolation thing gets really stuttery when cpu load gets
high though, any solutions for that?
isjtar
ps for those in the brussels area we're holding an sc workshop in may
at okno.be
On Jan 4, 2008, at 4:58 AM, Nick Inhofe wrote:
>
> I've been using supercollider for a few months. It does do GUIs,
> and you can do a lot of nifty complicated stuff with them.
> However, Max is much much faster for setting up basic GUIs.
> Setting up a GUI in supercollider isn't much (or at all) easier
> that setting up a GUI with Swing in Java. It takes a considerable
> amount of time.
>
> I do like the object oriented features of supercollider a lot, as
> well as the ability to dynamically create components as needed.
> However I still find myself going to max to do a lot of things.
> However this may simply be because I'm so comfortable with it.
>
> Here is an example from a supercollider tutorial. It creates a
> slider with a range of 0.0 to 1.0. It outputs to supercollider's
> print window-
>
> (
> var w, slid;
>
> w=SCWindow("My Window", Rect(100,500,200,200));
> //A 200 by 200 window appears at screen co-ordinates (100, 500)
>
> slid=SCSlider(w,Rect(10,10,150,40));
>
> slid.action_({slid.value.postln;});
>
> w.front;
> )
>
>
> Not incredibly complicated, but still a lot more work than dragging
> an icon onto a patcher window!
Adam Murray schrieb:
> Anyone have any thoughts or suggestions on how the pattr system
> should fit into the separation of GUI from logic?
You need pattrs that bind to the objects you want to look at beiing
attached to the GUI. To create the bindto messages use sprintf. They
only differ with the beginning of the pattr/object name you bind to...
A pattrbackward would simplify issues not only for objects with multiple
outlets, but thats on the way as I understood Jeremy...
You have to exclude these connecting pattrs from the pattr storage.
(pattrbackward would be simpler in this regard...)
The other option would be a pattrhub, this has to be triggered to reveal
the values. I didn't try this yet, but it should work as well (maybe its
even better...)
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Stefan, I challenge you to go one entire day without mentioning
pattrbackward. :) Your next Berlin beer is on me, if you rise to the
occasion.
jb
Am 04.01.2008 um 16:59 schrieb Stefan Tiedje:
> A pattrbackward would simplify issues not only for objects with
> multiple outlets, but thats on the way as I understood Jeremy...
isjtar schrieb:
> as for pattr, i just drop it in at the end as others mentioned.
> the gui interpolation thing gets really stuttery when cpu load gets high
> though, any solutions for that?
In bigger projects I design everything around pattr, I drop them in in
the beginning! It will force you to do a good conceptual design because
you need to think about communication from the beginning. If you drop
them in at the end, you can hardly use all of its potential.
For me its still the most powerfull part of creating bigger patch
structures. Its well worth to dive in...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Jeremy Bernstein schrieb:
> Stefan, I challenge you to go one entire day without mentioning
> pattrbackward. :) Your next Berlin beer is on me, if you rise to the
> occasion.
Uuhh thats a hard one, especially as a reply on this thread. Maybe next
week... ;-)
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com