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