[PD-dev] libpd partly working with pd instances

[Miller Puckette]

Short answer: I started discovering that there were static structures in
Pd that had ponters to symbols - all such static structures would have to be
tracked down and made per-instance.

Longer one:

The specific one I hit (but this could be only one of many problems hiding
there) was every single static t_class (one per class).  This structure
containes a list of symbols (message selectors) and associated function
pointers (and more).  

At first I thought, no problem, we'll just create one trigger_class (e.g.)
per Pd nstance by calling all the init methds anew for each new Pd instance.
But that failed miserably because:

   t_trgger *x = pd_new(trgger_class)

then blithely picks up the most recently created trgger_class and not the
instance-specfc one.  That new one then can't find any messages because it
has teh symbols fro mteh wrong PD instance to check against.

I thought of perhaps changing the class structure itself to keep track of
which instance we're in, but couldn't fgure out how to do it without requiring
a hash list lookup on each message pass in Pd (ugh) or by making incompatible
API changes.

And this might just be the tip of an iceberg - I have no idea what other
oopses I'd discover after coding all that up.

cheers
M

On Sun, May 25, 2014 at 11:42:07PM -0400, Peter Brinkmann wrote:
> Hi everybody,
> Sorry to chime in so late in the conversation...
> 
> Here's my take on the discussion so far:
> 
> 1. I'm thrilled to see that multiple instances are happening. Thanks,
> Miller!
> 
> 2. If at all possible, we should go all the way and have fully independent
> instances. Anything else will likely come back to bite us, by requiring
> additional documentation and other support, confusing developers (and
> therefore giving rise to bugs), underutilizing multicore systems, excluding
> use cases that we haven't thought of yet, etc. (And I already have a few
> use cases where concurrent instances would have been handy.)
> 
> 3. As I understand the current state, there are two problems that we need
> to solve to achieve independent instances. One is a revision of the API to
> introduce an additional instance parameter. That might be unpleasant to
> implement but seems feasible. (I always expected that we'd need a
> completely revised libpd 2.0 when multiple instances become available.) The
> other one is the shared symbol table.
> 
> 4. Miller, you said in your original post that you ran into seemingly
> insoluble problems when trying to create per-instance symbol tables. Would
> you mind elaborating on this point?
> 
> 5. Even if we're stuck with a single global symbol table, we may be able to
> make it thread-safe without having to resort to locks.
> 
> Cheers,
>      Peter
> 
> 
> 
> On Thu, May 22, 2014 at 5:24 PM, Dan Wilcox <danomatika at gmail.com> wrote:
> 
> > Sure. I guess I don't know what I'm saying :D other than the question:
> > what do we reasonably need? Does the current solution work or is the next
> > step required?
> >
> > On May 22, 2014, at 5:03 PM, pd-dev-request at lists.iem.at wrote:
> >
> > To me, I think the ultimate use case is to be able to fire up two versions
> > of pd in the same processing chain (take vst's in a DAW for example), load
> > each one with identical patches, and have them controlled separately.  This
> > would be a fantastic boost for the ability to extend what we can already do
> > with Pd as an audio processing engine, separated from its native GUI.
> > Locking may be necessary in places, but then that is extremely fast these
> > days.
> >
> > Of course, this all leads to the pdinstance being able to manage the
> > symbol table along with Miller's recent changes, but what are the
> > difficulties in achieving this? It seems like Miller tried and it was more
> > difficult than what we are imagining.
> >
> > cheers,
> > Rich
> >
> >
> > --------
> > Dan Wilcox
> > @danomatika
> > danomatika.com
> > robotcowboy.com
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Pd-dev mailing list
> > Pd-dev at lists.iem.at
> > http://lists.puredata.info/listinfo/pd-dev
> >
> >

> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> http://lists.puredata.info/listinfo/pd-dev