@mhartzel: Thanks for your reply. We agree that the chocie of plugins matters as far as stability is concerned, with Ardour, and very likely, Pro Tools. From what you are describing, and from a quick search I just did, it looks very much like Bitwig has hit a technical feature big time with their plugin crash protection. At the time of announcement many people sprung forth with the notion that it can’t be done, CPU cycles, the usual. Yes, there is a need to do technical research and be creative about it, and this takes time, and money. I’m interested by how they might be doing it. I do not have the time to delve into this though, as music is priority for free time usage.
But let’s do a bit of improvisation here.
Processes are an extension of the object orientention concept. Or rather, vice-versa. A process is an object. And what is being done between objects is communication. So if I wrap every plugin in an Adapter and this Adapter establishes the communication with the host then there is no concern about jails, chroots, and all that. It’s just another process and it can basically live and die on its own. The Adapter decouples the communication layers since the host does not know how that process talks, but the Adapter does. So the Adapter can talk to the process and when the process talks back to it, it will forward the message to the host in a way that both the host and the Adapter knows. And if the process goes crap, the Adapter can report to the host ah well, that thing just died, do you want me to try to restart it ? This is to say that communications are very much optimized in efficiency. This way could be I think close to how grace is added to the handling of plugins. This woudl be on the straightforward side of things.
Now, the option to have ‘independant plug-in host processes’ is something else. I do use it for DiscoDSP’s Vertigo, Discovery Pro and Bliss as well as Redux, because these guys cannot cohabit with any of the u-he synths. It’s either one company’s products or the other, not both. So I told Bitwig to apply that option to the DiscoDSP and Redux plugins only and they can run fine alongside the u-he plugins. For someone who gets irritated at the slight perception of a latency delay while recording acoustic guitar, I can say they all run just fine. That aspect of Bitwig plugin handling is the most interesting one. It might have to do with exploiting modern CPU characteristics, below the use of object-oriented concepts, I don’t know. Lightweight CPU-supported LXCs…
As for development, there would have to be a dedicated resource to explore and test in a duplicated believable test framework the options. Once the approach is tested and found solid, the implementation is another matter. It might be that the way the code is structured cannot allow for this kind of change, I don’t know. OTOH, Bitwig is a small team, coming from Ableton, but they have one advantage in that they are starting more or less from scratch in an era filled with countless previous DAW experiences, and with a fresh code base that can be immediately structured to the need of a new technical designs.