Thelordofsod

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?

tidying-up-your-patchers

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 

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 

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

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

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

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'.

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.

> 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

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"...

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?

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"...

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


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 

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).

> 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).


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).

Use align. I'm left handed and have it remapped via macro to control + home. Also use fix width.

Use align.  I'm left handed and have it remapped via macro to control + home.  Also use fix width.


oh and the max toolbox for UI stuff or whatever really. keys x and y are all you need.

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?

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 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!

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

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. 

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.

http://www.oli.tudelft.nl/avdl1064/TS_var_20061211.zip

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. 

Tidying up your patchers