Tidying up your patchers
Nov 3, 2006 at 1:43pm
Tidying up your patchers
does anyone have any bits of help for tidying up your patchers and making them a little more user friendly. or is it just a matter of hiding objects on lock, using send/receives and sub patchers and a bit of elbow grease?
Also any help with the more graphical side of max will be helpful too. how do i make my patchers look pretty?
Nov 3, 2006 at 3:08pm
I’ve been taking lessons at harvestworks and was surprised to find
For me, as a conceptual person, the most important thing is that when
Tim Place said he never trusted pvar once. He’s certainly more
below is a typical matt patch. it doesn’t do anything as its part of
#P window setfont “Sans Serif” 9.;
Nov 3, 2006 at 3:47pm
1) as soon as 5 or more objects perform one task together, encapsulate them.
2) do all naming according to java naming conventions (sends/receives: ‘lfoSpeed’, subpatchers: ‘calcAvarage’, abstractions: ‘FreqModulationControl’)
3) subpatchers should all have the right-to-left output sequence (if the outlets are related) and the left-most inlet triggers output.
4) if you make an abstraction, make sure it does what its name suggests, also in situations you didn’t anticipate.
5) if there are a lot of cables that have a similar and obvious task, color them gray.
6) get rid of the happy feeling the ooh’s and aah’s give you when other people stand behind your laptop and admire the obvious complexity (max spaghetti) of your software. A patch with only 5 subpatchers looks much less difficult to ‘the crowd’ (but much better to me if that helps ;)
If you want to make a good interface you have the problem of at least sends and receives standing in your way. I would love the reaktor-approach, where interface objects create their interface part in a different window. Btw the rest of reaktor is bad, don’t use it.
I begin to see max more and more as an object-oriented programming language, but in that aspect it misses some basic functionality, most importantly (as I see it now, may change tomorrow) a real variable that incorporates the concept of ‘scope’.
Nov 5, 2006 at 7:02am
Dave Mcwayne wrote:
Yes it is…
But best is a good design in the beginning. For example you can use the
tidying up is just “just a matter of hiding objects on lock, using
Nov 5, 2006 at 10:01am
Quote: keithmanlove wrote on Fri, 03 November 2006 08:54
> It seems boring and more trouble than it’s
thats true, the more you rebuild stuff the more you
Nov 6, 2006 at 7:13pm
Not to mention the use of colorized objects and patch cords… though it may seem like extra work, it really helps in the long run. Keeping to perhaps the first 3 or 4 standard Max colors for all your groups of objects — like “color 3 for storage stuff”, “color 4 for interactive stuff”, “color 5 for mtr recordings”, etc. That way users (or yourself) can choose new color sets if they want a different look, and the objects will respond accordingly. (For that matter, bgcolor and a swatch with saturation bar is a must for every patch… except bpatcher where you need a panel for this.)
I rarely use send and receive personally, but when I do, I try to always use the #1 arguments in there. I mean, heck, if you have a great patch that does something cool (like act as a synth with some cool effects), it only takes a bit of time to make 16 iterations of it, each on their own MIDI channel, etc… etc… so you obviously don’t want to deal with renaming those send and receive objects. Only the global messages are fair game for non-argumented sends/receives (like key events that can then be filtered).
Nov 8, 2006 at 9:53am
Use align. I’m left handed and have it remapped via macro to control + home. Also use fix width.
Nov 8, 2006 at 9:53am
oh and the max toolbox for UI stuff or whatever really. keys x and y are all you need.
Nov 9, 2006 at 4:30pm
Quote: seejayjames wrote on Mon, 06 November 2006 20:13
> I rarely use send and receive personally, but when I do, I try to always use the #1 arguments in there.
Hey seejayjames, I do stuff like this too, a lot. I’m interested in the way you do it. Would it be possible for you to post an example of this that illustrates the idea?
Nov 11, 2006 at 11:06pm
Hey Mattijs, thanks for the interest. I put together a patch that shows some of how I use the arguments. I’m sure you’ve probably got all this figured out by now, but maybe there’s some elements that will give you ideas. I commented it pretty fully because I’m going to use it in a tutorial for a Max class I’m assisting in.
When I took the Max class originally we didn’t get to arguments that early, and we didn’t really *cover* them in the depth they needed … too bad, it’s one of the most powerful features of Max, I think. Being able to use patches as objects, with as many iterations as you want, is amazingly flexible, not to mention the use of bpatcher with all these concepts.
Hope there’s something there of interest, whether specifically related to the arguments or not. Enjoy!
Nov 12, 2006 at 12:45am
Thanks a lot for sharing! I see we’re on the same track when it comes to using patchers as objects without having to bother about stuff that’s inside.
I used to utilize the same system as you display in your patch. This idea evolved and lately I have been working on a more general way to make multiple instances of the same patch without having to rename sends and receives. I call it the ‘var’ system since it incorporates the idea of a variable with a clearly defined scope.
Here is a link to the current version (it’s not finished yet). Maybe I should add some comments but you’ll probably get the idea. Adjust the numboxes and note how the two instances are completely similar and still not interfering, without using arguments.
Let’s have some cross-inspiration ;)
You must be logged in to reply to this topic.