Cubase 12.0.51 maintenance update

it’s still not entirely clear when or if this happens ? And there doesn’t seem anything in the documentation to see how that works with Cubase/Nuendo

Is it automatic ?
Will this happen if I have Kontakt 5 (and 6?) and Kontakt 7 on the system - will a substitution occur ?
Will Cubase/Nuendo warn me it has happened ?

EG - I have some libraries that work fine in K5 but don’t work in K6/7 - I don’t want it to be automatically substituted.

basically - is there any documentation for this ‘hotfix’ change ?

1 Like

Oh that’s really good to hear. Let’s hope developers, where applicable, embrace this. :+1:

1 Like

If you still have Kontakt 5 on your machine it will use it and not replace it automatically with Kontakt 7.
If it will be replaced you will get a notification during loading a project.


thanks Yvan

now if it had just said that in the release notes :slight_smile:

that’s incredible. If I wouldn’t have posted a meme in the Cubase users facebook group today, this would have completely gone unnoticed :stuck_out_tongue:

how well do you think the VST replacement feature might work? if it is what I think it is, it would make it easier for us to replace older VST2 versions of plugins with newer VST3 counterparts - correct? if so, THANK YOU SO MUCH :raised_hands::pray:

From what I understand, Steinberg implemented a feature in the programming environment that VST plugin devs use, and it is up to those devs to configure it according to the needs of their customers and their products.

It will work very well if the plugin developer takes the time to configure the feature.


This was already available and working fine in most circumstances. Most developers used the same UID for VST2 and VST3 and so the transition should have already been seamless. In fact you’ve probably noticed that if you have a VST2 and the same plugin in VST3 that cubase ‘hides’ the VST2 plugin from you (in most cases!)

Some plugin developers don’t do this unfortunately…and it’s annoying. It’s possible/probable that those same developers will keep making life difficult by not implementing this new(ish) VST3 feature .

The latest VST3 SDK means that the plugin developer has more options to tell Cubase/Nuendo that the plugin is an equivalent, not just VST2 > VST3 but also from different version of VST3. Although currently I can only think of NI Kontakt that this VST3 equivalence might be useful for…and that’s because the made a bit of a mess of the plugin name.

It also means that plugin developers can fix the mess they have already made using different UIDs for VST2 and VST3 without breaking backwards compatibility.

ALL of this requires the plugin developer to implement it - it’s not a ‘automatic’ thing.

but yes, it’s useful addition :+1:

1 Like

Thanks for clearing that up! Makes sense of course.

As far as I remember, PSP Audio and Softube also used differents IDs for VST2 and VST3, so they both could also benefit from this feature if implemented. And maybe Guitar Rig 6 VST3 to automatically replace Guitar Rig 5 VST2.

Sorry for not understanding, but this sounds to me like the user may not have control over the process - they would simply “get a notification” that a replacement will take place.

Is that incorrect?

Thank you!

I was referring to VST3 to VST3 equivalence when I mentioned Kontakt as they have Kontakt 5, Kontakt, Kontakt 7 etc (all VST3) although on reflection Izotope could do with quite a bit of tidying up too :slight_smile:

re: VST2 to VST3 differences in UID - there are quite a lot, recent Spitfire Audio stuff, U-he, Korg (IRRC), Relab etc etc. Fortunately they now have a way to fix up the mess going forward.

That assumes that the data saved in the project is compatible between VST2 and VST3 and that’s not always the case - which is why some use different UID (I think!?)

fyi Kontakt 5 is VST 2.4, Kontakt 6 and 7 are VST 3

1 Like

These developers also had option for note expression support. :slightly_frowning_face:

Needs other DAWs to adopt this new change to the SDK for it to be utilised, or else developers won’t necessarily implement it.

ahh yes, I forgot NI were late to the VST3 party :slight_smile:

Maybe Izotope would be a better example - every release give you a full set of new plugins but they are 90% the same plugins - Although that situation would be better dealt with by Izotope not pretending they were new :smiley:

I’m not sure how much of the changes are backwards compatible between different host DAWs - Most VST3 are not running the same SDK build so they don’t need to match ? Do they just ignore the stuff that the host can’t handle ? not sure ?

anyway enough of a thread derail in this one :slight_smile:

yep :+1: (@steve already pointed it out)

my point was more that this was already possible with the earlier SDK for vst2 to vst3

I hope Guitar Rig 5 and 6 are compatible enough to benefit from this feature. It would be a timesaver for old projects having Guitar Rig 5 VST2 automatically replaced.

1 Like

That’s modern agile development cycles applied to Music sofware, looks like Steinberg devs are raising the bar and setting an example to all competitors!

Thank you again Steinberg!

1 Like

hoped that the agile development method of timely problem solving can last forever

It is definitely useful, but I guess unless JUCE implements support for that feature, the majority of plugins probably won’t really use it.

1 Like