Solution to crashes by plugins - Sandboxing (Crash protection)

Hi everyone,

Thanks for your invaluable ideas!

I can assure you your concerns are shared by everyone working on Cubase, as we rule out crashes reported to us on a daily basis that are in the end due to 3rd-party developers. This is not a blame shift, every one is human. Nonetheless not knowing that the plugin is the root cause of a crash is inefficient for everyone: our users, we, and also the 3rd-party devs who do not always hear from their own crashes.

We hope to bring some effective changes in this regard in the future.

Cheers,
Armand

8 Likes

Giving this a bump, because as the number and diversity of music software tools keep growing exponentially, more and more of us will have increased chances of encountering crashes.

It is certainly important to understand the cause of crash, so logging and reporting are quintessential. Feedback to developers, based on such acquired reports, is the next vital step in the chain. I would think most users reasonably know that.

With all that said, reading some of the comments, a rigid resistance to implement sandboxing may be unhelpful not only to Steinberg users, but to the computer-based music production community overall.

The fact is, no two computers will be exactly alike. Even if you have two identical pieces of hardware and install exactly the same software, DAW, drivers and plugins, there will be instances of diverging system behavior.

(Before someone accuses me of being an AI, I have been writing in-depth about technology and music production for years, way before Chat GPT even existed. I like to organize my thoughts in full sentences and paragraphs. And since I truly want sandboxing feature in my DAWs, I have to roll up my sleeves and make my case.)

A music production computer is basically, throwing some complexity science in there, a complex system. It has numerous, interdependent, interconnected, diverse, (but usually not very) adaptive components. An error in any of the elements can cause a “chaotic” ripple effect in the entire system. As in: crash.

Fortifying as many elements of this system as possible makes it more resilient and stable. With some of the loading times for more involved projects, it really does break your stride when a $999 MSRP piece of “professional” software unceremoniously crashes because of one seemingly benign plugin.

No DAW operates as an island. It relies on hardware, drivers, OS, plugins, audio interfaces, etc. I think it is a reasonable expectation that our tools have SOME level of resilience built into them.

Of course, everyone’s workflow is different. Some musicians like to experiment with a larger number of plugins and pick sounds or effects quickly and easily from a large available palette. Sentiments such as “Just avoid holding it in that way”, “these are not the DAWs you are looking for” or even “if this product cannot do it, why would anyone want to do it in life anyway” are for fan crowds, not for responsive, community-supporting companies.

Some plugins do not always crash, and sometimes they crash inconsistently, not always caused by the same activity. It is very beneficial to quickly identify the crashed plugin, either reload it, reload a different version of it, or swap it for a different one, without waiting to reload a DAW and an entire session. Certain virus scanners can cause some problems with DAWs and plugins. It is significantly more convenient to add an exception to a .vst3 file really quick without having to restart an entire session.

I know there are always those comments out there, even on official DAW vendor channels, that “Please contact your third party plugin manufacturer and ask them to update their product for full compatibility with our DAW.” When they say that, they cannot keep a straight face, because they even know how uphill-battle-ish it sounds. (I remember turning one vendor rep’s line into a looping meme with the pained expression on his face when he said that.) No, it is not to say that plugin vendors should not proactively improve their products, but as a music production computer is a complex system, the more players take the effort to ensure stability and compatibility, the better. Nobody cared who was to blame when a Mac OS upgrade regularly crashed the entire computer, caused by Mac OS, Logic, driver and audio interface not working together. (Yes, music production computers crash on ANY platform when you are around long enough. There is no “one platform to rule them all” that is guaranteed to work every time, all the time. If what you have right now is not crashing, good for you, but it is not the same for everyone.)

About the “but for goodness sake, think of the overhead!” flag; it is not fully such a judgment day scenario. For starters, sandboxing CAN be enabled or disabled. Furthermore, working with sandboxing DAWs, especially on today’s systems, there is just not this apocalyptic latency and CPU hit that people warn about. And even if there is SOME hit, at least give the users the choice.

Another argument I see on forums for multiple DAWs is “if they work on this feature, they will spend less resources working on the important features!” Well, if sandboxing is important to a lot of people, then probably it is worth working on it!

Supply, demand and free markets will to various extents play a role. It IS very common for people to switch DAWs. You read case studies of musicians, producers or studios switching to entirely new platforms, or watch their YT videos talking about it. I am not saying a software vendor has to jump on any feature request/suggestion it encounters, but it is worth communicating with the community and with other vendors and developers to see where the trends are going. Is it not a loyalty-inspiring selling feature that a DAW is stable and can handle those misbehaving little plugins?

Just food for thought.

3 Likes

Logic has plugin sandboxing. It works quite well.

The problem is plugin sandboxing did nothing to help with the audio interface and the driver. However, it is one of those things that we generally accept in music production: never upgrade to a new Mac OS immediately upon release. Wait a few months.

You’re right. But this way you could at least be sure the issue you’re having comes from the interface/audio driver and not some buggy plugins. When having crashes out of nowhere without any additional information, you’re basically groping in the dark, losing countless hours trying to fix it.

