Cubase 9's Plug-in Manager going wrong

[Jakob / Cableguys]

It's perfectly fine and great that Steinberg disables non-working plugins (which ehm, is a great innovation too..).

But it's bad that they disable perfectly working plugins. Period. I think there's nothing to argue about, is there?

[MirkoVanHauten]

I read, there are several problems with blacklisting plugins. It not only blocks those who crash, but also those that takes some time during initialization (like some high-level dongle protected plugins). Plugins that do not implement the vst rules very strictly can also be blacklisted. And, of course, there are many false flag alarms.
Steinberg recommends to update all plugins to their latest version. But often there are reasons why customers keep a particular version and will not update.

Some say that the Sentinel is also a sneaky way to check if the plugin can be a warez version. Regardless of the fact that warez su**s there are plugins that only exist with a cracked version (for example, if a company has passed out or they took a plugin out of the sale).

[chk071]

Nevermind, was writing nonsense here.

[chk071]

Some say that the Sentinel is also a sneaky way to check if the plugin can be a warez version.

As far as it is described on Steinberg's website, it's rather a sandbox kind of thing. And i don't think there is any reason to believe it to be a "warez check" of any kind, firstly, it would be pretty pointless for Steinberg to check on third party plugins anyway, and, secondly, i don't see how something like that could be implemented, it's not like the plugin shouts "Hey, look here, i am cracked!" anyway.

[MirkoVanHauten]

Some say that the Sentinel is also a sneaky way to check if the plugin can be a warez version.

As far as it is described on Steinberg's website, it's rather a sandbox kind of thing. And i don't think there is any reason to believe it to be a "warez check" of any kind, firstly, it would be pretty pointless for Steinberg to check on third party plugins anyway, and, secondly, i don't see how something like that could be implemented, it's not like the plugin shouts "Hey, look here, i am cracked!" anyway.

Yes I know. But on the other hand plugins can already do a self test to check if they got cracked uhe wrote about that. So there could always be ways for anything.

Anyways I just read that and summed it up to a post. Never been a Cubase user. Studio One ftw

[chk071]

Some say that the Sentinel is also a sneaky way to check if the plugin can be a warez version.

As far as it is described on Steinberg's website, it's rather a sandbox kind of thing. And i don't think there is any reason to believe it to be a "warez check" of any kind, firstly, it would be pretty pointless for Steinberg to check on third party plugins anyway, and, secondly, i don't see how something like that could be implemented, it's not like the plugin shouts "Hey, look here, i am cracked!" anyway.

Yes I know. But on the other hand plugins can already do a self test to check if they got cracked uhe wrote about that. So there could always be ways for anything.

If that is built into the plugin itself, and the dev who coded the plugin knows about the specific copy protection, and the way to get around it. Steinberg can't know which copy protection this or that plugin is using. Let alone check if it is a warezed version or not. And they won't have any reason to do so either. I think warez users can rest assured.

[noiseboyuk]

What makes me wonder is that Steinberg apparently thought, "Ok, if we blacklist plug-ins, then people won't use them anymore!"

I really doubt that's the case. Soon as a user sees their plug-in is missing, they are going to re-enable it. I don't know of anyone that's going to see that a plug-in they use is blacklisted and say, "Oh, great! Cubase thinks that plug-in that I always use is problematic. Alright, well I'll just stop using it then!" Yeah right.

It's a ridiculous idea.

My jury is out on this, but I'm leaning towards it being a good thing and here's why. It threw up scores of NI and iZotope plugins for me, which obviously was a problem. However, turns out all the NI plugs just needed an update which took minutes to fix, and that - according to Sternberg - iZotope plugs on a Mac running an OS prior to Sierra have an OpenGL issue which means they are unstable, and might cause performance issues on ANY version of Cubase without it being in any way obvious they are related to the plugin.

So let's think about that for a moment. The first complaint anyone has about their DAW is if the performance is compromised. Crashes, spikes etc that you can't get to the bottom of. Currently may main rig runs pretty well, but for no reason I get the odd debilitating spike that is no small PITA. Cubase is shit, right? Well what if it is caused by one rogue plugin that I use routinely, but have never diagnosed as a problem? The Sentinal becomes the primary tool for a reliably functioning DAW. So if I just throw up my hands at all the blacklisted plugins and say "what a ridiculous waste of time" and put them all back sighing heavily at the political correctness gone mad, I'm throwing away the one tool to solve my performance issues.

