Re: [PD] Fwd: right angle connections

[Jonathan Wilkes]

 >From: Ivica Ico Bukvic 
>To: Jonathan Wilkes  
>Cc: Charles Goyard ; "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


-- 
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[Ivica Ico Bukvic]

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.


--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[Jonathan Wilkes]

 >From: Charles Goyard 
>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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[Jonathan Wilkes]

 >From: Simon Wise 
>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 Bukvic  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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[Roman Haefeli]

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






___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[Charles Goyard]

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.


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[Simon Wise]

On 14/06/13 16:15, michael noble wrote:

On Fri, Jun 14, 2013 at 4:51 PM, Ivica Ico Bukvic  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

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[michael noble]

On Fri, Jun 14, 2013 at 4:51 PM, Ivica Ico Bukvic  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.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[Ivica Ico Bukvic]

On 06/14/2013 01:03 AM, michael noble wrote:
On Fri, Jun 14, 2013 at 1:45 AM, Jonathan Wilkes > 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!

--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[michael noble]

On Fri, Jun 14, 2013 at 1:45 AM, Jonathan Wilkes  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.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[Jonathan Wilkes]

 From: IOhannes m zmoelnig 
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...@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/
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[IOhannes m zmoelnig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2013-06-13 00:51, mike...@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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlG5cKkACgkQkX2Xpv6ydvTbygCgkgLruTbtl3OI2jLGyiNY45SX
eFkAnR3N4udxh39sC2gzTqboBemqez13
=LjJC
-END PGP SIGNATURE-

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[i go bananas]

here's a quick hack using tiny graph on parent subpatches as angled joints


right-angles.pd
Description: Binary data
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[Jonathan Wilkes]

 >From: "mike...@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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Fwd: right angle connections

[mike.jt]

Hello,
how can connection between objects be splines or traversal line ? Now - 
straight lines or terrible messy.
 
Sincerely Mike. 
 

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list