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!