PDCON:Conference/Embedding Pure Data with libpd: Design and Workflow: Difference between revisions
From Medien Wiki
Glozt100sob (talk | contribs) No edit summary |
mNo edit summary |
||
| Line 1: | Line 1: | ||
== | == 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. | 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. | ||
| Line 6: | Line 6: | ||
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. | 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 = | === 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. | 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. | ||
| Line 13: | Line 13: | ||
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]. | 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= | === 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. | 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. | ||