[PD-dev] Pd-dev Digest, Vol 110, Issue 16

[Dan Wilcox]

On May 22, 2014, at 6:00 AM, pd-dev-request at lists.iem.at wrote:

> 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.

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. 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).

I think we need other libpd iOS developers etc to chime in on whether the current solution is all that's needed or whether the next step is required. I'm all for choosing what's good now over what's best, but I'm not sure if this case is good enough, so I wanted to ask everyone. I'm not sure if we've gotten an answer yet ...

--------
Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20140522/9f5c1905/attachment.html>