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