<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_1_1456965226216_13290" dir="ltr">> 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.</div><div id="yui_3_16_0_1_1456965226216_13294" dir="ltr"><br></div><div id="yui_3_16_0_1_1456965226216_13296" dir="ltr">Coincidentally, I was thinking about counterexamples to this today.</div><div id="yui_3_16_0_1_1456965226216_13418" dir="ltr"><br></div><div id="yui_3_16_0_1_1456965226216_13419" dir="ltr">Consider a gate:</div><div id="yui_3_16_0_1_1456965226216_13486" dir="ltr"><br></div><div id="yui_3_16_0_1_1456965226216_13487" dir="ltr">float</div><div id="yui_3_16_0_1_1456965226216_13519" dir="ltr">|</div><div id="yui_3_16_0_1_1456965226216_13521" dir="ltr">v</div><div id="yui_3_16_0_1_1456965226216_13522" dir="ltr">-----o <- gate!</div><div id="yui_3_16_0_1_1456965226216_13523" dir="ltr">|</div><div id="yui_3_16_0_1_1456965226216_13548" dir="ltr">v</div><div id="yui_3_16_0_1_1456965226216_13561" dir="ltr">(copy of) float<br></div><div id="yui_3_16_0_1_1456965226216_13566" dir="ltr"><br></div><div id="yui_3_16_0_1_1456965226216_13619" dir="ltr">One of the problems with C is that you must take care both in your conditions for <br></div><div id="yui_3_16_0_1_1456965226216_14675" dir="ltr">opening the gate, and in avoiding many subtle bugs through spacing, scoping, etc. <br></div><div id="yui_3_16_0_1_1456965226216_14156" dir="ltr">that could cause the gate to become ineffectual.  Many of those subtle bugs are visual-- <br></div><div id="yui_3_16_0_1_1456965226216_14158" dir="ltr">I mean, your variable's state is just waiting to be perused by any context inside the <br></div><div id="yui_3_16_0_1_1456965226216_14889" dir="ltr">function that's willing to read it.  It's amazing Linux works at all when you consider <br></div><div id="yui_3_16_0_1_1456965226216_15124" dir="ltr">how few constraints there are on the code one must reason about.</div><div id="yui_3_16_0_1_1456965226216_14890" dir="ltr"><br></div><div id="yui_3_16_0_1_1456965226216_17328" dir="ltr">A dataflow language improves this by representing the gate as a visual barrier. <br></div><div id="yui_3_16_0_1_1456965226216_14676" dir="ltr">You can't just blithely read "stuff" below the gate[1].  The gate has to pass the data <br></div><div id="yui_3_16_0_1_1456965226216_14730" dir="ltr">down the line, and even if you made an additional connection from "float" to something <br></div><div id="yui_3_16_0_1_1456965226216_14780" dir="ltr">below, you have to drag the line visually over the gate so that your violation of <br></div><div id="yui_3_16_0_1_1456965226216_14831" dir="ltr">common sense and decency is visually obvious.</div><div id="yui_3_16_0_1_1456965226216_14832" dir="ltr"><br></div><div id="yui_3_16_0_1_1456965226216_14833" dir="ltr">But now we have a problem, because if we have anything more than "float" that we <br></div><div id="yui_3_16_0_1_1456965226216_15068" dir="ltr">want to operate on below the gate, we have no way to read it.  There are two possible <br></div><div id="yui_3_16_0_1_1456965226216_15466" dir="ltr">solutions to this:</div><div id="yui_3_16_0_1_1456965226216_15528" dir="ltr">1) store copies of the data below the gate, so that you can read <br></div><div id="yui_3_16_0_1_1456965226216_15591" dir="ltr">them if you happen to be allowed through the gate.</div><div id="yui_3_16_0_1_1456965226216_15655" dir="ltr">2) send some more expressive form of data like an object through the gate, and pack <br></div><div id="yui_3_16_0_1_1456965226216_15656" dir="ltr">everything you want to have access to into that object.</div><div id="yui_3_16_0_1_1456965226216_16026" dir="ltr"><br></div><div id="yui_3_16_0_1_1456965226216_15658" dir="ltr">#1 is what I see in most patches (and what I end up patching when I just need to get <br></div><div id="yui_3_16_0_1_1456965226216_15657" dir="ltr">something done).  But think about how that complicates the dataflow.  In the gate <br></div><div id="yui_3_16_0_1_1456965226216_16157" dir="ltr">example it's especially apparent-- if you want to store some data below the gate you <br></div><div id="yui_3_16_0_1_1456965226216_16677" dir="ltr">have to draw a line that does an end run around it to the right inlet of a [float] below <br></div><div id="yui_3_16_0_1_1456965226216_17558" dir="ltr">the gate.  That  violates the very representation of a gate that the visual language was <br></div><div id="yui_3_16_0_1_1456965226216_18109" dir="ltr">trying to provide for you.</div><div id="yui_3_16_0_1_1456965226216_17559" dir="ltr"><br></div><div id="yui_3_16_0_1_1456965226216_17339" dir="ltr">#2 pack your data into a list and use [route] as the gate.  This restores visual clarity <br></div><div id="yui_3_16_0_1_1456965226216_17326" dir="ltr">at the expense of anonymous positional arguments.  So it works well for routing a list <br></div><div id="yui_3_16_0_1_1456965226216_17325" dir="ltr">of, say, two or three values.  But not so well for a larger amount of discrete data.  An <br></div><div id="yui_3_16_0_1_1456965226216_17327" dir="ltr">example of this downside would be a patch that does a good job of showing where <br></div><div id="yui_3_16_0_1_1456965226216_17422" dir="ltr">a list flows or branches, but then seeing a big message box at the bottom with something <br></div><div id="yui_3_16_0_1_1456965226216_17329" dir="ltr">like [voice $1-$3 $5 $2 $4(.  It's a real pain to debug and extend patterns like that.</div><div id="yui_3_16_0_1_1456965226216_18414" dir="ltr"><br></div><div id="yui_3_16_0_1_1456965226216_18175" dir="ltr">I'd be interested to hear other approaches to this problem.</div><div id="yui_3_16_0_1_1456965226216_18415" dir="ltr"><br></div><div dir="ltr">-Jonathan<br></div><div id="yui_3_16_0_1_1456965226216_17324" dir="ltr"><br></div><div id="yui_3_16_0_1_1456965226216_16748" dir="ltr"><br> </div><div id="yui_3_16_0_1_1456965226216_13567" dir="ltr"><br></div><div id="yui_3_16_0_1_1456965226216_13524" dir="ltr"><br></div><div id="yui_3_16_0_1_1456965226216_13295" dir="ltr"><br></div><div id="yui_3_16_0_1_1456965226216_13257"><span></span></div> <div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font face="Arial" size="2"> On Wednesday, March 2, 2016 8:20 PM, Matt Barber <brbrofsvl@gmail.com> wrote:<br></font></div>  <br><br> <div class="y_msg_container"><div id="yiv7949132295"><div><div dir="ltr"><div class="yiv7949132295gmail_default" style="font-family:verdana, sans-serif;">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.</div><div class="yiv7949132295gmail_default" style="font-family:verdana, sans-serif;"><br clear="none"></div><div class="yiv7949132295gmail_default" style="font-family:verdana, sans-serif;">Three limitations that I love in Pd off the top of my head:</div><div class="yiv7949132295gmail_default" style="font-family:verdana, sans-serif;"><br clear="none"></div><div class="yiv7949132295gmail_default" style="font-family:verdana, sans-serif;">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!"</div><div class="yiv7949132295gmail_default" style="font-family:verdana, sans-serif;"><br clear="none"></div><div class="yiv7949132295gmail_default" style="font-family:verdana, sans-serif;">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.</div><div class="yiv7949132295gmail_default" style="font-family:verdana, sans-serif;"><br clear="none"></div><div class="yiv7949132295gmail_default" style="font-family:verdana, sans-serif;">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.</div></div><div class="yiv7949132295yqt0976633500" id="yiv7949132295yqt28487"><div class="yiv7949132295gmail_extra"><br clear="none"><div class="yiv7949132295gmail_quote">On Wed, Mar 2, 2016 at 9:50 AM, Lorenzo Sutton <span dir="ltr"><<a rel="nofollow" shape="rect" ymailto="mailto:lorenzofsutton@gmail.com" target="_blank" href="mailto:lorenzofsutton@gmail.com">lorenzofsutton@gmail.com</a>></span> wrote:<br clear="none"><blockquote class="yiv7949132295gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Trying to turn the Pd limitations thread, which eventually became the (usual) 'Pd vs foo" thread, into something possibly more constructive, interesting and inspiring.<br clear="none">
<br clear="none">
Starting from the concept of "Creative Limitation" (I am primarily thinking of Stravinsky):<br clear="none">
<br clear="none">
How do Pd's limitations enhance people's creativity?<br clear="none">
<br clear="none">
<br clear="none">
_______________________________________________<br clear="none">
<a rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">
UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br clear="none">
</blockquote></div><br clear="none"></div></div></div></div><br><div class="yqt0976633500" id="yqt88388">_______________________________________________<br clear="none"><a shape="rect" ymailto="mailto:Pd-list@lists.iem.at" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a shape="rect" href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br><br></div>  </div> </div>  </div></div></body></html>