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 ?
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 ?
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.
thatâs incredible. If I wouldnât have posted a meme in the Cubase users facebook group today, this would have completely gone unnoticed
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
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.
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.
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
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!?)