[PD] How (Pd's) 'limitations' enhance creativity

i go bananas hard.off at gmail.com
Thu Mar 3 05:04:13 CET 2016


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 at 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 at yahoo.com>
> wrote:
>
>> > 3. 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 at 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:
>>
>> 1. 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!"
>>
>> 2. 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.
>>
>> 3. 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 at 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 at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160303/4ad62490/attachment-0001.html>


More information about the Pd-list mailing list