[PD] Fwd: PD

[Alexandre Porres]

Something regarding PD


---------- Forwarded message ----------
From: Bennett Smith <bennett.smith at music.mcgill.ca>
Date: 2011/5/18
Subject: [Mumt_grad] Fwd: PD
To: mumt_grad at music.mcgill.ca


Here's an opportunity for some interesting work:

Begin forwarded message:

*From: *Jordan Deitcher <jordan at liminal.ca>
*Date: *May 10, 2011 10:39:59 AM EDT
*To: *Bennett Smith <bennett.smith at music.mcgill.ca>
*Cc: *Mitchel Benovoy <mitchel.b at gmail.com>
*Subject: **PD*

Hi Bennett,

We're looking for somebody to do the following.  We were hoping that the guy
who did our particle system would do this, but he can't right now.  Here's
what Mitchel wrote to him.  Zack and Mike thought you might know someone who
could do this.  Would you be oh so very kind and let me know?  Thanks.

Jordan




 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/





_______________________________________________
Mumt_grad mailing list
Mumt_grad at music.mcgill.ca
http://music.mcgill.ca/mailman/listinfo/mumt_grad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110518/fecefca1/attachment-0001.htm>