Sure. That's preferable to my example on the left, and clearly inferior to both the middle and right examples.
Why inferior?
(biggest) you break up the hot inlet flow into two separate units, making it harder to scan
visually emphasize an empty space
have to follow horizontal lines twice to visually complete the path of the hot inlet data flow
the lower horizontal line *will* create an ambiguity on Pd Vanilla
The point of my post is that the limitations of Pd do not in any way guide the user toward the most readable solution. While you have found a fairly readable solution within the constraints, I find it inferior to my theoretical example made without those constraints. If one agrees, then it should be obvious that the limitations of Pd don't allow optimal readability. If one disagrees, then at least I've made it obvious that segmented patch cords do not in any way lead to esoteric-looking, nor complicated, patches. (And if one believes they do then using [t a] or [pd] just for segmented patch cords must be avoided, too.)
-Jonathan
----- Original Message -----
From: Martin Peach martin.peach@sympatico.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Thursday, January 19, 2012 8:06 PM Subject: Re: [PD] how to tidy up patches ?
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 Suttonlorenzofsutton@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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->