<div dir="ltr"><div class="gmail_extra">Thanks for the informative read.<br><br><div class="gmail_quote">On Mon, May 26, 2014 at 1:47 PM, Miller Puckette <span dir="ltr"><<a href="mailto:msp@ucsd.edu" target="_blank">msp@ucsd.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Short answer: I started discovering that there were static structures in<br>
Pd that had ponters to symbols - all such static structures would have to be<br>
tracked down and made per-instance.<br>
<br>
Longer one:<br>
<br>
The specific one I hit (but this could be only one of many problems hiding<br>
there) was every single static t_class (one per class).  This structure<br>
containes a list of symbols (message selectors) and associated function<br>
pointers (and more).<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div> </div><div>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...</div>
<div><br></div><div>cheers,</div><div>Rich</div></div></div></div>