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.