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
