good design includes more than just personal taste. in real life, you don't want to have cables running diagonally through your room, only because that is the easiest way to do... in pd it is more likely that you accidently delete a line if it runs over an object. plus, in a performance situation you already know what your patch does, the priority of readability will probably get shifted to a priority of usuability, where you want to highlight and concentrate only on the interaction elements. this is not only a matter of "taste". but you are right, there is not always a need for segmented patch cords and max users do not use them all the time. marius.
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?
Ciao