A better way to manage 3rd Party plugin crashes

I wish if there was a feature or advance 3rd party plugin management to prevent the whole project/DAW from crashing because of faulty 3rd party plugins.

The problematic plugin could be disabled or paralyzed until it is re-scanned or inserted/reloaded.

Based on the forum, I am not the only one facing these uninvited crashes because of the 3rd party ARA tools or effects and instrument plugins. Sometimes corrupting the project itself.

I think the problem here is that VSTs are essentially callbacks running in the context of the audio engine and using the address space of the application. I think serious architecture changes would be required for this.

I don’t know how effective it is, but Bitwig Studio somehow managed to pull that off! I’ve tried several DAWs, but I always comeback to Cubase because of its extensive features and workflow that it provides. No other DAW comes close to it. The only issue that I face frequently is the crashes, that too because of the 3rd party plugins.

Bitwig Studio runs the plugins in a separate process. There’s some overhead to that, but it keeps the main process from crashing.

I have no idea if Steinberg could/should/would do this, but it’s a pretty significant change to do something like that, as you need to have cross-process calls added into the audio engine.

Pete
Microsoft

It’s not a simple thing to add, but it can be done and, as you say, other DAWs have this feature.

I would just add that I’m quite certain nobody wants this feature in Cubase more than Steinberg :grinning_face: . I would guess probably 50% of their support calls are due to an errant 3rd party plugin causing Cubase to crash. The fact that they haven’t added it speaks to how difficult it would be to retrofit into Cubase.

I just hope that the developers are working on it. It’s embarrassing to experience crashes in front on my clients every now and then.

Cubase closes itself sometimes, or it would just become non-responsive, forcing me to use the Windows Task Manager, then re-start Cubase and wait for 10 to 15 seconds, then select the project file or it’s back-up, then wait for a few more seconds to finally get into the project. Sometimes it requires disabling all the 3rd Party Plugins. NOT TO FORGET! ALL OF THIS DRAMA OCCURS IN FRONT OF THE CLIENTS! :smiley:

Many of us have felt this pain periodically!

Better partitioning of VSTs from core code certainly has its benefits. However, it also comes at a performance cost as audio buffer contents get copied between application space and VST space.

In theory, this separation is great! In practice, the solution to this comes with its own issues.

As for the “client” visibility, arguably a crashing VST might be less embarrassing in front of a client than the application crashing entirely, or not. It could still cause audible problems with your mix, depending on the role of the problem VST in your signal chain.

Being able to reliably determine that a VST is causing issues and eliminating the VST from your workflow would be invaluable. However, for those already having resource issues in their Cubase projects, these changes might exacerbate their problems.

The devil is in the details!