View Issue Details
|ID||Category||Date Submitted||Last Update|
|0008223||features||2020-06-10 06:48||2020-07-08 06:23|
|Fixed in Version|
|Summary||0008223: Plugin sandbox|
I understand there has been a lot of discussion around sandboxing plugins, offering plugin crash protection. There seems to be even its own subpage on Ardour webpage handling this one question:
I'd like to raise this topic up as a feature request still. Mainly because I find this feature very important for Ardour's future competing with other DAWs. But also, I didn't find a feature request for this one yet, only discussion on discourse.ardour.org.
Here come also some ideas to tackle issues with plugin sandboxing mentioned on the Ardour web page.
"It may work for 4 track Bitwig session with 12 plugins or thereabouts but it's not suitable for any large scale work, and certainly not at the very low latency settings that Ardour can be run with."
- How about implementing sandboxing the same way is in Bitwig, so you can choose whether to load plugins "within Bitwig" (as Ardour does now), or choose between different sandboxing methods (grouped together, or by manufacturer/plug-in/individually). This way for use cases you need an absolute real-time, low-latency workstation, you could turn the sandboxing off. But still, for other cases, you could save yourself multiple restarts of the crashed host.
"In short, plugin sandboxing is a way to use plugins that crash their hosts so that when/if they crash, they no longer crash the host. We think that it is a better idea to simply not use these plugins (or, if you prefer, use a different host)."
- There are just too many plugins that may crash. By trying to use only 100% stable (open source and free) plugins, the selection would be very much limited. I think great host should be able to forgive not-so-great plugins' occasional crashes.
- This vision/goal of Carla is nice to read: "Carla should attempt to correct plugin mistakes whenever possible, so it runs as many of them as possible. A warning is logged in such cases. The target is to not annoy users that are unable to fix things by themselves (they cannot write code usually). The logged warnings should be clear enough that 3rd party developers understand what they have to fix after reading them." (https://kx.studio/Applications:Carla)
Frequent crashes of Ardour (in many cases because of misbehaving plugins) are a workflow killer. Restarting crashed projects over and over again is very frustrating. And because it's hard to know if a certain plugin decides to crash, I find myself becoming very afraid maneuvering around settings just to avoid crashes.
|Tags||No tags attached.|
||I'd also love to help to develop this feature. Thought I have never done any C/C++ projects, but have a solid background with Java/PHP/Python and other more high-level languages.|
We reject implementing this in Ardour.
Apart from the arguments mentioned on the page that you've linked.
If a plugin crashes, there will be an audible artifact and it's already game over.
If you want to help, I highly recommend to help fix plugins instead to prevent crashes in the first place.
Well, that's a bummer. As I believe such a feature is gaining far more love than hate on other DAWs.
Also, maybe preventing audible artifacts could be as simple as muting all the audio when the crash happens (which is in fact the case now when the whole DAW crashes). I believe you have heard all the arguments already, but I feel a need to express one more. As I wrote, I think a great host should forgive not-so-great guests. Same as if the operating system would crash whenever any application is crashing, it would be odd to ask for applications to behave well rather than make the OS safe. This will be my last argument, no worries :)
Anyway, if that's the official line, then let's hope plugins get better. Or I think it's even possible to use Carla as an audio plugin and sandbox rest of the plugins in it while working with Ardou
Re; Your OS analog .... plugins are not like applications. Plugins' relationship to a host is like a kernel module. When a kernel module crashes, so does the kernel.
Ah, you will say: that's why you don't run most things as kernel modules, but "out of process" in an "application", so that if it crashes it doesn't take down the entire system.
And that's true, but it doesn't change the fact that we're not going to cook up some absurd hack to deal with unreliable 3rd party code that doesn't scale to large sessions just because unreliable 3rd party code exists. If other DAW developers want to do stuff like this, good luck to them and their users. It's not a stupid idea, but it's also not the kind of software engineering that those of us involved in Ardour want to pursue.
||Thanks for putting your time on explaining more in details thinking process behind the decision! Appreciate it.|
|2020-06-10 06:48||karrirasinmaki||New Issue|
|2020-06-10 06:50||karrirasinmaki||Note Added: 0024447|
|2020-06-10 12:09||x42||Note Added: 0024449|
|2020-06-10 21:32||karrirasinmaki||Note Added: 0024451|
|2020-07-01 16:29||paul||Note Added: 0024545|
|2020-07-01 16:30||paul||Assigned To||=> paul|
|2020-07-01 16:30||paul||Status||new => resolved|
|2020-07-01 16:30||paul||Resolution||open => won't fix|
|2020-07-08 06:23||karrirasinmaki||Note Added: 0024633|