Dan Newcome, blog

I'm bringing cyber back

The Zen of Pure Data

with 2 comments

I have been mulling over the idea of writing a guide for Pure Data aimed at developers proficient in at least one other more mainstream programming language. Pure Data is so different than many other programming environments, yet its utility is such that I keep coming back to it despite the difficulties in managing code written in it using traditional techniques.

I’ve written a couple of posts in the past dealing with things like connection order and event processing precedence. However, the little oddities of PD run pretty deep, and I’m afraid that it is quite an involved subject to start in on.

Plenty of other books have been written on PD in the past, and I don’t think I want to write just another PD book. I think there has been enough written on general signal processing techniques and also on programming PD in general. There are some idiomatic things in PD that come up again and again, and I don’t think I’ve seen a concise guide for PD aimed at programmers that already code in other languages and already are familiar with signal processing in general.

Here is a rough list of topics I might cover if I write such a guide:

Processing order

Subpatching

Bang vs everything else

Lists, atoms and messages

Top down, left right (sort of)

Functional PD

That’s a good start. I’ll add to this list soon hopefully.

Advertisements

Written by newcome

May 14, 2013 at 5:22 pm

Posted in Uncategorized

2 Responses

Subscribe to comments with RSS.

  1. This is the first I’ve heard of it. I have seen something like it at work, but I wasn’t sure it was Turing-complete (but the c2 wiki says it is): Unreal Kismet. I never thought I would see program logic that literally looked like spaghetti, but there it was.

    Could you point me to an article explaining how the visual approach is valuable to programmers? Kismet and Pure Data seem to both be designed for those who aren’t (traditional) programmers

    Chris

    May 14, 2013 at 10:24 pm

  2. Chris, this is one of the very things I want to address if I end up doing this. PD has been a strange love/hate affair for me, but there is something magical and creative about it despite its many shortcomings. I think the biggest win for PD is live coding. Being able to change the structure of a running program while performing with it on stage is pretty cool. There are some other langauges deisgned for this, so possibly there are some other ideas to be gleaned from them. ChucK (textual) and KeyKit (hybrid) come to mind.

    Most existing guides seem to use it simply to illustrate one-off DSP concepts rather than actually building a larger system with it. One of the questions I want to answer is whether or not it even makes sense to build reusable larger-scale systems using PD at all. I think the biggest thing I’ve built so far has been the Peeq sequencer. I had to figure out a lot about managing complexity in PD to pull this off. Most of that knowledge came from reverse engineering other patches. Finding patches that weren’t total spaghetti themselves was challenging it itself.

    I’ve started doing a hybrid audio/3d graphics project recently and many of the core components were prototyped in PD/GEM. I started tying everything together by writing a framework called glfo. However, glfo has been pretty tedious to modularize and design in a nice way, which has been the impetus for looking into whether this stuff should even be done in PD or whether I should rewrite it using something like three.js. I probably will do something with three.js anyway, so that point is probably moot, but I still like PD.

    Many of my science friends that I show PD to immediately mention LabView, and other programmers mention Apple’s Quartz Composer. Your mention of Unreal Kismet is the first I have seen of that language, so thanks for pointing that out, I’ll check into it. I think in the best case, a graphical language represents the structure of a system in a terse way without having too many procedural idioms visible. In the worst case, visual systems are just spaghetti fan-in/fan-outs that no one can quite figure out processing order or other side effects without lots of trial and error.

    PD can be pretty bad, but it doesn’t have to be. I’ve been thinking it would be awesome to have a functional visual programming lagnuage that was kind of a cross between Quartz and Clojure. I’ve been inspired partly in this by the Lighttable IDE from Chris Granger and the reactive documents concept from Brett Victor.

    newcome

    May 15, 2013 at 2:45 pm


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: