most of the times Cubase crashes, it has to do with plugins. Also, Cubase is often not able to create a DMP file to tell us, which one was the culprit. Let alone all the hassle and lost time when crashes happen. Thats why I am requesting a Sandboxing feature to prevent that.
For all who don’t know what that is:
Its like a plugin runs in a separate wrapper and when there is a crash, only the wrapper crashes and lets Cubase continue working.
There are multiple ways to do this, per plugin, all plugins together in one wrapper, all plugins of one manufacturer in one wrapper, etc. A error message then appears and tells us that there is a crashed plugin. The plugin can then be reloaded (be it manually/automatically).
You can see how a solution like this works on other DAWs like Bitwig:
You can imagine how much more stable Cubase would be with a solution like this and how fast you could sort out faulty plugins or contact the developer to fix their issues.
90% of all crash reports here on the forum would instantly disappear, providing more resources for Steinberg and less headache for their customers.
It is also time to stop repeatedly blaming 3rd party apps when Cubase crashes, instead of making sure this does not happen in the first place.
There will always be some bad coded plugins, but by implementing a feature like this Cubase runs, no matter what. At least I’d not want to let some sloppy 3rd party apps ruin the reputation and stability of the program I wrote.
It is also necessary for a professional editing program in our times, which also works as a platform for all different kind of software.
I created a project in Bitwig with 100 tracks and 200 plugins in total and did the same in Cubase. To prove, that if implemented well, this system has no real impact on the latency or resources. The results can be found here (Post #43 in this thread):