Dear god, please, no.
no no no no no. No gradiated patch coords. *please*
I would not mind self routing patch coords, but somehow, whenever a
computer/algorithm/programmer tries to do things for me, like
intelligently re-arrange "x", it ends up getting in my way. I suspect
this will be the case for all but the simplest routing around objects
scenario.
But really - Segmented patch coord are a decent solution - I insist
they can help readability, if used correctly.
I mean, whats the difference between a poorly laid out patch WITHOUT
patch segmentation to one WITH segmentation, both are spaghetti! Hard
to read, and will need to be re-laid out /refactored to make any sense.
With segmented patch coords users have the choice to use them, and
well laid out patches with segmentation (again, I really insist), can
be more readable and less visually distracting than those without.
VIVA LLA SEGMENTED PATCH COORD REVOLUTION!
On Dec 5, 2007, at 1:04 PM, Martin Peach wrote:
And how about patch cords that start out one colour and end up
another with a smooth blend all the way along? Then you could identify different
cords as well as know which way they were going. The ability to raise or lower objects as in Max ("bring to front",
"send to back") and also to have the cords run behind them would be nice. Not sure how much of this is feasible in tk though...also the pd
file format would need to be modified to include patch cord colours and object
drawing order.