Solution to crashes by plugins - Sandboxing (Crash protection)

Cubase
,
1

Hey people,

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):

26 Likes
2

This has been called many times over the years, and I agree it would solve a lot of headaches. I’m guessing there must be a strong reason why this Han’t been implemented., Do you know of any other DAWs that have Sandboxing for plugins?

1 Like
3

I’ve just been watching how Bitwig Studio implements sandboxing. If a plugin crashes within a project you simply reload the plugin, with no interruption to the audio engine. Gets my vote.

7 Likes
4

Yeah, was just gonna say Bitwig i.e.!
EDIT: And reaper has it as well.

5

I can’t imagine there not being some kind of overhead due to the necessary IPC. Whether that is noticeable on modern CPUs is another question, though.

1 Like
6

From what I know Bitwig already does this. And is currently the only daw.

1 Like
7

No, as already mentioned, reaper can do it, too, as can Tracktion waveform. So it seems that any technical/performance issues that might’ve been possible are solved.
The implementation in Bitwig really seems clever, where you have different options from no sandboxing over sandboxing all plugins from a vendor to everything sandboxed, but with overrides possible (because there still might be plugins who for whatever reason don’t work in a sandbox).
So yeah, would be nice to have, although not very high on my personal wish list, as I don’t have that many problems with crashing plugins, and if yes, I can relatively quickly find out which.

4 Likes
8

Plugin sandboxing, coupled with a gapless audio engine and a background save system that does not interrupt workflow would make Cubase incredible.

10 Likes
9

Yep, and I mean if you could enable it not only globally, but per plugin/track too, then the resource thing would be a non issue imho. As soon as you see which plugins always crash cubase, you could sort that problem out and then disable the sandbox again. Or leave it enabled for it, if there is no fix and you really need this plugin.

Also, even if your sessions right now work all flawlessly, you don’t know what happens tomorrow.
Maybe you’re gonna adapt your workflow, use new plugins/products and the situation may change drastically. For the peace of mind it would be good to know, that Cubase will always work, no matter what plugin might crash.

1 Like
10

Next level sh*t! Now these would make wonderful key features for Cubase 13.

2 Likes
11

I wondered why Orange Tree and/or Ample Sound guitars were always present when a lock up occurred. It usually happened during night hours where the computer wasn’t being used. And it didn’t happen every night either. My other VSTs don’t seem to be a problem and I wish I could isolate which guitar company it was. I have some projects in the coming months where I may be able to report on that.

I would definitely be in favor of something that would at least point the finger as to which plugin was doing the deal.

12

Sounds like a great idea.
I’m sick of Cubase/Nuendo hanging and crashing just because of 3rd-party plugins either not loading or authenticating with PACE correctly.

2 Likes
13

It wont work. It will totally destroy latency and efficiency.

1 Like
14

And you are sure about that based on what?
Reaper/Bitwig did it without any mentionable decrease in efficiency.

There could actually be an improvement in resource management, because if you’re able to split up the processing of your master/mix buss on a separate process/thread, the load might spread more evenly on multiple cores.

And even if there would be a slight decrease in efficiency and latency, by having the option to enable/disable it per plugin/track or globally, you can always disable it again, after you found the faulty plugins crashing your projects.

1 Like
15

Yes, im sure. You add scheduling overhead. And the split up of processing can be done better if you pack your channels in same task slice. A and a sand-boxing is it’s own process,
the thread separation is of course needed, but then you share memory and that is what causes the problem. And it wont be slight. Having as a last resort for specific plugins would of cause be helpful, however it will also make plugin vendors more lazy. It’s better to solve the problem where it is.

16

As already said, Reaper and Bitwig users don’t seem to have a big problem with that, which means it is absolutely possible without big drawbacks.

And sorry, but your conclusion does not make sense. This would be the opposite of making plugin vendors more lazy, because finally you 'd know for sure which plugin caused a crash and you can let them know that their plugin was the fault. As it is now, unless you have a dmp file which proves the cause of a crash precisely, there is not much you can do to.

This is helping you solving the problems where they are.

17

I have not tested Reaper nor Bitwig, and I dont need. Sandboxing will need a big amount of context switches and they are not for free.

Mostly it is not that hard to find what plugin is the one that causes the problem. And moving the problem it separate process does not necessary solve the problem, and a plugin that crashes in a sandbox is not useful and still need to be fixed.

18

Then I suggest you try them out. Because how they did it (especially Bitwig) is remarkable, you have multiple sandbox modes and options, which let you choose how many resources/latency will be used, with whitelists and blacklists. It just works.

Depends on what you are mixing/producing, the size of your projects and of course the time you spend doing that.
Usually when mixing smaller projects this is not an issue. But when mixing bigger ones, with over 100+ tracks and hundreds of different plugins, even usually stable plugins can cause crashes. To me it seems this is also related to the CPU usage in general.

This is not for plugins which obviously crash your project everytime you do a specific operation. This is for those cases, when the crash happens out of nowhere. And that to me that happens like 4 times a day sporadically. After troubleshooting for a week I found two plugins which needed to be updated, before it was even worse.

1 Like
19

I agree that it is a bit of a solution to a problem not caused by the DAW itself, and im the end, a crashing plugin must be fixed. It’s nice that the whole DAW doesn’t crash, but personally, if I had to regularly “reload” a plugin, I wouldn’t use it.
So the real benefit to me is that the DAW doesn’t crash and you maybe lose work because of a misbehaving plugin. For that you would of course have to have sandboxing permanently on, and sure, due to the necessary IPC when communicating with the separate processes, that adds overhead. Would it be noticeable? Dunno. Measurable for sure.

It could be a good idea though to just sandbox new plugins that your trying out or have updated, until you make sure that they behave well. That would make sense to me.

1 Like
20

With 100+ tracks with a few plugins in sandbox per track your useful latency is what?
And stability issues are not always software related, quite common that PC are over optimistic tuned.