[PD] how to tidy up patches ?

[Jonathan Wilkes]

----- Original Message -----
> From: Lorenzo Sutton <lorenzofsutton at gmail.com>
> To: pd-list at iem.at
> Cc: 
> Sent: Thursday, January 12, 2012 3:26 AM
> Subject: Re: [PD] how to tidy up patches ?
> 
> On 12/01/12 01:47, Фывапр Олджэвич wrote:
>>  Hi !
>> 
>>  is there any option in PD to make complex patches look less messy ?
>> 
>>  for example in MAX you can hide all the connections in performance mode..
>> 
>>  in VVVV - you can spline the hords
>> 
>>  in MAX you also can make hords with different angles.. and so on..
>> 
>>  is there any way in PD to tidy it all up ?
>> 
>>  i can't find it.
>> 
>>  maybe it is really something to do ?
> 
> It's a feature, not a bug. Why? At least two reasons comwe to mind
> 
> 1. You can deliberately create messy, uncomprehensible cmoplicated- 
> esotheric-looking patches which really impress girls/guys
> 
> or
> 
> 2. As already suggested it forces you to strictly, unconditionally stick 
> to the rule: it it starts to look messy, I probably need to make a 
> subpatch along the lines of certain programming theorems that say 
> something like "if a program starts to go beyound the screen you 
> probably need a function" (not sure what the average screen resolution 
> was when it was enunciated though)

By understanding "complex patches" as "lots of objects that take up 
lots of screen real estate" you gloss over commonly needed idioms that 
look messy because of the constraints that Pd forces on the user.  Three
examples are:

1) a storage value at the bottom of the chain that needs to be fed from the top of the 
chain before the chain itself gets triggered.
2) an output at the bottom of the chain needs to feed back into an object at the top 
or middle of the chain
3) both #1 and #2 happening in the same chain.

An example of #3 is attached.  I hope you will agree that wires in the leftmost chain 
are messy and hard to follow.

The middle chain resolves ambiguities at the expense visual noise-- the placement 
of the [t a] objects distract from the chain and in fact create an ostensible 
secondary-chain whose area is unnecessarily large for its function.  And what is 
its function?  Why, it is not to pass the values through unchanged-- which is
redundant because that's what wires do in the first place-- rather, it's function is to 
break one line segment into two segments!  So actually, we already have segmented 
patch cords in Pd-- they just always happen to be accompanied by an unnecessary 
and distracting "b" or "t a" enclosed in a rectangle.

The rightmost example is the clearest to me.  Of course others may think 
differently but it is at *least* as clear as the middle example (with the added benefit that 
there is only one vertical chain of objects).  Plus here we have different line styles 
(Bezier-curved vs. straight) to easily distinguish the difference between the overlapping 
chains (which you don't get with the middle example).

I've left out the possibility of using a [s] [r] pair for such a common idiom because 
a) if this is to be a reusable chain you have to use a $0 prefix, which is ugly, and b) even 
using $0 doesn't guarantee locality (if elsewhere in the patch you have another chain with 
a [s] [r] pair for the same functionality, you have to give it a different symbolic name, so 
you're back where you started, having to rely on your memory to avoid name collisions).*

-Jonathan

* and the reply of "then it needs to be an abstraction" doesn't really work, because there 
are plenty of situations where, for example, you may need two [until] objects in the same 
chain-- furthermore, if one is placed in a subpatch as the OP suggests, memory comes 
in to play to avoid name clashes...

> 
> Of course 1. is usually more fun, and no one really follows 2. when the 
> deadline is midnight and it is 10.15pm :)
> 
> Lorenzo.
> 
>> 
>>  thnx , serg !
>> 
>> 
>>  _______________________________________________
>>  Pd-list at iem.at mailing list
>>  UNSUBSCRIBE and account-management ->  
> http://lists.puredata.info/listinfo/pd-list
> 
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.png
Type: image/png
Size: 15429 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120119/37aabfd3/attachment-0001.png>