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.pe...@sympatico.ca> > To: Jonathan Wilkes <jancs...@yahoo.com> > Cc: Lorenzo Sutton <lorenzofsut...@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 Sutton<lorenzofsut...@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 >>> >>> 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@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 -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