Now this is a best case scenario of the Sentinal, and it might be more hot air than I've just described - that's why my jury is still out. But if it means in practice that we get better stability by just updating plugs that Sentinal throws up (knowing we can take the risk for a while until they are updated if necessary), then it has to be a good thing, right?

[Jakob / Cableguys]

Again, can we agree: It's great that Steinberg blacklists unstable plugins. And it's bad that they blacklist plugins that are working perfectly fine.

I can see no benefit in disabling plugins that work perfectly ok. It just irritates users. And it adds an unjustified burden to our support Inbox. I also see no reason to update plugins that are several years old, just so that they pass Cubase's policy.

[noiseboyuk]

Again, can we agree: It's great that Steinberg blacklists unstable plugins. And it's bad that they blacklist plugins that are working perfectly fine.

I can see no benefit in disabling plugins that work perfectly ok. It just irritates users. And it adds an unjustified burden to our support Inbox. I also see no reason to update plugins that are several years old, just so that they pass Cubase's policy.

Do we know that's what's happening? I may have missed something, entirely possible. I don't think it's saying "oh dear, two years old, better blacklist it", is it? The point of my previous post really is the notion that plugins can cause instability in a session without it being at all obvious that it is in fact the plugin being at fault - which is what they say about the iZotope ones on certain OS Xs - https://helpcenter.steinberg.de/hc/en-u ... r-Cubase-9 . If this is in fact what Sentinel is going, it's performing a fantastic service.

So.... what do we know, factually, about how it determines a plugin's worthiness?

[Klinke1]

Sentinel it is just giving a hint about what plug-ins could cause problems.
You can activate them but if there are any problems you can try disabling these plug-ins and see if that is the root for the problem.

[aMUSEd]

Sounds a lot like Logic's au manager - very useful to be able to exclude buggy plugins

[swatwork]

Again, can we agree: It's great that Steinberg blacklists unstable plugins. And it's bad that they blacklist plugins that are working perfectly fine.

I can see no benefit in disabling plugins that work perfectly ok. It just irritates users. And it adds an unjustified burden to our support Inbox. I also see no reason to update plugins that are several years old, just so that they pass Cubase's policy.

Do you know why these plugins are being blacklisted? If you don't then your assertion that the plugins 'work perfectly' is just an opinion. It could be that Steinberg's scanner is being overzealous and needs fine-tuning but it could also be that your plugins are not up to spec and need updating to meet Steinberg's new acceptance criteria.

As an established developer I would have thought Steinberg would be happy to help you figure out why your plugins are being rejected, have you tried contacting them?

[hivkorn]

Again, can we agree: It's great that Steinberg blacklists unstable plugins. And it's bad that they blacklist plugins that are working perfectly fine.

I can see no benefit in disabling plugins that work perfectly ok. It just irritates users. And it adds an unjustified burden to our support Inbox. I also see no reason to update plugins that are several years old, just so that they pass Cubase's policy.

I only have 3 plugins blacklisted , i try to actived it and relaunch cubase , it cause instant crash during the initialisaton.

[aMUSEd]

Again, can we agree: It's great that Steinberg blacklists unstable plugins. And it's bad that they blacklist plugins that are working perfectly fine.

I can see no benefit in disabling plugins that work perfectly ok. It just irritates users. And it adds an unjustified burden to our support Inbox. I also see no reason to update plugins that are several years old, just so that they pass Cubase's policy.

Do you know why these plugins are being blacklisted? If you don't then your assertion that the plugins 'work perfectly' is just an opinion. It could be that Steinberg's scanner is being overzealous and needs fine-tuning but it could also be that your plugins are not up to spec and need updating to meet Steinberg's new acceptance criteria.

As an established developer I would have thought Steinberg would be happy to help you figure out why your plugins are being rejected, have you tried contacting them?

Does it provide any reporting functions like Logic's AU manager does?

[wagtunes]

As a Cubase 7 user, I am SOOOO glad I don't EVER have to worry about upgrading to Cubase 9.

What an abomination and abuse of power. Who the #$#% are they to tell me what plugins I can and can't use?

Un freaking believable.