(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@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@gmail.com
wrote:
On Sat, May 17, 2014 at 6:23 PM, IOhannes m zmölnig zmoelnig@iem.atwrote:
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@lists.iem.at http://lists.puredata.info/listinfo/pd-dev