Cubase 12.0.51 maintenance update

The 12.0.51 maintenance update is now available. We have received reports about issues with ADM exports and decided to release an immediate hot fix.

Please find all details below in the release notes:

The update is immediately available for download via the Steinberg Download Assistant.


thank u steinberg team for the very fast release


Is it possible to have some clarity on what this improvement entails?

“We have improved the automatic replacement of plug-ins in older projects when newer plug-in generations are available.”

Searched the forum but can’t see any obvious issues relating to this. Is it just a VST2 → VST3 thing?

1 Like

Will this fix the problems of not being able to get certain things working with the remote app or is it just to keep the remote programmers happy in their playground while we struggle to get controllers to work ?

“We have improved the automatic replacement of plug-ins in older projects when newer plug-in generations are available.”

Thanks a lot this is a great time saver :upside_down_face: Considering that there are other modern DAWs out there that are still not capable to do this…


The VST 3 SDK now provides a file that allows developers to tag their VST 3 plug-ins as a replacement for another plug-in (for example, an older VST 2 version), even if they have different UIDs.

This is currently supported by Kontakt 7, which can replace Kontakt 5 in older projects/templates. Deleting the Cubase Pro VST3 Cache folder might be necessary to trigger a plug-in rescan if you already have Kontakt 7 installed.


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.