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

On Mon, May 12, 2014 at 10:12 AM, Miller Puckette <msp@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