Pure Data (also known as pd) is a graphical programming language. Programs are called "patches", and consist of lots of boxes connected to each other by lines. Here's a picture of a pd patch that counts from 0 to 100 over and over again.
I was going to try to explain this whole patch, and talk about objects and messages and connections, but I realized I would be duplicating the efforts of others. If you want to know what's going on, take a look at the Interface section. Also, check out this video where a guy builds a sequencer. Since pd is graphical, sometimes it's easier to get an idea of what's going on by watching someone assemble a patch and listening to them talk about what they're doing.
If you read through those links and you're still with me, good work. And if you're confused, don't worry too much. It takes a little bit of time to wrap your head around what's going on in pd. The import thing to remember is that messages are passed from one object's outlet to another object's inlet.
Early on, pd (or rather, pd's creator's earlier language that ended up becoming Max) was used primarily for processing MIDI messages. The emphasis was on receiving an external event (a MIDI message), doing something with it, and possibly sending other events. These days pd is strongly associated with things like audio synthesis, but one of its strengths is still the ability to graphically describe procedures for handling message events. There are built-in objects for receiving and sending MIDI events, but there are also two objects, "send" and receive", that provide a general mechanism for passing message around within pd. Here's a patch that uses send and receive to transmit a numeric value.
In this case "num" acts as a global channel that can be used to transmit messages. The messages are broadcast in a point-to-multipoint manner, so multiple receives can receive a message from the same send. And multiple send objects can send messages along the same channel.
For a while, the standard way of interacting with a pd patch from another program was to create network connections using objects like netsend and netreceive. This made it difficult to do things like develop a game audio engine in pd and distribute it, because anyone wishing to use it had to have pd installed, and the application had to make sure that pd started up and loaded the patch (or patches) correctly.
A smart guy named Peter Brinkman came along and built libpd. libpd is a C library (with wrappers for a few other languages, including Java) that lets programmers embed pd in another program. Patches can be loaded and unload, and the parent program can communicate with patches by sending and receiving messages. The client program runs libpd inside a loop, passing it an that represent the audio input to the patch, and receiving an array that represent the audio output. This is usually done inside an audio loop, where the byte buffers represent incoming and outgoing audio. These audio processing callback occur at known intervals, so libpd can use this information to keep track of timed events like sending periodic messages from a "metro" (metronome) object. Messages sent to libpd are processed during the audio processing call.
The send/receive mechanism can be used to control applications from pd patches. For example, on the BUG I might create a convention that says that the BUG will send messages to "from_bug", and will listen for messages that are sent to "to_bug". I could then create a message vocabulary, where the patch could send a message like "accelerometer getSample" that would request a sample from the accelerometer, and it would receive a message like "accelerometer sample X Y Z" where X, Y, and Z are accelerometer values.
To this end, I've written a few wrapper bundles for the BUG that attempt to encapsulate libpd and expose BUG functionality to patches. The bundles are libpd, PureDataWrapper, and BugPureDataServices. The description of PureDataWrapper explains how to load a patch into libpd via HTTP. These libraries are very rough around the edges and provide only a bare-bones set of functionality, but I've been able to run the following patch, which reads data from the accelerometer and uses it to change the brightness of one of the LEDs.