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

[vade]

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.
>