Sure it is for developers. But it easy enough to check that the plugin is reasonable right. And many of the plugin vendors does not work with the tool. Waves for example fails and they dont even care.
1 Like
Hi,
Unfortunately this is not so simple. Cubase has 2 factors of VST plug-in verification. The “big one” is triggered when a new plug-in is loaded to Cubase for the 1st time. If this test doesn’t pass, the plug-in becomes blocklisted. Once the plug-in has passed this big test, there is only fast-check test during the next starts. Unfortunately if you update any plug-in, Cubase cannot recognise, this is an update (something has changed in the plug-in). So even in this case only the fast-check test has been triggered. But if the update breaks the plug-in (so it wouldn’t pass the big test), Cubase can’t find it out. The only way would be to trigger the big test manually from the Plug-in Information window.
And of course, as always, even the big test doesn’t test everything (this is just impossible). So it might happen, the plug-in is crashing even though the test passed.
There is a lot more needed that “don’t crash” for a plugin to classed as properly working. Bur sure it is good to screen off the real bad ones with some checks.
Try to close project without closing Cubase, then open new empty project, close it and then close Cubase. It will quit without crash. I did this many times, but anyway I don’t like this bug and while Cubase 12 Pro isn’t really Pro, I use Cubase 11 Pro which works perfectly on my setup.
2 Likes
And how do you do this? By clicking on File->Close project?
Because usually when clicking on the red X on the upper right, only the project should close, leaving Cubase running. But thats exactly what is buggy
Yes, this is understandable. But also it is not the users job, to fiddle around with developer tools, when a program crashes.
Using the test tools for VST3 is a good way to see if the plugin vendor is a idiot. If you then still continue to buy from that vendor you are in the same group.
1 Like
And how many times is this the case? Plugin vendors which sell obviously crashing plugins lose business anyway and get a bad reputation. Also if someone buys before trying and then continues doing that with those plugins, then he/she* is just stupid. In that case there is no such test tool needed.
But this is not what happens most of the times. 90%+ of the times these crashes are caused when doing a certain combination of things on the plugin GUI, or just sporadically (it seems). There are also cases, where certain plugins have issues only in combination with other plugins loaded in the project. This application is fine for general testing, but not really for real life use.
Also it is a dev tool, usually not meant for the normal user and also not easy accessible.
The big issues are not caused by plugins which clearly crash, these are easy to sort out, instead its those times where Cubase closes out of nowhere (like it is the case here), often without a crashdump.
For some reason it seems like that vendors that works flawless with the test tool is also working as good as any Steinberg plugins. However the tool should benefit from automation and test schemas. And the test tool is not focused on crashes. But it test interaction with GUI and 99.9 percent of plugin crashes are in GUI not in audio processing path.
I would not agree. there are at least as many random crashes not having to do with the GUI of a plugin. Just look at this Thread here.
I am pretty sure a plugin GUI has nothing to do with the crash on exit, which is actually one of the top reasons why cubase crashes, according to the forum.
Also there are multiple threads on the forum, where random crashes happen, without any connection to a GUI.
Can you point to any crash updated to this forum that is a crash in audio path?
The only one talking about crashes in audio path is you.
How about you read again what I wrote?
So where are they?
Sorry, but claiming that
is just hilarious and all but true.
You could also use the search button.
These are all non GUI related issues with plugins, just from the last couple of days (there is also an crash issue I had with some slate plugins, which is in there, which was not GUI related):
Crashes when activating instrument tracks, too often to be random - #4 by Lorenz_o
Thanks man, I wrote this on my first post:
Also
exactly
also from my first post
we share same ideas brother 
1 Like
But, but, but
so why update all the plugins if an update can break them and cubase can never find out? 
Hi,
Because I believe every single update is better than the previous one.
1 Like
Yes, of course you do, we most do.
But we are talking about finding a solution for the plugins that crash inside cubase.
It doesn’t matter if we do update them because cubase will still don’t know why it’s crashing, so we are only hoping that the vst vendor will do some magic and cubase will not crash.
Instead of cubase doing something to not crash since same plugins won’t crash other DAWs as mentioned.
All I want to say is that we can blame Vsts which generally don’t work, because of bad coding etc but not the ones that run smoothly with other DAWs.
And saying “please update your vsts” is a solution to a problem but it is also an excuse for the host not working. It’s like saying “cubase is fine, your vsts are the real problem”
1 Like
Thats exactly what I was thinking. I mean, it is possible you are working with 100 of different plugins in total (or even more), maybe not in one project, but in different projects and genres.
Assuming everything will always work, especially after installing updates is insane. Thats why this DAW needs no be prepared, when there are some 3rd party apps making trouble. There is a solution to this and other DAWs have implemented it. Its about time to stop blaming the others and to make sure Cubase runs no matter what.
If then there are plugins crashing, which then have to be reloaded without being able to crash Cubase anymore, well then Steinberg can proudly blame whoever 3rd party vendor they want.
1 Like
I have had that exact same problem. I used a method whereby I downloaded ProcDump from the microsoft website. Martin.Jirsak, from this forum, sent me an email with the info on how to operate it.
So, you start Cubase and immediately run Procdump. What happens is Procdump runs to where cubase freezes, then stops, but Cubase magically keeps running and skips the the problem VST. I discovered that even though I had quit using WAVES plugins around the time of Cubase 10.5, and deleted them from my system, buried deep in the folder chain, was a Waves file, not even a VST. I deleted this file and it proved to be the bad guy. Since then C12 has worked perfectly. Where Cubase is falling down, in my opinion, is it’s inability to broadcast when it finds a faulty plugin ( or anything else ) during initialization, but keeps running, having skipped the problem. There is enough people having this problem on the Forum now, that Steinburg needs to seriously look at this. I recon I have lost 2 or 3 days of production with this and it’s damn annoying. C12, itself is a wonderful update and I’m sticking with it for now.
2 Likes