Solution to crashes by plugins - Sandboxing (Crash protection)

Well, dream on it wont work without API adaptations.

Yes it does.

And now please stop spread misinformation here.

1 Like

Sees to be a reasonable way. But note that they emphases that it will have performance impact, and in the end they say that you put 1-2 plugins. So you still need to find out what plugins is causing your problem. And this would be a grate feature for Mac users running mixed native and rosetta2 plugins and you still need to have knowledge on what plugins do internal communications. And totally silence about what latency it will add, and on what latency it will work. They dont even claim that it works for real time tasks.

Yes they literally do, this is even recommended for live usage, where an ultra stable operation (and good latency) is key.

But no numbers?

Here you have your numbers:

I downloaded Bitwig Studio, created 100 tracks with audio on them and one instance of fabfilter Pro Q3 and one instance of Slick EQ on each (=200 plugins) and then recorded a guitar on one channel (it did not make a difference if I recorded multiple tracks at once or just one).

SR was on 48kHz, sample buffer was set on 256 and the reported latency was 5,33 ms:

I tested all plugin hosting modes: WITHIN BITWIG, TOGETHER, BY MANUFACTURER, BY PLUGIN and INDIVIDUALLY.

The observations:

  • There was literally no change in latency when changing between the sandboxing modes, in every mode it is possible to record/playback without any introduced latency, like it is in Cubase
  • With the same buffer setting the latency is at all times EVEN 1 MS LOWER than in Cubase (where it was 6,3), despite having sandboxing activated. This confirms the latency display in both DAWs and I could also not feel any difference in latency when recording, which makes sense at 1 ms difference
  • There is only a real difference in resource usage when using the INDIVIDUAL mode

Now for the resources here is more detailed data:

  • For the same project Cubase is using around 44% CPU usage and 3GB RAM
  • Bitwig in WITHIN BITWIG mode uses around 38% CPU and 2,5GB RAM so even if there is sandboxing activated, it uses less resources
  • TOGETHER and BY MANUFACTURER modes use about the same % CPU as Cubase, but still 500 MB less RAM
  • BY PLUGIN mode uses a bit more CPU, but still 500 MB less RAM
  • Even the hardcore mode INDIVIDUALLY only uses 62% CPU and 3,7 GB RAM, with over 200 additional instances of bitwig. This is not a mode you would likely use in general, but still everything works perfectly, without any issues whatsoever.

PS: BY MANUFACTURER and BY PLUGIN modes could potentially show different values when using more different plugins, but all the other modes would not be affected by this. My system info is visible in my signature/account info

Here are screenshots of the resource usage, while recording in both DAWs:






8 Likes

Hmm, I don’t think that is a real life scenario, tbh. First, you either have to ignore the RAM or establish a baseline with an empty project, because each program might use more or less RAM to begin with.
If Bitwig uses less CPU than Cubase with just one plugin host, kudos to them, they did something right (most likely they just don’t have to deal with +20 years old legacy code from times where SMP wasn’t really a thing).
But in a real world project, even if you group by vendors, you will most likely have plugins from more and different vendors, so the CPU usage will be higher.
Doesn’t matter, because what you have actually proved - and what was to be expected - is that sandboxing will use more resources, inevitably (and that Bitwig might be more efficient to begin with).
Whether that is noticeable is, as I already wrote, another question, and depends very much on the project, the amount of plugins/vendors used and the settings.

I wonder, if you group by vendor, and the one plugin from that vendor crashes, do you have to reload all the plugins from that vendor in that project? I can’t see how you wouldn’t, seeing that they just live in the same process.

Personally i think plugin sandboxing would be perhaps a nice to have feature for Cubase, e.g. for safely testing new or updated plugins, but not high on my own priority list.
If I have a plugin that crashes regularly, I wouldn’t use it anymore, sandboxing or not. Or open a case with the developer to have it fixed.

3 Likes

Hmm, no not really. For individual plugin/vendor sandboxing it may be higher, yes, but for global sandboxing, be it all plugins coupled with the audio engine (WITHIN BITWIG mode) or decoupled from it (TOGETHER mode), the difference can be neglicible or even non existent. And thats what I actually proved.

That also makes sense, because there are only 1 or maximum 2 sandboxes going on.
This is a scenario in which one could always use sandboxing, for more stability and still same good performance. I see no reason to not use this all the time.

The comparison to Cubase was just to have a rough idea, but also I expected Bitwig to use more resources. Instead even with sandboxing it seems to be a more resourcefriendly DAW, which tells us, that sandboxing in general is not making a DAW too slow/hoggy for everyday (live) use.

A positive side effect of all plugins running in their separate process from the audio engine might be another step towards a gapless audio engine. So probably these both things go hand in hand, which would be a great thing and requested by a lot of people as well.

Here is some interesting information.
Today, Steinberg launched a new product named VST Live and guess what?

3 Likes

Not sure if this is the actual Sandboxing as we expect, but who knows :upside_down_face:

That said, this software looks like the holy grail for small shows, especially the Pro version with DMX. The manual don’t say much about DMX, I’d expect it to have a MIDI Remote integration of some kind, but they don’t say how we can control the DMX controls. Just with the mouse ?

@mlib @Louis_R is there any mention of a sandbox/crash protection?
I checked the infos on their website and their promotional video, but found nothing.

Yes, this would be a very useful feature.

1 Like

This would be very useful. :+1:

1 Like

I would definitely welcome anything to make Cubase more immune to crashes, at this point. And the ability to quickly/effortlessly identify which plugins are crashing it would be fantastic. Bitwig’s implementation looks great in that video.

3 Likes

Thanks, be sure to use the vote button if not done already :slight_smile:

yes, please!

1 Like

Bring it on Steinberg :wink:

1 Like

Yes! Please! add this plugin isolation layer… run plugins in a separate worker process…
this could be good, for everyone’s soul.

1 Like

this makes sense…

1 Like

Just to make sure that this doesn’t get forgotten and that some of you still get to vote… :wink:

Also, it fits because I just crashed Nuendo because of a plug-in. Good thing I am paranoid and saw the disaster coming. So I opened the new plug-in in a test project. :innocent:

1 Like