Solution to crashes by plugins - Sandboxing (Crash protection)

What features and in what plugins?

I’m not sure you understand the concept of “sandboxing”. It is basically an additional host/abstraction layer in between the DAW and the plugin. The plugin itself wouldn’t know the difference between being sandboxed or not.

1 Like

There are many different ways. One is NLS plugins. I think waves, slate and brainworx have that. There is plugins that let same gui for sharing data. I think I saw that Fabfilter had for their EQ. There are plugins that uses thread pools like NI Kontakt. This does not in anyway conflict with the VST-SDK, but sandboxing is not part of the way VST works. (Nothing prevent Steinberg to add this, but then there is also a need to define HOW data should be shared between sandboxes)

So with your logic, Waves, Slate, NI Kontakt… they all don’t work in Bitwig or Reaper?

Are you familiar with NI Komplete Kontrol (there are plenty more examples I could use, but I’ll use this one). KK is a VSTi that acts as a VST host itself. Think about it. A host within a host.
I can load Kontakt instances, Waves plugins, you name it; in the Komplete Kontrol host.
If a plugin hosted by KK crashes, does KK crash, does Cubase crash as well as a result?
I don’t know. But I do know that KK could be designed so that a hosted plugin does not cause KK to completely crash.
A plugin sandbox as it relates to this discussion is a form of plugin wrapper and plugin wrappers have been around for a long time now.

Huh? Why does that need to be defined and who needs the definition?

1 Like

Yes, you can wrap vst in different ways. Novation did that with automap many years ago.
That was done without any sandboxing. It did never work very well. I have no idea if they work in Bitwig or Reaper. But with a true sandboxing they should not work as intended. Kontakt is probably only adding a thread-pool for each sandbox so it will only be overhead. (Their thread pool seems to cause a lot of problem for cubase 12.0 even without sandboxing)
The problem with that plugins something crashes is due to there are things that are undefined or they break the rules. The definition is need to make all hosts and plugins compatible with each other. The worst thing that can happen is that plugin vendors start to do different tweaks for each DAW or DAW vendors have special cases for some plugins.
Undefined behaviour is likely ending in a crash, and we do this only to reduce crashes.

Now you are talking about VST2.x / VST3 developer definitions within the API. Nothing’s changed in that department.
Again, a plugin does not know if it is loaded in a wrapper or in a DAW directly. The same applies for a sandbox wrapper. What they are saying in this thread is that Steinberg should implement a sandbox wrapper in Cubendo, not that they should change the VST definition to include a wrapper in the plugin itself.

1 Like

You’re clearly misinterpreting something here as was pointed out multiple times. There is no change to the plugin format or its API.
Would be nice if you could just stop derailing this FR. Thank you!

2 Likes

Then it will not work. It will be functional bugs. A sandboxed plugin can not interfere with other plugins thats the hole point with sandboxing, and some plugins use this interfere possibility to do its features. For sure some vendors will develop new ways to make it possible for plugins to communicate and that will cause performance and latency problems.

Well, dream on it wont work without API adaptations.

Yes it does.

And now please stop spread misinformation here.

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:






3 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.

2 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?

2 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 ?

@mlindeb @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