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 ?
thnx , serg !
Le 2012-01-12 à 05:47:00, Фывапр Олджэвич a écrit :
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..
It's more important to make patches less messy, rather than making them look less messy.
But if you really want to hide things, you can hide both the connections and the ordinary objects by using the Graph-on-Parent (GOP) feature of subpatches and abstractions.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Фывапр Олджэвич tofuckof@inbox.ru Cc: PD-list pd-list@iem.at; d-list@iem.at Sent: Wednesday, January 11, 2012 9:26 PM Subject: Re: [PD] how to tidy up patches ?
Le 2012-01-12 à 05:47:00, Фывапр Олджэвич a écrit :
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..
It's more important to make patches less messy, rather than making them look less messy.
There are some basics, like trying not to hide wires and avoid ambiguous placement of objects/wires, but at some point it becomes a wasted conversation because box widths and therefore wire positions/angles can vary based available fonts and how the windowing system renders them. So a patch on one system can look "tidy", while different fonts (or different rendering of the same font) can introduce an ambiguity on a different system.
-Jonathan
But if you really want to hide things, you can hide both the connections and the ordinary objects by using the Graph-on-Parent (GOP) feature of subpatches and abstractions.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-01-12 04:51, Jonathan Wilkes wrote:
how the windowing system renders them. So a patch on one system can look "tidy", while different fonts (or different rendering of the same font) can introduce
this of course depends on your definition of "tidiness". e.g. i wouldn't say that C++ code is more tidy/readable if the text was neatly "justified" (as opposed to the usual "left-aligned"ness).
nevertheless, in my conception of "tidyness", Pd alignment is also more important than in text-based languages. i just want to propose that if the readability of your patche depends on the alignedness of the 3rd outlet, you probably should break it down even more into idioms that are readable "at a glance".
fgmasdr IOhannes
----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Thursday, January 12, 2012 3:23 AM Subject: Re: [PD] how to tidy up patches ?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-01-12 04:51, Jonathan Wilkes wrote:
how the windowing system renders them. So a patch on one system can look "tidy", while different fonts (or different rendering of the same
font) can introduce
this of course depends on your definition of "tidiness". e.g. i wouldn't say that C++ code is more tidy/readable if the text was neatly "justified" (as opposed to the usual "left-aligned"ness).
There is absolutely no possibility of the text of one line of C++ overlapping with the text of another line. This is a qualitatively different issue than font differences in Pd creating ambiguities in a patch that weren't there on the author's monitor.
nevertheless, in my conception of "tidyness", Pd alignment is also more important than in text-based languages.
I'd say that with greater freedom of placement comes greater responsibility. Unfortunately Pd in its current implementation doesn't make cross-platform patch clarity possible without a burdensome amount of work (basically looking at the patch ahead of time on as many platforms as possible).
i just want to propose that if the readability of your patche depends on the alignedness of the 3rd outlet, you probably should break it down even more into idioms that are readable "at a glance".
Imagine a [clip 111 555] object with a diagonal wire to the right of it that connects to and from some other objects. That is readable/tidy by any standard. But how does one know whether the available fonts on another system will make [clip 1 5] so wide that its 3rd outlet overlaps the diagonal line, thus creating an ambiguity?
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8OmJcACgkQkX2Xpv6ydvSe3wCfTu6+NluY/I+f+ReSto43LA4W LCUAoN4pGu6k2Aipt5r2t31xmrOIzIji =SxGb -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
But if you really want to hide things, you can hide both the connections and the ordinary objects by using the Graph-on-Parent (GOP) feature of subpatches and abstractions.
or use sends/receives to your gui in paralell. Sometimes it's also not
easy to adjust gop into the original patch, as one atom might be in the
left corner, and the next atom relating to it in the opposing corner of
the screen.
careful with feedback, it might be better to always use [set $1( when
sending values to the gui.
Le 2012-01-12 à 17:37:00, Charles Goyard a écrit :
subpatches
about subpatches, I'm not sure if I saw it or dreamt it, but where's the "make a subpatch from selection" feature?
DesireData had such a feature, and some years later, there was some talk about it on pd-list, but I don't remember whether L2Ork (Ivica) implemented it or not.
In DesireData, it was called «subpatcherize».
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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)
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
Le 2012-01-12 à 08:26:00, Lorenzo Sutton a écrit :
- 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)
It's a good thing to know the difference between a theorem (a truth) and a heuristic (a guess).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Lorenzo Sutton lorenzofsutton@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
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 -> http://lists.puredata.info/listinfo/pd-list
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 ->
-
Charles Goyard -
IOhannes m zmoelnig -
Jonathan Wilkes -
João Pais -
Lorenzo Sutton -
Martin Peach -
Mathieu Bouchard -
Фывапр Олджэвич