[PD] segmented patchcords (was Re: PD & MAX)

[Roman Haefeli]

On Tue, 2007-12-04 at 18:29 +0100, Frank Barknecht wrote:
> Hallo,
> marius schebella hat gesagt: // marius schebella wrote:
> 
> > segmented patchcords can make patches less readable, but most of the 
> > time they make patches more readable, and that is when you use so many 
> > unsegmented cords that they hide the objects. also when you want to 
> > connect an object at the bottom of the patch to an object at the top, 
> > then you can lay the cord at the outside of the patch to make the 
> > ~feed-back.
> 
> Flamewar bait, but I'll bite: I think, in many of these cases the
> objects or even the whole patch are laid out in a bad or even wrong
> way. If a patch has so many cords that everything is black from them,
> something is wrong on another level than the level segmentation of
> cords could fix. Then the patch is in need of refactoring. 
> 
> With feedback it's a slighty different issue, but unless you have a
> lot of feedback in your patch, you can make your own segments with [t
> a] or send/receive, and if you have a lot of feedback in your patch,
> you probably should use more abstractions/subpatches anyway, see
> above.
> 
> Btw.: Even many Max users prefer non-segmented cords, don't they?

oh, dear... i sooo much agree with you...

from my experience, whenever segmented patch cords would make a patch
more readable, the patch is very unreadable already anyway (even if it
had segmented chords). it's very difficult (at least for me with limited
brain power) to keep track of all the dataflow and its execution order,
if there is so much recursion and chords going from left to right and
vice versa. in other words: i am absolutely not against segmented patch
cords in general, but they are not a solution for more easily readable
patches. they probably just make the problem look nicer, but the problem
is still there. so, my recommandations go in the very same direction as
franks: whenever readability becomes an issue, try to the restructure
the patch. 

probably this won't apply to your way of patching, but i used to have a
lot of readability problems when using objects like [textfile] or
[index] or selfmade abstractions to store and access certain sets of
information, because probably a lot of other objects were accessing
them, and each of these had a direct connection to [textfile] (or
whatsoever). especially, when the reading from [textfile] (..) is
dependent from previous outputs from [textfile] you can easily end up
with _very_ unreadable spaghetti patches. i would like to show you a
structure, that turned out to be used quite often in my patches. maybe
this is obvious and well known to you already, it is simply based on the
idea by making such objects like [textfile] more easily accessible with
sends and receives like this, lets call it the 'provide pattern':


[r $0.textfile.i.0]
|
[texfile ]
|        |
|        [s $0.textfile.o.1]
|
[s $0.textfile.o.0]


then you can access it with as many of the following structures as you
want (lets call it the 'access pattern':

|
[t b a]
|     |
|     [s $0.textfile.i.0]
| 
|     [r $0.textfile.o.0]
|     |
[list ]
|

you can easily have as many 'access patterns' in a serie and the patch
is still very easy to read. although we actually still have a patch with
many recursion, you can read it in one direction, from top to bottom. 


my 2¢ (CAD)

roman



	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de