----- Original Message -----
From: Lorenzo Sutton lorenzofsutton@gmail.com To: pd-list@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
- You can deliberately create messy, uncomprehensible cmoplicated-
esotheric-looking patches which really impress girls/guys
or
- 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:
- 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@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
