[PD] Comments on pd as a library to be used in game

[Chris McCormick]

On Tue, Feb 12, 2008 at 11:03:13AM +0100, Pablo Martin wrote:
> Mmmm, not so sure what you mean (i suppose the pd internal scheduler?),
> but i guess the whole thing could be put in a thread maybe... don't know
> why but it's always seemed like it good be a good idea to have pd as a
> library (after using it too many times as external program)... it'd make
> such a cool "internal" sound system. Still... probably we could handle
> running it as a separate process, but maybe i've had too many bad
> experiences with that :P....

I agree that it would be better to run it as a library. I did a bit of
an experiment, putting hte following into the Pd makefile in the src
directory:

libpd.so: $(OBJ) $(BIN_DIR)
        cd ../obj; $(LD) $(DBG_CFLAGS) -shared -soname ../bin/libpd.so.1 \
	-o ../bin/libpd.so -lc $(OBJ) $(LIB)

Then I tested it with a Python program something like this:

import ctypes
pd = ctypes.CDLL("./libpd.so")
pd.pd_init()
pd.sys_startgui("./pd-gui")

Which seems to vaguely work, although I haven't made it make a sound
yet. Anyway, I think this could be a good strategy for tying Pd into
Blender. I would suggest running Pd in a separate thread and using a
mutexed queue to pass it messages which would then be read from the queue
inside the same thread where Pd was running and passed into Pd in that
thread by using the standard Pd message generating functions. So basically
the game engine and Pd-in-a-thread would only communicate by message
passing over this mutexed queue which should eliminate deadlocks etc.

Best,

Chris.

-------------------
http://mccormick.cx