Funny, this is almost *verbatim* the solution i use in my framework
for creating "name spaces" with outlets and instance numbers.
good to know im not (completely) crazy.
Personally I find that use of segmented patch coords can *increase*
readability in patches that are well laid out. I have a much easier
time following segmented patch coords that are laid out with care than
a similarly grouped /laid out patch sans segmentation.
I actually *like* the patch coords being overlaid on the same pixel
row and column, with my patches, when I use this feature it makes it
very easy for me to visibly discern the flow, in a tree like structure
of multiple sources to destinations. I know that all patch coords on
this one pixel row or colum go "here" - I do not have to think about
it at all, and it takes up less space, making way for tighter patches
which take up less screen real estate.
Of course segmentation can be confusing, where many patch coords
originating from multiple locations and GOING to multiple locations
may be overlayed on the same row/column pixel (so it looks as one
patch coord), and this is definitely makes reading a complex patch
harder, but when used wisely it makes (at least for me) reading
patches MUCH easier, more aesthetic and easier to look at for longer
periods.
.. anyway.
They would be a welcome addition to PD imo.
On Dec 4, 2007, at 5:11 PM, Roman Haefeli wrote:
[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.