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 <danomat...@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 <danomat...@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-requ...@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 > > > > > _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
