[PD-dev] libpd partly working with pd instances

Dan Wilcox danomatika at gmail.com
Thu May 15 21:33:20 CEST 2014


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 at 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 at 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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20140515/d1f866e1/attachment-0003.html>


More information about the Pd-dev mailing list