Patching conventions

Mar 13, 2011 at 9:44pm

Patching conventions

Has anyone been able to quantify clear concise patching conventions? I feel like I’ve been seeing more and more spaghetti around and I would really love to respond with something other than “clean this up.” I’m not above it. My early patches looked insane! And if I’m being creative while I’m maxing my code looks crazy but I clean it up when I present it to people. But lately I feel like I operate under a system that I can’t quite put into words that keeps my patches looking and operating pretty cleanly. I learned on my own but I bet teachers would benefit from some sort of set of conventions. I couldn’t imagine trying to read code if variable names didn’t stick to certain conventions, max seems the same way.

I think what I’m talking about, mainly, is the following:

* I split my code into functions which are triggered remotely (s/r or oo.objects or scripting)

* Even if I have a massive tower of objects, like when you’re processing midi, I don’t ignore send/receive, value, trigger and zl mth. Those five object enable me to almost never cross a patch chord.

* Unless it looks extremely explicit, I almost never find myself needing to patch upwards.

* I left justify (using cmd Y) strings objects which allows the code to read a zillion times better.

* use snap to grid where possible

* I encapsulate groups of objects which perform a single function and name it so that I know what it takes and what it spits out.

The reason I’m asking is because I think the rules could be numerically quantifiable… and perhaps automate-able.

#55527
Mar 13, 2011 at 10:00pm

AudioMatt wrote: “* I split my code into functions which are triggered remotely (s/r or oo.objects or scripting)”

nice.

AudioMatt wrote: “* Even if I have a massive tower of objects, like when you’re processing midi, I don’t ignore send/receive, value, trigger and zl mth. Those five object enable me to almost never cross a patch chord.
* Unless it looks extremely explicit, I almost never find myself needing to patch upwards.”

seems a bit anal-retentive to me, but ok :D

AudioMatt wrote: “* I left justify (using cmd Y) strings objects which allows the code to read a zillion times better.”

yes! in coding environs, conventions are even more necessary, i think(not so much in the graphical environ in my opinion… simply because it is an environ dedicated to applications of art and the graphical part of it helps to syphon the abstract into concrete form… messy patching is still interesting sometimes when you can see this process in graphic form… there are some very professional max patchers out there who patch messy because it makes sense to them and that’s all that matters).

AudioMatt wrote: “* use snap to grid where possible”

oh damn, i need to get into doing this more, i think…

AudioMatt wrote: “* I encapsulate groups of objects which perform a single function and name it so that I know what it takes and what it spits out.”

this last thing you mention would be the best ‘convention’ to institute.
Modularity = Bliss Within Gestalt

I like, as a ‘graphical’ programming environment, how individual styles of patching can coexist. But I agree it can be messy to parse through spaghetti. I just think if you were to automate any kinds of ‘rules’ like this, it would definitely be somewhat subjective… that is to say, if AudioMatt or say, Jamoma were to come up with ‘patching conventions’, it would definitely be safe to also categorize the patching which ensues as being ‘AudioMatt-style’ or ‘Jamoma-style’ patching.

If you’re trying to find a way simply to automate it for yourself, though, I’d say go for it, and it would be great to see people follow your format.

#199745
Mar 13, 2011 at 10:25pm

I use a grid size of 4. 4. and that works very well, it’s enough to keep things aligned but not so much that things move all “blocky”. Encapsulation is great for certain things, just a trade-off with ease of access. I personally get a little confused when there are things going out and then back into a subpatch, makes me worry about a stack overflow etc., even though that’s just an irrational sense once everything’s working. However, if a function really just “does something” and spits something out, once it’s working, hey, you never need to see it again…encapsulate. Also this gives you a lot more space in the subpatch to see everything and spread things out.

#199746
Mar 13, 2011 at 10:56pm

Raja I think you’re right on a macro level. One couldn’t put together code that did things like modularize patches, but I’ve included an example of what I’m talking about

You have more experience with teaching lots of people so you’re a good person to ask. Do you think anyone would complain about turning A into B in a situation like this? Everything I’ve done here feels like an automeate-able task. ( p object being an exception) To be honest, it kind of feels like a non subjective no brainer even if I might have to play with it afterwards.

(This was just a random patch on my drive that I just cleaned up)

This also gave me a new idea for a rule, if you’re going to patch in parallel make sure both branches are the same length.

A:

– Pasted Max Patch, click to expand. –

B:

– Pasted Max Patch, click to expand. –
#199747
Mar 13, 2011 at 10:57pm

“I use a grid size of 4. 4. and that works very well, it’s enough to keep things aligned but not so much that things move all “blocky”.”

This is a great idea. thank you!

#199748
Mar 13, 2011 at 11:55pm

 
there is a cross relation between your thinking structure and your code/layout.

if you are an anarchist or if you have AHDS, you will not be able to create clean
code, but on the other hand, starting to code with a potion of forced cleanness
and readabilty will help you to think more organized after a while.

i think it is impossible for a beginner to max to start patching by first having a
perfect machine model in mind. finding ones personal layout style is always
a matter of taste and it also depends on what you are building with max.

if you plan to share, or if you plan to continue your old project after a longer
timeperiod where you dont look at it, some kind of organisation is your duty.
 
 
generally i always try to create small bunches of objects which are making up a
logical group. that is done when the whole thing is becoming an abstraction,
but also when it will remain in the root patch.

the absolute mininum where the interfaces between these logical groups are is:

– the GUI

– the inputs (all kind of “inputs” to a patch)

– the outputs (all kind of “outputs”)

– the core(s) of the program.

things like math, conversion, formatting, plug-in parameters, save/load stuff
make extra groups, which may appear multiple times in parallel.

my dataflow usually goes from top to bottom and from left to right, objects are
placed in a way that these direction can be kept.
where this is not possible, connections which go “back”, will be made blue.

things which appear more often are usually end up in an extra patcher.
i call them “application specific abstractions”.

using appropiate filenames and finding the perfect interface for poly~ patchers
are artforms for themselves, i´d need an extra post to describe those.
 
 
-110 (der das patch im innersten zusammenhält)
 

#199749
Mar 14, 2011 at 7:10am

Hello,

you can use a color strategy in your patch ;

for instance : me : subpatches are violet boxes, send/receive are blue boxes …

with time i stopped to fill comments for inlets/outlets ; too painful.

#199750
Mar 14, 2011 at 1:08pm

and never put vanille bechamel, zabaione, and tiramisu in the same subpatcher.

#199751
Mar 20, 2011 at 1:33am

(oops, sorry, been busy lately…)

“You have more experience with teaching lots of people so you’re a good person to ask.”

what what? no, only tutoring long ago, not much teaching.

“Do you think anyone would complain about turning A into B in a situation like this?”

no, no complaints, but it does increase file size with segmented patch chords, maybe you could add an option to step through or skip certain steps in automation. that would allow people to customize more within the style choices.

#199752

You must be logged in to reply to this topic.