[PD-dev] libpd partly working with pd instances

[Rich E]

(replying the Dan's message that was in reply to the digest mail)

On Thu, May 22, 2014 at 10:29 AM, Dan Wilcox <danomatika at gmail.com> wrote:

>
> The issue is, I think, that it feels like we might have the chance to get
> real multi-context, separate symbols. It would be really great to discuss
> this and maybe see it happen as opposed to 5 years from now. If it simply
> involves just lots of symbol renaming, count me first on the list of
> volunteers. I'll do the dirty work if required.
>
> It feels like the current work is definitely *almost* there and I'm really
> happy. I'd just like to know what's required to take it that extra step and
> let's see if we can do it *now*.
>
> If you really want to run things in parallel, you can always just run Pd
> in a new process, which is much safer too.
>
>
> Cool but how do I run "just run Pd in a new process" on iOS? I brought up
> this further separation question to see if the currently solution works for
> most of the use cases we'd see with libpd.
>

I don't think there is a public API for starting multiple processes on iOS,
the system takes care of that by firing up each app in its own process.
These can communicate, though, but they have their own sandbox.  Nor do I
think multiple processes on a tablet would be very useful.

I could see a use case for using pd instances as dsp processors (similar to
a plug-in architecture) on iOS, which would require the same functionality
of independant dsp chain and symbol table.



> It sounds like you answered that with a "no": "If you really want to run
> things in parallel...". Remember, at this point, I believe libpd is being
> mostly used for iOS apps, with desktop being second (you can just run
> pd+gui there).
>
>
People are using libpd in many different ways outside of mobile devices,
from embedding in games to installation work, to live performance with
visuals... and these areas are more in need of this instance change.


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



On Thu, May 22, 2014 at 2:59 AM, Kjetil Matheussen <k.s.matheussen at gmail.com
> wrote:

>
>
>
> On Sat, May 17, 2014 at 6:23 PM, IOhannes m zmölnig <zmoelnig at iem.at>wrote:
>
>> On 05/16/2014 07:34 AM, Miller Puckette wrote:
>> > I think that would work (if Pd was compiled with the "thread lock"
>> enabled)
>> > but the two wouldn't be able to run simultaneously;
>>
>> the problem is, that if someone made Pd into a (e.g.) VST-plugin (and
>> judging from the responses to your announcement mail, a lot of people
>> definitely would like that to happen), then you cannot make any
>> assumptions about how the host will deal with multiple instances of that
>> plugin. the host may choose to run all it's plugins in parallel :-(
>>
>>
> But for now, if you want to make a Pd wrapper VST plugin, you can just put
> locks around all
> pd calls. I think this first step is a good one. I'm not convinced it's
> necessary to
> do the next step, but let's see how this works first. At least it's nice
> to be able to send
> and receive pd messages between instances easily. If you really want to run
> things in parallel, you can always just run Pd in a new process, which is
> much safer too.
>
>
>
> _______________________________________________
> 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/20140522/bee192c4/attachment.html>