Trying to turn the Pd limitations thread, which eventually became the (usual) 'Pd vs foo" thread, into something possibly more constructive, interesting and inspiring.
Starting from the concept of "Creative Limitation" (I am primarily thinking of Stravinsky):
How do Pd's limitations enhance people's creativity?
This is a great way to frame it, and it is indeed how I approach composition as well. It sometimes helps to think of a piece as a solution – maybe the only solution – to a set of constraints.
Three limitations that I love in Pd off the top of my head:
- The relatively small set of core objects really helps with programming
ingenuity, and in fact has made me think through some things that have been helpful in other programming contexts. I love when someone throws down a "this can't be done in vanilla" challenge; I've learned lots from thinking, "OK, we'll see about that!"
- The smallish set of objects also means that Pd is not a black box. It
does mean sometimes that you have to know what you're doing, but in general it does not force you to think a specific way about what you're doing. This is not true in my experience with my students who use other programs excluding csound and SC, but including Max – they'll often as a group settle on one massive object or plugin that does 100 things in a really specific way (look at this badass object I found!) and all end up writing more or less the same piece due to the directions the design of the object pushed them in.
- Its visual austerity is a huge help to me in thinking clearly about
patching and dataflow. It's amazing how often a geometrically elegant solution turns out to be an elegant solution full stop.
On Wed, Mar 2, 2016 at 9:50 AM, Lorenzo Sutton lorenzofsutton@gmail.com wrote:
Trying to turn the Pd limitations thread, which eventually became the (usual) 'Pd vs foo" thread, into something possibly more constructive, interesting and inspiring.
Starting from the concept of "Creative Limitation" (I am primarily thinking of Stravinsky):
How do Pd's limitations enhance people's creativity?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
- Its visual austerity is a huge help to me in thinking clearly about patching and dataflow. It's amazing how often a geometrically elegant solution turns out to be an elegant solution full stop.
Coincidentally, I was thinking about counterexamples to this today. Consider a gate: float|v-----o <- gate!|v(copy of) float
One of the problems with C is that you must take care both in your conditions for opening the gate, and in avoiding many subtle bugs through spacing, scoping, etc. that could cause the gate to become ineffectual. Many of those subtle bugs are visual-- I mean, your variable's state is just waiting to be perused by any context inside the function that's willing to read it. It's amazing Linux works at all when you consider how few constraints there are on the code one must reason about. A dataflow language improves this by representing the gate as a visual barrier. You can't just blithely read "stuff" below the gate[1]. The gate has to pass the data down the line, and even if you made an additional connection from "float" to something below, you have to drag the line visually over the gate so that your violation of common sense and decency is visually obvious. But now we have a problem, because if we have anything more than "float" that we want to operate on below the gate, we have no way to read it. There are two possible solutions to this:1) store copies of the data below the gate, so that you can read them if you happen to be allowed through the gate.2) send some more expressive form of data like an object through the gate, and pack everything you want to have access to into that object. #1 is what I see in most patches (and what I end up patching when I just need to get something done). But think about how that complicates the dataflow. In the gate example it's especially apparent-- if you want to store some data below the gate you have to draw a line that does an end run around it to the right inlet of a [float] below the gate. That violates the very representation of a gate that the visual language was trying to provide for you. #2 pack your data into a list and use [route] as the gate. This restores visual clarity at the expense of anonymous positional arguments. So it works well for routing a list of, say, two or three values. But not so well for a larger amount of discrete data. An example of this downside would be a patch that does a good job of showing where a list flows or branches, but then seeing a big message box at the bottom with something like [voice $1-$3 $5 $2 $4(. It's a real pain to debug and extend patterns like that. I'd be interested to hear other approaches to this problem. -Jonathan
On Wednesday, March 2, 2016 8:20 PM, Matt Barber <brbrofsvl@gmail.com> wrote:
This is a great way to frame it, and it is indeed how I approach composition as well. It sometimes helps to think of a piece as a solution – maybe the only solution – to a set of constraints. Three limitations that I love in Pd off the top of my head:
- The relatively small set of core objects really helps with programming ingenuity, and in fact has made me think through some things that have been helpful in other programming contexts. I love when someone throws down a "this can't be done in vanilla" challenge; I've learned lots from thinking, "OK, we'll see about that!"
- The smallish set of objects also means that Pd is not a black box. It does mean sometimes that you have to know what you're doing, but in general it does not force you to think a specific way about what you're doing. This is not true in my experience with my students who use other programs excluding csound and SC, but including Max – they'll often as a group settle on one massive object or plugin that does 100 things in a really specific way (look at this badass object I found!) and all end up writing more or less the same piece due to the directions the design of the object pushed them in.
- Its visual austerity is a huge help to me in thinking clearly about patching and dataflow. It's amazing how often a geometrically elegant solution turns out to be an elegant solution full stop.
On Wed, Mar 2, 2016 at 9:50 AM, Lorenzo Sutton lorenzofsutton@gmail.com wrote:
Trying to turn the Pd limitations thread, which eventually became the (usual) 'Pd vs foo" thread, into something possibly more constructive, interesting and inspiring.
Starting from the concept of "Creative Limitation" (I am primarily thinking of Stravinsky):
How do Pd's limitations enhance people's creativity?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"Gate" is a metaphor, so it seems to me you just need another metaphor for what's going on. The best one I've come up with so far is entirely inappropriate for most cases, but gets the point across: instead of a "gate," you might think of it as a safety on a firearm. You can load and unload it all you want but as long as the safety is on it won't fire. Another one might be "sending supplies past the blockade." Or if you want to keep the "gate" metaphor, it might be "tossing your knapsack over before trying to get through." Or "meet me at the rendezvous; don't do anything without me – if I don't make it past security with the goods, you'll have to abandon the plan."
The other thing about this particular dataflow representation is that cold inlets are themselves a kind of gate. That might make the end-run feel better.
A third option you didn't mention would be using [value].
On Wed, Mar 2, 2016 at 9:20 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
- Its visual austerity is a huge help to me in thinking clearly about
patching and dataflow. It's amazing how often a geometrically elegant solution turns out to be an elegant solution full stop.
Coincidentally, I was thinking about counterexamples to this today.
Consider a gate:
float | v -----o <- gate! | v (copy of) float
One of the problems with C is that you must take care both in your conditions for opening the gate, and in avoiding many subtle bugs through spacing, scoping, etc. that could cause the gate to become ineffectual. Many of those subtle bugs are visual-- I mean, your variable's state is just waiting to be perused by any context inside the function that's willing to read it. It's amazing Linux works at all when you consider how few constraints there are on the code one must reason about.
A dataflow language improves this by representing the gate as a visual barrier. You can't just blithely read "stuff" below the gate[1]. The gate has to pass the data down the line, and even if you made an additional connection from "float" to something below, you have to drag the line visually over the gate so that your violation of common sense and decency is visually obvious.
But now we have a problem, because if we have anything more than "float" that we want to operate on below the gate, we have no way to read it. There are two possible solutions to this:
- store copies of the data below the gate, so that you can read
them if you happen to be allowed through the gate. 2) send some more expressive form of data like an object through the gate, and pack everything you want to have access to into that object.
#1 is what I see in most patches (and what I end up patching when I just need to get something done). But think about how that complicates the dataflow. In the gate example it's especially apparent-- if you want to store some data below the gate you have to draw a line that does an end run around it to the right inlet of a [float] below the gate. That violates the very representation of a gate that the visual language was trying to provide for you.
#2 pack your data into a list and use [route] as the gate. This restores visual clarity at the expense of anonymous positional arguments. So it works well for routing a list of, say, two or three values. But not so well for a larger amount of discrete data. An example of this downside would be a patch that does a good job of showing where a list flows or branches, but then seeing a big message box at the bottom with something like [voice $1-$3 $5 $2 $4(. It's a real pain to debug and extend patterns like that.
I'd be interested to hear other approaches to this problem.
-Jonathan
On Wednesday, March 2, 2016 8:20 PM, Matt Barber brbrofsvl@gmail.com wrote:
This is a great way to frame it, and it is indeed how I approach composition as well. It sometimes helps to think of a piece as a solution – maybe the only solution – to a set of constraints.
Three limitations that I love in Pd off the top of my head:
- The relatively small set of core objects really helps with programming
ingenuity, and in fact has made me think through some things that have been helpful in other programming contexts. I love when someone throws down a "this can't be done in vanilla" challenge; I've learned lots from thinking, "OK, we'll see about that!"
- The smallish set of objects also means that Pd is not a black box. It
does mean sometimes that you have to know what you're doing, but in general it does not force you to think a specific way about what you're doing. This is not true in my experience with my students who use other programs excluding csound and SC, but including Max – they'll often as a group settle on one massive object or plugin that does 100 things in a really specific way (look at this badass object I found!) and all end up writing more or less the same piece due to the directions the design of the object pushed them in.
- Its visual austerity is a huge help to me in thinking clearly about
patching and dataflow. It's amazing how often a geometrically elegant solution turns out to be an elegant solution full stop.
On Wed, Mar 2, 2016 at 9:50 AM, Lorenzo Sutton lorenzofsutton@gmail.com wrote:
Trying to turn the Pd limitations thread, which eventually became the (usual) 'Pd vs foo" thread, into something possibly more constructive, interesting and inspiring.
Starting from the concept of "Creative Limitation" (I am primarily thinking of Stravinsky):
How do Pd's limitations enhance people's creativity?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
you don't have a DAW, so you're not sitting there just arranging boxes on a screen all day...err...hang on... bad example ;)
On Thu, Mar 3, 2016 at 12:28 PM, Matt Barber brbrofsvl@gmail.com wrote:
"Gate" is a metaphor, so it seems to me you just need another metaphor for what's going on. The best one I've come up with so far is entirely inappropriate for most cases, but gets the point across: instead of a "gate," you might think of it as a safety on a firearm. You can load and unload it all you want but as long as the safety is on it won't fire. Another one might be "sending supplies past the blockade." Or if you want to keep the "gate" metaphor, it might be "tossing your knapsack over before trying to get through." Or "meet me at the rendezvous; don't do anything without me – if I don't make it past security with the goods, you'll have to abandon the plan."
The other thing about this particular dataflow representation is that cold inlets are themselves a kind of gate. That might make the end-run feel better.
A third option you didn't mention would be using [value].
On Wed, Mar 2, 2016 at 9:20 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
- Its visual austerity is a huge help to me in thinking clearly about
patching and dataflow. It's amazing how often a geometrically elegant solution turns out to be an elegant solution full stop.
Coincidentally, I was thinking about counterexamples to this today.
Consider a gate:
float | v -----o <- gate! | v (copy of) float
One of the problems with C is that you must take care both in your conditions for opening the gate, and in avoiding many subtle bugs through spacing, scoping, etc. that could cause the gate to become ineffectual. Many of those subtle bugs are visual-- I mean, your variable's state is just waiting to be perused by any context inside the function that's willing to read it. It's amazing Linux works at all when you consider how few constraints there are on the code one must reason about.
A dataflow language improves this by representing the gate as a visual barrier. You can't just blithely read "stuff" below the gate[1]. The gate has to pass the data down the line, and even if you made an additional connection from "float" to something below, you have to drag the line visually over the gate so that your violation of common sense and decency is visually obvious.
But now we have a problem, because if we have anything more than "float" that we want to operate on below the gate, we have no way to read it. There are two possible solutions to this:
- store copies of the data below the gate, so that you can read
them if you happen to be allowed through the gate. 2) send some more expressive form of data like an object through the gate, and pack everything you want to have access to into that object.
#1 is what I see in most patches (and what I end up patching when I just need to get something done). But think about how that complicates the dataflow. In the gate example it's especially apparent-- if you want to store some data below the gate you have to draw a line that does an end run around it to the right inlet of a [float] below the gate. That violates the very representation of a gate that the visual language was trying to provide for you.
#2 pack your data into a list and use [route] as the gate. This restores visual clarity at the expense of anonymous positional arguments. So it works well for routing a list of, say, two or three values. But not so well for a larger amount of discrete data. An example of this downside would be a patch that does a good job of showing where a list flows or branches, but then seeing a big message box at the bottom with something like [voice $1-$3 $5 $2 $4(. It's a real pain to debug and extend patterns like that.
I'd be interested to hear other approaches to this problem.
-Jonathan
On Wednesday, March 2, 2016 8:20 PM, Matt Barber brbrofsvl@gmail.com wrote:
This is a great way to frame it, and it is indeed how I approach composition as well. It sometimes helps to think of a piece as a solution – maybe the only solution – to a set of constraints.
Three limitations that I love in Pd off the top of my head:
- The relatively small set of core objects really helps with programming
ingenuity, and in fact has made me think through some things that have been helpful in other programming contexts. I love when someone throws down a "this can't be done in vanilla" challenge; I've learned lots from thinking, "OK, we'll see about that!"
- The smallish set of objects also means that Pd is not a black box. It
does mean sometimes that you have to know what you're doing, but in general it does not force you to think a specific way about what you're doing. This is not true in my experience with my students who use other programs excluding csound and SC, but including Max – they'll often as a group settle on one massive object or plugin that does 100 things in a really specific way (look at this badass object I found!) and all end up writing more or less the same piece due to the directions the design of the object pushed them in.
- Its visual austerity is a huge help to me in thinking clearly about
patching and dataflow. It's amazing how often a geometrically elegant solution turns out to be an elegant solution full stop.
On Wed, Mar 2, 2016 at 9:50 AM, Lorenzo Sutton lorenzofsutton@gmail.com wrote:
Trying to turn the Pd limitations thread, which eventually became the (usual) 'Pd vs foo" thread, into something possibly more constructive, interesting and inspiring.
Starting from the concept of "Creative Limitation" (I am primarily thinking of Stravinsky):
How do Pd's limitations enhance people's creativity?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
i go bananas -
Jonathan Wilkes -
Lorenzo Sutton -
Matt Barber