[PD-dev] libpd partly working with pd instances

[Rich E]

This is excellent news indeed.  Happy to see this taking place.


On Mon, May 12, 2014 at 10:12 AM, Miller Puckette <msp at ucsd.edu> wrote:

> I think the global shared symbol space will cause some confusion (patches
> will have to protect their sends and receives, etc., by fabricating local
> names using '$' characters.
>
>
Hm, yea I can see it odd because it means a patch running in normal pd
works differently to one that is 'instanced' in a plug-in architecture.  I
suppose people can be a little more careful how they design their synth /
effect - wide variable passing, but it will make it more difficult to
convert a patch to a plug-in.  Still, can be worked around.


> Also, it won't be possible to run several Pds concurrently on several
> threads - in a threaded environment, each Pd instance will have to lock
> all others out while it runs.  (There might be a fix for that by replacing
> all static variables in Pd by thread-local ones, but this is untested and
> I'd hate to do it unless there's a real need for it, since it would involve
> systematically changing 100s of variable definitions in Pd.)
>
>
I don't think running multiple pd instances concurrently is a big use case
- the big thing this solves is the ability to have 'pd plugin', via vst,
AU, or some other platform, and in those environments all current audio
nodes are processed on the same thread.  If someone really needs multiple
concurrent instances of pd running, they can look into spawning new
processes (which was already possible).

Miller, is the locking happening within pd_setinstance() or some other pd
internal place, or is this synchronization required by the libpd wrapping
layer?

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