PDCON:Conference/Embedding Pure Data with libpd: Design and Workflow
Embedding Pure Data with libpd
Authors: Peter Brinkmann, Peter Kirn, Richard Lawler, Chris McCormick, Martin Roth, Hans-Christoph Steiner
Download full paper: Media:Embedding Pure Data with libpd.pdf
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[[Pure Data]] a dataflow programming environment 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[[Pure Data]] a dataflow programming environment proper.
libpd is defined not only by what it adds to Pd[[Pure Data]] a dataflow programming environment, 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[[wikipedia:Application Programming Interface]] also includes a number of functions for sending messages to Pd[[Pure Data]] a dataflow programming environment, as well as hooks for registering callbacks that receive messages from Pd[[Pure Data]] a dataflow programming environment. From the point of view of Pd[[Pure Data]] a dataflow programming environment, this mechanism is no different from exchanging messages with [send] and [receive].
Pd[[Pure Data]] a dataflow programming environment 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[[Pure Data]] a dataflow programming environment separately, Pd[[Pure Data]] a dataflow programming environment is embedded in the client code. Instead of using the network, Pd[[Pure Data]] a dataflow programming environment 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 GUIGraphical User Interface elements. In order to deploy a patch, the sound designer only needs to assign the appropriate send and receive symbols to the GUIGraphical User Interface elements. The prototype is the production code.
Brinkmann, Peter: Making Musical Apps – Real-time audio synthesis on Android and iOS, O'Reilly Media 2012 ISBN 978-1-4493-1490-3
4th international Pure Data Convention 2011 Weimar ~ Berlin