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):
Thanks man, I wrote this on my first post:
also from my first post
we share same ideas brother
But, but, but
so why update all the plugins if an update can break them and cubase can never find out?
Because I believe every single update is better than the previous one.
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”
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.
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.
Yes and if you got a deadline it makes you nervous. Some will say you can go back to 11. Sure, I can even go back to 7 but that’s not ideal.
Same here, it’s not that I am blaiming the 12 update or something, it’s more of a discussion of how things will get better for the end user.
12.0.30 any time soon?
The first was concluded that is a non supported OS-cubase version missmatch.
Some other was related to Slate. Slate does not pass the VST-SDK test tool.
You only need to point out one specific to show your point, not list up a lot of crashes I dont intend do check all of them.
I’ll write it again: everything has the latest version installed!!!
I tried what Procdump generates, the result from ten starts:
6 x C:\Program Files\Steinberg\Cubase 12\Components\mediaservice.dll
1 x C:\Program Files\Steinberg\Cubase 12\VST3\VST Connect.vst3 2 x win32u.dll
1 x mswsock.dll
The MediaService always crashes in the same place, which is easy to fix (this is not a random error).
I am very curious when Steinberg will fix it.
Just choose any of those, if you say Slate plugins don’t count. How about you begin with Cubase crashing on exit?
What I found is that the update 12.020 changed something. Up until then I had no trouble. I hope that Steinburg will have fixed this issue with the next update. Of course, I’m not worried for myself, now.
At least one confirmed exit crash is confirmed to internal within cubase and occurs without any plugins at all.
Actually there are users which don’t have the problem whithout plugins, and others have it more frequently the more plugins are loaded into a project. Others have it only when certain plugins are loaded into the project and others don’t have it at all. And now?
I gave you a list of multiple threads, which all are related to issues with plugins which are NOT related to their GUI, not just this here. You said, just give me one. Well there are lots, everyday. Now if you are too lazy to look through them, thats not my problem. But then stop acting like the issues were not real.
I don’t have the time to continue this useless conversation with you, like on the sandboxing thread, where you clearly ignored what others were saying and tried to derail a FR, just because you don’t think its a thing. Lets stop here with this nonsense. If you think crashes of plugins are 99,9% related to their GUI, than thats good for you. Keep on closing your eyes and thinking that