--- On Fri, 2/18/11, Andy Farnell padawan12@obiwannabe.co.uk wrote:
From: Andy Farnell padawan12@obiwannabe.co.uk Subject: Re: [PD] FLOSS book Lists chapter To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca, pd-list@iem.at Date: Friday, February 18, 2011, 7:46 PM
I noticed this too.
Miller is quite fond of using it in "Theory and Techniques".
[phasor~] crossing the right inlet of [-~] is completely unecessary, solved merely by moving [-~], [*~], and [cos~] down by 10 px or so.
looks better as attached with the two messages controling [line~] next to each other.
Still unnecessary, but these benefit from signal connections being thicker so that there is a 1px corner where the wire meets the corresponding inlet (basically just a subtle, automatic segmented patch cord).
There are lots of others but I don't see how the modest aesthetic bonus of a completely straight line segment outweighs potential ambiguity created by them.
I do from time to time, but only if the connection is a leftmost or rightmost control/message connection.
For certain kinds of patch, where you mostly have audio DSP runnimg down the page, and occasional parameterisation by number or recieve boxes to the sides, having them hoizontal makes for a kind of nice clarity, audio vertical, messages horizontal.
It might look nice but if the object being connected to has more than one inlet there is an ambiguity in the patch. This may be fine for a picture of a patch where the correct connection is obvious, but for an actual patching habit it's terrible because a subtle, persistent bug can easily cause you to start searching through your patch for all such horizontal cord ambiguities and moving around the relevant objects.
It's exactly the same problem as seeing closely spaced objects:
[1( [slay-fire-breathing-dragon]
Why risk it?
The only rational I can think of is: "looks clean". Which, for a piece of software that relies on black mono-spaced text with black lines running over it, strikes [through] me as odd*.
-Jonathan
But break the rule rather than do anything ambiguous.
My rule avoids all the ambiguity addressed above (well, except for black lines running through black text).
-Jonathan
On Thu, 17 Feb 2011 15:13:05 -0800 (PST) Jonathan Wilkes jancsika@yahoo.com wrote:
--- On Thu, 2/17/11, Mathieu Bouchard matju@artengine.ca
wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: "Jonathan Wilkes" jancsika@yahoo.com Cc: padawan12@obiwannabe.co.uk,
pd-list@iem.at
Date: Thursday, February 17, 2011, 9:25 PM On Thu, 17 Feb 2011, Jonathan Wilkes wrote:
if { $xlets_involved > 2 } {
menu_doc_open
attachment_dir horiz-connections.pd }
Error: Success
Now what's the problem with horizontal wires ?
I mean those that aren't overlapping any inlets
or outlets,
not the ones in your patch.
Here's a revised version where the wires aren't
overlapping.
How do you know they aren't overlapping?
- Use pd-ext and notice the difference between the
1px gray box and the
1px black connections. 2) Actually move the object to _reveal_ that the
connection don't overlap.
- Always assume that the patch creator followed the
rule of "don't
overlap xlets".
1 is implementation specific and ridiculously subtle
for an
environment where "the diagram is the code", 2 is
wasting people's time
by making them fuss around in the patch in order to be
sure they
understand what it does, and 3 is easy to screw up:
__[inlet]_ [f] [f]
(On a narrow object like [f] it's very easy to make a
connection to the
wrong inlet. Well, not as easy on pd-l2ork...)
So I guess qualify it to "no horizontal connections
unless there's only 1
inlet and 1 outlet involved".
-Jonathan
(We already agreed against overlapping wires)
| Mathieu Bouchard ---- tél: +1.514.383.3801
Villeray, Montréal, QC
-- Andy Farnell padawan12@obiwannabe.co.uk