Pure Data, Android audio, and random stuff

Noisepages: Websites for smart artists.

A recent thread on pros and cons of libpd at Pd Everywhere got me thinking about workflows and the implications of libpd.

I always knew that libpd provides a very smooth and natural workflow from the creation of a patch in Pd to the deployment of a patch to an embedded instance of libpd, but until this morning I only looked at this from my own point of view, i.e., that of a single developer creating both patches and client code. Then I realized that this has much larger implications.

First, libpd provides great separation of concerns — sound designers don’t have to know about programming, and programmers don’t have to know about sound design. All they have to do is agree on the number of input and output channels as well as the collection of send and receive symbols through which the client code will interact with the Pd patch. The sound designer can go ahead and build a patch, controlling it with the usual GUI elements. Building a patch for libpd is no different from building a patch for Pd itself. In order to deploy the patch, the sound designer only has to assign the appropriate send and receive symbols to the GUI elements. Now the programmer can simply load the patch and use it as a black box.

Second, libpd erases the distinction between prototypes and production code. Several people have hooked up Pd or Max/MSP to game engines as a prototyping tool for game audio, using OSC or UDP. While this is a powerful approach, I see two drawbacks: One drawback is that the sound designer needs to add network objects to the patch, in addition to the GUI elements that are needed for development and testing. This adds some friction to the patching process. The other drawback is that this approach is fragile; you have two separate pieces, the game and the audio engine, that have to be launched and networked correctly. You wouldn’t ship production code that way. The prototype that you build this way will always be a prototype.

With libpd, the prototype is the production code. The GUI scaffolding that you use when designing and testing a patch is also the conduit through which the deployed patch communicates with the client code, and the embedded copy of Pd simply becomes a part of the application. Add in the large number of artists who are already familiar with Pd (even larger if you count users of Max/MSP) as well as the fact the libpd comes with the extremely permissive BSD license, and you have some serious disruptive potential.


13 Responses

  1. perdan walter

    Hi, I’m interested to use libpd in a Game engine like Neoaxis http://www.neoaxisgroup.com/ Any chanches to have a C# wrapper? Someone is interested in?Thanks to all.

  2. Peter Brinkmann

    I think a lot of people would be interested in C# bindings for libpd, and I’ll be happy to add them to the libpd repository once someone implements them. It shouldn’t be too hard. You can probably start with the SWIG interface file for python and modify it for the purposes of C#.

  3. perdan walter

    I looked at SWIG. This is new for me. It seems that help in the wrapping process. I consider to try to do it . I’ve never do this before so this is no a promise…. will see. Thanks for the info Peter 

  4. Peter Brinkmann

    SWIG is pretty straightforward to work with. It will wrap most functions automatically, but there are two places that will probably require some thought. Firstly, you need to figure out how to handle sample buffers in C# and then write the appropriate typemaps. Secondly, you need to figure out how to implement callbacks so that your C# client code can receive messages from libpd. Good luck!

  5. perdan walter

    Thank you Peter. I will consider your precious advises! But i must understand well SWIG before. In the next days i will try. actually i m bit busy with some academic exams (i m an italian student of fine arts…) .See you!

  6. Yuli Levtov

    Hi Peter,

    I’m looking into creating a pretty fully-featured audio iPad app with Pd as the engine, and a combination of openFrameworks and Objective-C for the rest. What do you think are the possibilities of using Sonoma Wire Works’ AudioCopy/AudioPaste with audio that’s stored in Pure Data arrays? Do you think that data accessible to the protocol?


  7. Peter Brinkmann

    Hi Yuli,
    I recently added support for reading and writing arrays in Pd (documented in the wiki: http://gitorious.org/pdlib/pages/Libpd), and that should work just fine with AudioCopy and AudioPaste.

    I haven’t looked at the Objective C bindings for libpd lately, and I’m not sure whether the new array access API has been added to the Objective C API yet, but if not, then you can easily add that yourself.

    Another question is whether you really want to use arrays this way.  It’ll certainly work, but it may lead to an unusual patching style.  It might be easier to just use the usual input/output buffers of Pd, but it’s hard to tell without knowing more details.

    In any case, you should head over to pd-everywhere (http://noisepages.com/groups/pd-everywhere/) and ask your question in the forum in order to get some feedback from the iOS crowd.

  8. Mason Alessandro

    I’m sorry for my English..
    I’ve a question that hasn’t an answer yet. It’s possible to implement OSC protocol PD methods with libpd?

  9. Peter Brinkmann

    I’m not quite sure what you mean by implementing OSC methods with libpd, but here’s how OSC and libpd fit together.

    Basically, you have two choices. You can use the familiar OSC externals with libpd (the wiki explains how: http://www.gitorious.org/pdlib/pages/Libpd), or you can use an OSC library in your client code and have your client code convert OSC messages to Pd messages and vice versa.

    If you are going to use existing Pd patches that use OSC, you probably want to keep those patches and use an OSC external. If you’re creating new patches for this project, then it’s probably easier to implement the OSC parts in your client code.

  10. Mason Alessandro

    Thank’s a lot! I’ll try to implement the PureData OSC methods such as OSCsend, OSCreceive and TouchOSC using libpd and I hope that will be too much difficult.

  11. Flipp

    This sounds great …if it really IS as I imagine it…
    Well is there a tutorial for the programmers part for non-programmers… I mean just adding some kind of “c++-wrapper” to the pd-patch sounds like it even could be scripted.
    So that the non-programmer would just habe to select the patch, give some in- & out-names, hits return and the script does the rest like midi & audio-program-pd-connections…
    Is this possible?!?

  12. Peter Brinkmann

    Not only is this possible, but it’s mostly been done already. If you want easy to use C++ integration, take a look at ofxPd by Dan Wilcox: http://forum.openframeworks.cc/index.php?topic=6492.0

    For scripting, you can take a look at the Python bindings that come with libpd. They haven’t seen much use yet, but they come with some sample code that gives you an idea how to use them.

    About selecting a patch and having some program do the rest, that’s essentially what RjDj and PdDroidParty are doing, all based on libpd.

    About a tutorial, there’s sample code that comes with the various pieces of libpd, and the wiki at Gitorious also contains a lot of useful information.

  13. [...] may help: libpd — workflow, prototyping, and production I believe libpd is a open-source library for sound "patches" The article should also at [...]

Leave a Reply