Hi Reuben,
After consulting with a PD expert, we're going to change your
workplan slightly. Basically, you will not need to port your C++
code into PD Externals, as this might result in suboptimal CPU
scheduling. Instead, you should use PD purely as an interface to
control the particle system, which will be running in a different
thread. The communication between the particle system and the PD
interface should be done using Open Sound Control (OSC), which is an
efficient UDP communication protocol. The idea is use OSC to send
commands to the particle system (like changes in the parameters).
This is fairly easy to do: you need to implement an OSC handler in
your code that listens to incoming messages from the PD interface
that you will design.
I suggest you familiarize yourself with OSC before you get started
on this (
http://opensoundcontrol.org/introduction-osc).
Here is what our PD expert had to say:
===
So my
suggestion for the particle system / Pd thing is: Don't make a
pd external that contains an OpenGL rendering loop. It's
suboptimal because you'll need a non-blocking polling and/or
drawing mechanism. Pd expects to be in control of scheduling. If
you draw GL in the same thread, you'll get blockage of DSP
(clicky audio). If you draw GL in a separate thread, you'll need
mutexes or condition variables to tell Pd when it's allowed to
change the GL content (ie, between frames). This is tricky
scheduling, and not necessary for what you're doing.
A better solution is to provide an control interface via
OpenSoundControl (OSC). ie, the particle system would be in a
separate process with a socket that listens to control messages.
You do a non-blocking poll of your sockets between frames. There
are lots of libraries (eg, liblo or oscpack) that you can use
for this.
On the Pd side, I'd highly recommend using my [OSCrxtx] objects
for sending messages:http://code.sat.qc.ca/pdsheefa/trunk/src/OSCrxtx/