A customer has written in concerned about the recent Steinberg announcement that upcoming Steinberg hosts will drop VST2 support. As part of our discussion about chunk recall, he said this (about Cubase):
“if I have a plugin with both VST 2 and VST 3 installed, and the used version is the VST 2 in the project, if I remove the VST 2 version (from the VST2 folder), the VST 3 version of that plugin is automatically loaded in Cubase”
I cannot see how this can be possible, because it would require…
(a) the host to know which VST2 IDs somehow match to VST3 IDs
(b) assume chunk compatibility between VST3 and VST2 which obviously cannot be safely assumed
(1) the customer is wrong, and therefore Steinberg dropping support for VST2 will kill users old songs
(2) there is something in the VST3 sdk to map ids and chunks which I am unaware of. If so please point me in the right direction…
please read this section in the documentation.
If you already released a VST3 version of your plug-in with a different UID to the VST2 one, you have to wait for the next SDK update which will include documentation and a new API for a VST3 plug-in to declare UID’s of VST2 plug-ins to replace.
Note that we currently don’t support remapping of parameter identifiers in this case.
@Arne_Scheffler I though the VST2 code below as mentioned in the docs, alongside VST3::tryVst2StateLoad was enough or did I miss something ?
VstIntPtr Vst2Wrapper::vendorSpecific (VstInt32 lArg, VstIntPtr lArg2, void* ptrArg, float floatArg)
if (vst3EffectClassID.isValid ())
memcpy ((char*)ptrArg, vst3EffectClassID, 16);
This works if you plan to update the VST2 plug-in. But if you don’t plan to update the VST2 plug-in and have released a VST3 plug-in with different UIDs then there’s currently no way to handle this. This use case will have a solution in the next SDK.
Ok, thanks, yes I do plan to update the VST2 as I bundle them with the VST3 in the installer anyway.