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 
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 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 
yes, please!
1 Like
Bring it on Steinberg 
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âŚ
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. 
1 Like
Thanks for the support. Imho this is a win/win feature for everybody. We would finally see which plugins are unstable and Steinberg wouldnât have to handle all the crash reports caused by those plugins.
2 Likes
VOTED! Ive been asking for this for years.
I was told via the steinberg FB page a while ago that this was on the roadmap but no ETA
1 Like
That would have been very good for cubase 12 (solving the problem with x86-only plugins in a rosetta sandbox). It would interesting to see if it also would have solved cubase gui sluggishness with a lot of plugins.
I really like the audio engine is a separate processes. With a good interface it would make it possible to have them separated on different computers too. Little bit like waves soundgrid.
But I did not see anything about a very nice feature that reaper has. It can resample plugins.
The plugins does not run with the same sample-rate as the host. It is very useful for plugins that have aliasing artefacts. Many of the Plugin-alliance sound much better with the aliasing are removed.