Hello, how can connection between objects be splines or traversal line ? Now - straight lines or terrible messy. Sincerely Mike.
From: "mike.jt@centrum.cz" mike.jt@centrum.cz To: pd-list@iem.at Sent: Wednesday, June 12, 2013 6:51 PM Subject: [PD] Fwd: right angle connections
Hello,
how can connection between objects be splines or traversal line ? Now - straight lines or terrible messy.
Sincerely Mike.
Currently it isn't possible. In the meantime you can use [t a].
[foo( | | [t a]----------------[bar(
-Jonathan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-06-13 00:51, mike.jt@centrum.cz wrote:
Now - straight lines or terrible messy.
or a structured patch.
i haven't yet come across a patch that has been more readable because of rounded corners or bezier lines.
fgamd IOhannes
From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-list@iem.at Sent: Thursday, June 13, 2013 3:11 AM Subject: Re: [PD] Fwd: right angle connections
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-06-13 00:51, mike.jt@centrum.cz wrote:
Now - straight lines or terrible messy.
or a structured patch.
i haven't yet come across a patch that has been more readable because of rounded corners or bezier lines.
Segmented patch cords don't have to have rounded corners nor be made of bezier curves.
As for segmented straight lines...
They improve readability in situations where a straightforward, structured patch ends up with a line crossing over and obscuring text. Obscuring text with lines makes it harder to read words. Making it harder to read words causes eye strain. That ultimately wastes the time of everyone who reads the patch who doesn't have a fresh memory of how the patch got created. (Which, after more than a few hours away from the patch, includes the patch author, too.)
If a cord can make a 90-degree turn to route around text _and_ avoid introducing a visual ambiguity _and_ avoid complicating the dataflow, then it's helpful. If you think a single 90-degree turn in a patch cord cannot achieve all three then you must have a hard time reading flow diagrams in general.
-Jonathan
fgamd IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/
On Fri, Jun 14, 2013 at 1:45 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
They improve readability in situations where a straightforward, structured patch ends up with a line crossing over and obscuring text.
I'll go out on a limb as someone who rarely posts here. I've been working on a single complex patch, with many abstractions and sub-patches, for a long time now and one of the greatest pleasures of patching in PD for me is taking the time to avoid visual clutter within the constraints of working without right-angles or bezier curves.
There are basically three types of lines that look any good in PD to me - the horizontal cord, the vertical cord, and one particular diagonal in which the pixels just happen to align in a regular pattern. I would go so far as to say that working with only those three and sufficient white space one can avoid obscuring text in all situations. It takes longer because you have to think about where you place objects as well as what objects you are using, but I personally find I make better patching decisions based solely on the fact that I am forced to think longer about the patching process.
So long story short, I don't agree that right-angles or beziers are a requirement for clear, structured and readable patches. They may be helpful time-saving tools, but using them would come at a cost for me.
On 06/14/2013 01:03 AM, michael noble wrote:
On Fri, Jun 14, 2013 at 1:45 AM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
They improve readability in situations where a straightforward, structured patch ends up with a line crossing over and obscuring text.I'll go out on a limb as someone who rarely posts here. I've been working on a single complex patch, with many abstractions and sub-patches, for a long time now and one of the greatest pleasures of patching in PD for me is taking the time to avoid visual clutter within the constraints of working without right-angles or bezier curves.
There are basically three types of lines that look any good in PD to me - the horizontal cord, the vertical cord, and one particular diagonal in which the pixels just happen to align in a regular pattern. I would go so far as to say that working with only those three and sufficient white space one can avoid obscuring text in all situations. It takes longer because you have to think about where you place objects as well as what objects you are using, but I personally find I make better patching decisions based solely on the fact that I am forced to think longer about the patching process.
So long story short, I don't agree that right-angles or beziers are a requirement for clear, structured and readable patches. They may be helpful time-saving tools, but using them would come at a cost for me.
While I agree with you that in most cases segmented patch cords are unnecessary, if you never have a need for them I presume you must be then using sends and receives for any situation where there is a feedback loop like:
[object] x [object]
Segmented patch cords have their advantages, but like any tool, they can be also misused to produce even less readable patches. Time permitting and provided there is enough interest I may look into adding segmented patch cords into pd-l2ork.
Cheers!
On Fri, Jun 14, 2013 at 4:51 PM, Ivica Ico Bukvic ico@vt.edu wrote:
While I agree with you that in most cases segmented patch cords are unnecessary, if you never have a need for them I presume you must be then using sends and receives for any situation where there is a feedback loop like:
[object] x [object]
Good point, I had a sneaking suspicion I was missing something. White space helps here, but this is is the one case where I reluctantly tolerate some obscuring the text.
On 14/06/13 16:15, michael noble wrote:
On Fri, Jun 14, 2013 at 4:51 PM, Ivica Ico Bukvicico@vt.edu wrote:
While I agree with you that in most cases segmented patch cords are unnecessary, if you never have a need for them I presume you must be then using sends and receives for any situation where there is a feedback loop like:
[object] x [object]
Good point, I had a sneaking suspicion I was missing something. White space helps here, but this is is the one case where I reluctantly tolerate some obscuring the text.
leaving the lines crossed this way also makes the construct instantly recognisable.
I find that with the addition of an occasional [t a] object and a few send-return pairs when they give a clearer logical layout (plus putting appropriate logically related sections of the code in subpatches) makes a patch very readable, while tracing out segmented cords in big patches in other languages gets tiresome.
Its all really a matter of taste ... it has come up many many times over the years, and nobody who could implement them seems to want segmented cords enough to actually do the work.
Simon
Simon Wise wrote:
Its all really a matter of taste ... it has come up many many times over the years, and nobody who could implement them seems to want segmented cords enough to actually do the work.
Desire Data did Bezier curves.
Having the feature does not force people to use it.
The real problem is: having the feature forces every pd flavor to understand them at the file format level, even if not rendering it.
On Fre, 2013-06-14 at 12:38 +0200, Charles Goyard wrote:
Simon Wise wrote:
Its all really a matter of taste ... it has come up many many times over the years, and nobody who could implement them seems to want segmented cords enough to actually do the work.
Desire Data did Bezier curves.
Having the feature does not force people to use it.
The real problem is: having the feature forces every pd flavor to understand them at the file format level, even if not rendering it.
I'm not sure if this is really a problem. Pd 0.45 supports setting a box width (for objects, messages, comments) that is saved with the patch. Those patches still can be opened and read by previous versions of Pd. This is done by storing the box width after a comma on the object creation line:
#X obj 135 129 osc~ 3000, f 25;
Similarly, this could be done for connections:
#X connect 0 0 1 0, add some connection props here;
Of course, this information is lost when saving the patch with a Pd that doesn't understand the format extension. Also, the extension might cause an older Pd to print an error.
Roman
From: Charles Goyard cg@fsck.fr To: pd-list@iem.at Sent: Friday, June 14, 2013 6:38 AM Subject: Re: [PD] Fwd: right angle connections
Simon Wise wrote:
Its all really a matter of taste ... it has come up many many times over the years, and nobody who could implement them seems to want segmented cords enough to actually do the work.
Desire Data did Bezier curves.
Having the feature does not force people to use it.
The real problem is: having the feature forces every pd flavor to understand them at the file format level, even if not rendering it.
If the "connect" method took A_GIMME you could just follow its initial four floats with a list of coordinates.
-Jonathan
On 06/14/2013 12:07 PM, Jonathan Wilkes wrote:
The real problem is: having the feature forces every pd flavor to understand them at the file format level, even if not rendering it.
If the "connect" method took A_GIMME you could just follow its initial four floats with a list of coordinates.
-Jonathan
Indeed. This is how pd-l2ork maintains backwards compatibility for a number of features. That said, storing coordinates in the existing file format and/or drawing the cord are not the problem. The problem is what happens when you translate the object the cord is connected to? Uncovering logic whether all the coordinates need to be translated (as opposed to only last one) is something that even Max fails to do gracefully despite the fact it has been capable of this for over 10 years, perhaps in part because there is no perfect/graceful way to deal with this that does not require some fairly evolved logic.
Another challenge is cord selection. What needs to be checked is if the existing cord selection logic is indeed robust to handle new segmented cords. Although my memory is not what it used to be, as far as I remember, the hitbox detection is fairly primitive when it comes to cords and in its current form is not capable of gracefully handling this. Please correct me if I am wrong.
Perhaps more pressing matter IMO is ability to multiselect cords so that you can erase many of them at once without having to resort to hack-ish ways of cutting and pasting objects.
From: Ivica Ico Bukvic ico@vt.edu To: Jonathan Wilkes jancsika@yahoo.com Cc: Charles Goyard cg@fsck.fr; "pd-list@iem.at" pd-list@iem.at Sent: Friday, June 14, 2013 2:47 PM Subject: Re: [PD] Fwd: right angle connections
On 06/14/2013 12:07 PM, Jonathan Wilkes wrote:
The real problem is: having the feature forces every pd flavor to understand them at the file format level, even if not
rendering it.
If the "connect" method took A_GIMME you could just follow
its
initial four floats with a list of coordinates.
-Jonathan
Indeed. This is how pd-l2ork maintains backwards compatibility for a number of features. That said, storing coordinates in the existing file format and/or drawing the cord are not the problem. The problem is what happens when you translate the object the cord is connected to? Uncovering logic whether all the coordinates need to be translated (as opposed to only last one) is something that even Max fails to do gracefully despite the fact it has been capable of this for over 10 years, perhaps in part because there is no perfect/graceful way to deal with this that does not require some fairly evolved logic.
For problems like this we should probably look to the only arena that takes UX seriously: games.
There has to be some game designer who ran into exactly this problem and wrote a decent solution.
Another challenge is cord selection. What needs to be checked is if
the existing cord selection logic is indeed robust to handle new
segmented cords. Although my memory is not what it used to be, as
far as I remember, the hitbox detection is fairly primitive when it
comes to cords and in its current form is not capable of gracefully
handling this. Please correct me if I am wrong.
You're probably right. Having the editing logic on the c side means someone would have to code from scratch something that probably takes a single statement in any gui toolkit-- even tk. :)
Perhaps more pressing matter IMO is ability to multiselect cords so
that you can erase many of them at once without having to resort to
hack-ish ways of cutting and pasting objects.
Control-clicking on an empty part of a canvas currently does nothing. Control-click and dragging could leave a trail of 1px rectangles (like the pencil tool in Gimp), and when the user releases the mouse button Pd could select all the wires that have a point in common with the 1px trail. (Then delete the 1px trail [.x5236f0 delete pixeltrail])
There's probably a more efficient way, though.
-Jonathan
From: Simon Wise simonzwise@gmail.com To: pd-list@iem.at Sent: Friday, June 14, 2013 4:37 AM Subject: Re: [PD] Fwd: right angle connections
On 14/06/13 16:15, michael noble wrote:
On Fri, Jun 14, 2013 at 4:51 PM, Ivica Ico Bukvicico@vt.edu wrote:
While I agree with you that in most cases segmented patch cords are unnecessary, if you never have a need for them I presume you must be then using sends and receives for any situation where there is a feedback loop like:
[object] x [object]
Good point, I had a sneaking suspicion I was missing something. White space helps here, but this is is the one case where I reluctantly tolerate some obscuring the text.
leaving the lines crossed this way also makes the construct instantly recognisable.
I find that with the addition of an occasional [t a] object and a few send-return pairs when they give a clearer logical layout (plus putting appropriate logically related sections of the code in subpatches) makes a patch very readable, while tracing out segmented cords in big patches in other languages gets tiresome.
If segmented cords existed, morality would not suddenly go out the window. You would still have subpatches and send/receive pairs to organize your patch. Replacing your occassional [t a] object with a right angle cord isn't going to make a patch harder to read.
Its all really a matter of taste ... it has come up many many times over the years, and nobody who could implement them seems to want segmented cords enough to actually do the work.
Segmented lines with straight and Bezier segments were implemented by majtu in Desire Data.
-Jonathan
-
Brian Perez -
Charles Goyard -
i go bananas -
IOhannes m zmoelnig -
Ivica Ico Bukvic -
Jonathan Wilkes -
michael noble -
mike.jt＠centrum.cz -
Roman Haefeli -
Simon Wise