[PD] how to tidy up patches ?

Martin Peach martin.peach at sympatico.ca
Fri Jan 20 02:06:14 CET 2012


As the attachment shows, if you sometimes drop the left-alignment 
requirement it can be done unambiguously.

Martin

On 2012-01-19 18:10, Jonathan Wilkes wrote:
>
>
>
>
> ----- 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
>>
>>
>> _______________________________________________
>> 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_2.png
Type: image/png
Size: 2824 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120119/4eacd4aa/attachment.png>


More information about the Pd-list mailing list