Hi everyone,
Most of Cubase’s crashes and serious problems actually come from third‑party plug-ins, and they end up ruining the user experience of an otherwise very solid DAW.
I’d like to raise a structural issue that affects Cubase/Nuendo and most traditional DAWs, and propose a possible direction that could really improve performance and stability.
Right now, the audio engine and all plug-ins (VST) run in the same main process and share the same real-time audio thread. Even with multi-processing enabled, there is usually one core that gets overloaded first, because critical parts of the graph (buses, master chain, long insert chains, etc.) end up running on that single core. When that core hits its limit, you get dropouts or overloads even though the total CPU usage of the machine is far from 100%.
On top of that, because plug-ins run in-process, any misbehaving plug-in (crash, memory corruption, deadlock, etc.) can bring down the whole DAW. It doesn’t matter if the rest of the project is stable, one problematic plug-in can freeze or crash the entire session.
Some modern hosts and tools already show that there are better architectures to deal with this:
-
Bitwig Studio has built-in plug-in sandboxing and different hosting modes. You can choose to run plug-ins “Within Bitwig” (classic mode), “Together” (all plug-ins in a sandbox separated from the audio engine), “By manufacturer”, “By plug-in” or even “Individually”, where each plug-in instance is isolated in its own process. If a plug-in crashes, only that sandbox is terminated and the main DAW keeps running; audio can continue and you only lose that specific plug-in until you reload it.
-
AudioGridder shows something similar from the outside: it runs plug-ins in a separate server process (local or on another machine) and the DAW only sees an AudioGridder plug-in. This lets you spread heavy chains across multiple cores and even multiple computers, and it also means that if one of those remote plug-ins crashes, it does not necessarily take down the DAW itself – you just reconnect/restart the server. It’s a very clear real-world example of how moving plug-ins out of the main DAW process helps with CPU distribution and fault isolation.
These examples prove that:
-
CPU load can be spread more flexibly across cores (and even across machines) when plug-ins are not tied to a single in-process audio thread.
-
A plug-in crash does not have to equal a DAW crash; the host can survive and keep the session running.
I know this is not a “small feature request” – it would require changes to the engine and to how VST hosting works internally. But I believe that true out-of-process plug-in hosting (with proper crash protection and better multi-core distribution), similar in spirit to Bitwig’s sandboxing modes or what users achieve today with AudioGridder, is the next logical step for Cubase/Nuendo’s audio engine, and would be a huge selling point for professional users working on large, complex projects.
It would be great if Steinberg could consider:
-
Providing an option to host plug-ins in separate sandboxed processes (configurable per project or globally).
-
Allowing different modes (all in one sandbox, per vendor, per plug-in, etc.), so users can choose the right balance between performance and protection.
-
Improving core distribution in combination with this, so that critical chains do not overload a single core while others stay underused.
If other users are experiencing similar issues (single-core overload, DAW-wide crashes caused by one plug-in, etc.), or are using tools like AudioGridder / other external hosts to work around these limitations, please add your vote or share your scenarios. The more real-world cases Steinberg sees, the easier it is to justify such a deep change in the engine.
Thanks!