Pure Data Packet

Introduction

Pure Data Packet (PDP) is an extension library for the computer music program Pure Data (PD), by Miller Puckette and others. Its goal is to provide a way to use arbitrary data types (data packets) as messages that can be passed around inside PD, along side the standard PD numbers and symbol types. In short it puts any data object on the same level as a float or a symbol.

PDP runs on Linux and OSX. The OSX version depends on Fink, which is not in the "point & click" stage yet, so setting it up will require some efford. There is no windows version. The reason for this is simple: i don't use windows myself. Porting would require writing code for input/output and getting the libraries PDP depends on to work. If anyone is willing to do this, just let me know. PDP can run without X Window, using SDL.

Currently, PDP's focus is on images and video, but there is no reason it should stay like that. There is limited support for matrix processing included in the main library (like Jitter or Gridflow). There is an extension library for 1D and 2D binary cellular automata, opengl rendering (like Gem). Some plans include audio buffers (like Vasp), ascii packets, text buffers, ... Finally there's a library that enables you to connect a scheme interpreter (guile) to PD/PDP. For more image processing objects, have a look at Yves Degoyon's PiDiP library.

Getting Started

If you're used to working with PD, the the documentation and example patches should be enough to get you started. Have a look at the README file in the distribution to find out how to compile and setup. The file doc/reference.txt contains a list of objects. If you have installed PDP properly, you can just press the right mouse button on an object and select help to get a help patch. If this doesn't work, look in the directory doc/objects for a collection of help patches. The directory doc/examples contains some more demos. The directory doc/objects contains two abstractions that are used to setup the input and output in the help patches. You might want to cut and connect some wires to use the input/output setup that works for you.

Packets and Types

PDP is centered around the concept of packets and operations on packets. There are several types of packets. The default type for most objects is image/YCrCb/320x240. This is a single video frame, encoded in the internal 16bit YUV format, measuring 320 by 240 pixels. Another image type is the grayscale image image/grey/320x240. Important notes: All image processing objects that combine two or more packets need to be fed with the same packet types, i.e. encoding (YCrCb/grey) and dimensions need to be the same. Image dimensions need to be a multiple of 8x8.

The bitmap/*/* type is another image representation type supporting several encodings. I.e. bitmap/rgb/*, bitmap/rgba/*, bitmap/yv12/*, ... This type cannot be processed directly by most of the image processing objects, but it can be used to store in delay lines, or to send over the network. It's main use is to support all kinds of input/output devices, and opengl textures, without introducing too many conversions, but it can serve as a space and bandwidth saver too (especially bitmap/yv12/*).

One of the interesting features in PD is the possibility of connecting everything with everything. If you want to generalize this to all kinds of media objects, the complexity of managing the different types starts to grow quite fast. Therefore PDP has a type conversion system that can take care of most of the conversions using the [pdp_convert] object. You can manually convert packets to a certain type by specifying a type template as a creation argument. I.e. [pdp_convert image/grey/*] will convert any packet to a greyscale image. Most of the conversion will become automatic later on.

An example: You can use the basic PDP library together with the cellular automata library and the opengl rendering library to use a cellular automaton as an input to a video processing chain. You can convert the processed image to a texture that can be applied to a 3d object, which then can be drawn to the screen, captured as a texture, converted back to an image, which can then be converted to a sound, processed and converted back to an image, etc... You get the point. The possibilities are endless.


Tom Schouten
Last modified: Thu Sep 25 20:51:44 CEST 2003