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