[PD-dev] libpd partly working with pd instances

[Peter Brinkmann]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20140525/69ca23b8/attachment.html>