Being able to sort out all plugin related crashes reduces the vast amount of crashes out there, as only a few are related to drivers or interfaces.

1 Like

Excellent point, and to be fair, I definitely got a LOT of crash dump data on the Mac which I diligently submitted to various vendors. After a few months, all component vendors have caught up and things were functioning again (of course not because of my bug reports, but no doubt a whole community’s).

Interesting incident with a different DAW vendor: after sending them reports, they responded with something along the line of “we just released this new version, let the community enjoy it and let the developers take a break”. Which would be fine, but that is simply something you do not SAY to your loyal users. You take the reports, set them aside, give your guys a break, but not TELL your PAYING users “hold off with the bug reports”. I gave them two YEARS, they still did not have a stable, efficient product, and of course, no sandboxing. Needless to say, I stopped using that DAW, did not buy into their subscription plans or buy any upgrades and never recommend it to anyone. Supply/demand. Users do vote with their wallets.

On the subject of the Mac OS upgrades, the magic number became 3-6 months to apply a system upgrade after release. This exponentially reduced problems. But then of course the whole CPU architecture change, 32/64 bit, VST2/VST3, Rosetta/native debacle ensued, so incredibly, Windows became the more stable and reliable solution. The only incentive for Mac was Logic, and if it is not the primary DAW, then Mac is not such an absolute rule-them-all proposition. Whatever works for someone’s setup and workflow. In my current setup, I have sandboxing, VST2/3 and both 32 and 64-bit plugins work, and there is no architecture or Rosetta mess. It also did no cost like $7,200 for a fully spec’d machine, and if I want to upgrade a component, I do not need picks, pry bars, heat guns and an “I void warranties” geeky T-shirt! Bonus: more money left for… plugins!

I’m just here to add my VOTE, bookmark, and :heart:.

Please for the love of all things audio and DAWs, Steinberg, please just finally do this…2 or 3 versions later. A single plugin should not dictate a whole software application. Bitwig does rock in this aspect. Now that you are buddies with them, PLEASE pay them to consult and add this to Cubase. Thank you!

5 Likes

Happy New Year Bump to try and keep Sandboxing feature request on the radar.

May 2022-Jan 2025

4 Likes

Keep it bumpin in 2025 yo!

2 Likes

Agreed. This would be amazing. A single plugin shouldn’t be able to take down an entire DAW (and session). Would be very beneficial in identifying problematic plugins too… I’ve used up my votes already, but otherwise I’d vote on this.

3 Likes

Still hoping for this so my legacy plugins stop disturbing sessions

1 Like

@Martin.Jirsak - forum question:
Is - despite the high amount of votes - the implementation of this less likely, because the topic’s tag is reading “Cubase 12” (the most recent version, when the topic was created) instead of Cubase 14?

Since this is not yet implemented by Steinberg in Cubase 14, it would be a pity, if those votes “go to nirvana” just because an older version is tagged.
Not every member might still be using the forum to update tagging on their topics.

Just asking out of curiousity (and because strongly interested in this feature :wink: ).

1 Like

As a daily user of Cubase getting crashes too often I SUPPORT THIS TOO !

We do NOT need more compressors or reverbs BUT we need WORKFLOW AND PERFORMANCE IMPROVEMENTS.
I hope the content on the forums is watched daily by Steinberg operatives. We are helping them sell us a product … !!

2 Likes

You can always use audio gridder to host all your plugins if it’s an issue, that has sandboxing built into it with various options.

I’ve had reaper crash with rogue plugins the same as Cubase so I’m not sure I’ve found the sandboxing in Reaper any more useful than Cubase TBH. Unless it’s something you have to do on a plugin by plugin basis , which would be a PIA.

Bitwig performance on a new multi core CPU machine is poor compared to Cubase. Just look at various benchmarks no the internet and you’ll see Bitwig like Ableton is always behind in performance. They have other strengths of course.

M

Glad to see this was tagged with cubase 14 now.

I just want to throw this out there since I had an issue with Cubase scanning waves plugins recently on initial load. It was just stuck. No messages…nothing indicating why cubase could not complete the vst scan. I had to go digging in process explorer to see what the hell was up. the Steinberg vst scan process showed it was attempting to load the waves shell. Nothing had changed on any of my waves plugins. I had to force terminate everything in cubase. Then run the waves central tool…I guess it had an update. Then rerun cubase and it got through it fine.

My point is, if the cubase vst scanner is having a hard time scanning something, force some sort of dialog after a certain time where you can skip or get an idea of what plugin is having the issue.

2 Likes

I would love to see this feature implemented into Cubase. It’s super annoying when a VST instrument / plugin crashes the DAW. You never know how much work you have lost and never know if the project file will become corrupted to the point of being un-salvageable.

2025, Bitwig done it, Cubase/Nuendo 14 should be able to handle crash plugins far better. It’s easy to have the mindset of ‘well developers should code their plugins so they don’t crash’!However, thousands of lines of code will inevitably throw up problems now and then due to many factors.
Having a well conceived Steinberg take on VST Sandboxing for Cubendo would be really great.