I think that would work (if Pd was compiled with the "thread lock" enabled) but the two wouldn't be able to run simultaneously; this would reduce efficiency and might make it harder to get low real-time latencies out of a two-sound-card system.
I'm always nervous about multi-threaded real-time systems on the whole (they can be prone to occasional crashes that are hard to re-create). But if there's demand for it I could go ahead and make static storage in PD per-thread which would theoretically make Pd thread-safe. That would work unless for some reason it happened to crash mysteriously and un-debuggably.
cheers M
On Thu, May 15, 2014 at 04:09:11PM -0400, Dan Wilcox wrote:
Also, I'm just throwing that idea out there as an engineering edge case. Obviously it's probably not that expected etc but should that capability be something we might need in the future?
On May 15, 2014, at 3:33 PM, Dan Wilcox danomatika@gmail.com wrote:
In thinking about this some more, I'm concerned about thread issues if the symbol tables are still global. Would having two instances running on two separate threads (let's say two separate sound card audio threads, for example) work?
On May 15, 2014, at 2:53 PM, Dan Wilcox danomatika@gmail.com wrote:
Howdy Miller,
This looks great and is definitely something we've been excited about.
On May 11, 2014, at 6:00 AM, pd-dev-request@iem.at wrote:
To Pd developers...
I've adapted Pd to nternally use a "pdinstance" structure to allow multiple schedulers (including DSP chains) to run in one address space. With slight modification (see below) libpd can use this to run separate patches asynchronously.
I tried to "instance-ize" all Pd symbols to keep them private but ran into seemingly insoluble problems, so am leaving all symbols global for now. (So patches used in pdlib, if they want to be usable in a multiple-instance scenaro, should protect all send/receive/table/delay/etc named objects with a $[0-9] somewhere.
Judging from quickly scanning the test code, the main difference on our end would be switching context between instances?
I was brainstorming a future api for multiple instances along the lines of simply adding a instance index or pointer version of each of the existing libpd api calls, such as:
int libpd_bang(const char *destination); // current function int libpd_bang(t_pdinstance* instance, const char *destination); // additional instance version (probably better to use a pointer, etc)We could then call pd_setinstance, pdinstance_new etc internally ...
t_pdinstance* libpd_init(); // default, single use case; sets internal default instance pointer and returns it int libpd_init(t_pdinstance* instance); // creates a new instance, returns 0 on success... but in the end perhaps simply adding the new functions directly is simpler:
t_pdinstance* libpd_init(); // returns default internal instance or null on failure t_pdinstance* libpd_new_instance(); void libpd_set_instance(t_pdinstance* instance);I didn't look hard, but I thnk pdlib now will need a way to send $ arguments to patches via libpd_openfile() somehow. Also, libpd_init_audio() will want to make number of channels per-instance, etc. I've put some relevant comments in the test program I'll include below (and sorry for the length of this mail!)
Ok cool. We've got something to go on, great!
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com