[PD-dev] libpd partly working with pd instances

Miller Puckette via Pd-dev pd-dev at lists.iem.at
Wed May 28 12:55:56 CEST 2014


Hi Rich -

> 
> These are class-level selectors and function pointers only, no? It seems
> like an acceptable limitation to me that symbols relative to a static class
> definition be unique across the memory space. There is a similar limitation
> in the obj-c runtime, not nice but that's just part of the language.
> 
> The part that seems like it would cause a great deal of confusion would be
> things like send and receiver names, table names, etc.  How difficult is it
> to make these per-instance and deal with classes as static objects that
> need to use sys_lock() to ensure thread safety?  I realize this may not
> suit every use case, but it seems like this would still greatly improve the
> feasibility of using pd as a plug-in.
> 
I think this won't work - if you have duplicate symbols flying around in the 
same instance for the same strings someone will test s1 == s2 somewhere and
fail to see a match.  I don't think it's feasible to have two symbol types,
one for selectors and another for all other names, because you never know when
a symbol is being created which of the two it's going to be.

> As a second alternative, I was wondering if it isn't possible to prepend a
> unique per-instance arg to symbols like the ones mentioned above.  Of
> course has threading issues that would need to be resolved...
> 
This is an interesting possibility.  I found 48 calls to pd_bind() so presumably
I'd have to make 48 edits to prepend a string to every symbol that anything
binds itself to.  The tricker thing would be message boxes - binbuf_eval()
would probably have to do the same prepending when passing messages to named
objects from message boxes.  (Unless we were just to blow that off and require
using explicit "send" objects instead which you'd have to do anyway as it is
now, since everything now has to be "$0" - protected.)

cheers
Miller




More information about the Pd-dev mailing list