On May 22, 2014, at 6:00 AM, [email protected] 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





_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev

Reply via email to