Embedding Pure Data with libpd: Design and workflow
Author: Peter Brinkmann
Pure Data can be relevant to sound designers, musicians, and software developers, given a way to integrate graphical sound development with their tools and platforms of choice.
We present libpd, a thin wrapper that turns Pure Data into an embeddable audio library, as one solution. libpd emerged as a byproduct of an effort to port Pd to Android, but it has since taken on a life of its own, with language bindings for Java, Processing, Objective-C, and Python, mobile apps for Android and iOS, and inclusion in packages such as openFrameworks and jReality. Since its announcement in October 2010, it has attracted more than 100 developers, and libpd-based applications are running on more than 3,000,000 iPhones and available to millions of Android devices in the Android Market. We explain the design of libpd, how to use the library, and how it fits into the lifecycle of an audio application from sound design to deployment. We conclude with a discussion of the relationship of libpd to Pd proper.
Design
libpd is defined not only by what it adds to Pd, but what it removes. As a pure audio library, it has no graphical user interface, no audio drivers, and no MIDI drivers. Most crucially, libpd has no innate sense of time.
Instead, libpd focuses on signal processing in its purest form: Samples go in, magic happens, samples come out. The heart of libpd is an audio callback that accepts a buffer of input samples, processes them, and fills a buffer of output samples. libpd keeps track of time only in terms of the number of samples requested so far (i.e., the number of invocations of the process function); calling the process function at the right time is the responsibility of the client code.
The libpd API also includes a number of functions for sending messages to Pd, as well as hooks for registering callbacks that receive messages from Pd. From the point of view of Pd, this mechanism is no different from exchanging messages with [send] and [receive].
Workflow
Pd has been used in prototyping, using OSC or [netsend]/[netreceive] to exchange messages with the outside world. With libpd, the relationship between client code and audio engine is more immediate. Instead of having to launch Pd separately, Pd is embedded in the client code. Instead of using the network, Pd and the client code exchange messages directly. This setup allows sound designers and software developers to work independently; they only have to agree on basic parameters such as the number of audio channels and the labels of send and receive symbols. Software developers can treat libpd as a black box, and sound designers can build patches as usual, designing and testing them with the usual GUI elements. In order to deploy a patch, the sound designer only needs to assign the appropriate send and receive symbols to the GUI elements. The prototype is the production code.
4th international Pure Data Convention 2011 Weimar ~ Berlin