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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >> 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? >> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
