On Sat, Jan 14, 2012 at 3:04 PM, Miller Puckette msp@ucsd.edu wrote:
To Pd dev -
For some time the good folks who brought us pdlib have been asking how one could make it possible to run several instances of Pd in a single address space.
Maybe I have on my audio-colored glasses--but that's just where I see things happening.
I remember a conversation with IOhannes in August about multi-threading audio via sub-canvas user interface object (propose thread~ akin to block~). If all you're after is audio multi-threading--there's no need for multiple instances of Pd. Threads could be used to start a portion of the dsp chain, running asynchronously, and then join/synchronize with Pd when finished.
What this would look like: Add a thread_prolog, thread_epilog, and thread_sync function. The thread_prolog function that occurs before block_prolog, starts a thread running the portion of dsp chain cointained within, and returns the pointer to the function following the thread_epilog. The thread_epilog function that occurs after block_epilog--waits for synchronization and returns.
What's the difficult part: You would need to have a good ordering of the dsp chain to take advantage of concurrency--each subcanvas having a thread~ object needs to kick off as early as possible, followed by objects that have no dependence on its output. Secondly, you'd need to put thread_sync on the dsp chain immediately before you will encounter functions with data dependencies.
What this approach would provide: a user interface to control audio threading, without having any duplication of global variables/arrays/symbols, etc. It would put the threading operations closer to the calculations to be performed, and so eliminate many problems as being out-of-scope.
I've been looking at asynchronous dsp chain operations for my PdCUDA project (which is several months behind where I expected to be)--the basic problem is the same. I haven't gotten that far yet, but someday I'm going to get to the point where improvements will be made by changing the order in which perform functions are placed on the dsp chain.
Maybe this doesn't fit what you want--so I'd refer back to problem definition. What's the point of threading and the usage case you have in mind?
Chuck