Tidying up your patchers


    Nov 03 2006 | 1:43 pm
    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 03 2006 | 3:08 pm
      I've been taking lessons at harvestworks and was surprised to find out that even people of max seniority have patchers that look like max's splash screen. one of the things I have been taking away from the lessons, is that theres something to be said for just not worrying about tidyness in order to keep up with creative flow.
      For me, as a conceptual person, the most important thing is that when I open or glance at a patch, the order of operation / procedural nature should be obvious. encapsulating long strings of procedural objects helps this. when patching, I hardly let more than 2 or 3 patch chords cross eachother. if they cross at a right angle, I color one.
      Tim Place said he never trusted pvar once. He's certainly more learned than me but I can't live with out it. If my interface touches my code, it makes it impossible to organize especially in large patches. I mean hopefully, your working towards something reusable. pvar makes things easy to tuck away. who wants to be creative in an environment 99 percent of the stuff on the screen, you don't want to think about.
      below is a typical matt patch. it doesn't do anything as its part of a larger program but its a good example of tidyness. it could have been a mess if not for segmented patch chords, pvar, and encapsulation
      rant ended. -matt
    • Nov 03 2006 | 3:47 pm
      My style:
      1) as soon as 5 or more objects perform one task together, encapsulate them. 1a) name the subpatchers according to their tasks (don't be afraid of names that consist of multiple words) 1b) describe all inlets and outlets of subpatchers 1c) color all subpatchers yellow.
      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'.
      Cheers, Mattijs
    • Nov 05 2006 | 7:02 am
      Dave Mcwayne wrote: > 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?
      Yes it is...
      But best is a good design in the beginning. For example you can use the pattr family of objects to seperate UI and functionality. But its hard to do it later if it isn't planned in the beginning.
      tidying up is just "just a matter of hiding objects on lock, using send/receives and sub patchers and a bit of elbow grease"...
      encapsulate-encapsulate-encapsulate...
      Stefan
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Nov 05 2006 | 10:01 am
      Quote: keithmanlove wrote on Fri, 03 November 2006 08:54
      > It seems boring and more trouble than it's > worth, but it's good proof reading; I usually > find errors and ways to > simplify processes.
      thats true, the more you rebuild stuff the more you find better ways, thinking in "modules" and "interfaces" is not only about finding interfaces, it is also about creating modules (and making them better).
    • Nov 06 2006 | 7:13 pm
      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).
      --CJ
    • Nov 08 2006 | 9:53 am
      Use align. I'm left handed and have it remapped via macro to control + home. Also use fix width.
    • Nov 08 2006 | 9:53 am
      oh and the max toolbox for UI stuff or whatever really. keys x and y are all you need.
    • Nov 09 2006 | 4:30 pm
      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?
      Thanks, Mattijs
    • Nov 11 2006 | 11:06 pm
      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!
      -CJ
      ------------------------------------------------------
    • Nov 12 2006 | 12:45 am
      Hi CJ,
      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 ;)
      Regards, Mattijs