VST3 -> VST2 chunk compatibility

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

Either…
(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…

Hi,
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)
{
    switch (lArg)
    {
        case 'stCA':
        case 'stCa':
            switch (lArg2)
            {
                case 'FUID':
                    if (ptrArg)
                    {
                        if (vst3EffectClassID.isValid ())
                        {
                            memcpy ((char*)ptrArg, vst3EffectClassID, 16);
                            return 1;
                        }
                    }
                break;
        // ....

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.

@Arne_Scheffler I’ve implement the opcode-based auto-migration above but unfortunately neither Cubase 12 nor Reaper (latest) seem to want to perform the migration,
even though I see the vendor specific code is actually called by both.

Interestingly Cubase doesn’t list the VST2 version in the plugin manager if I activate this code.

I’m using the VST3 processor class ID.
Do you have any ideas please ?

So what’s happening in Cubase. You have a Cubase project saved with your old VST2 plug-in (without the ‘FUID’ opcode) and then you update the plug-in which now supports the ‘FUID’ opcode in the VST2 version and the project is loaded but without instantiating your VST3 plugin?

Exactly, the project gets loaded but Cubase says the plugin could not be found,
and the VST2 version is not listed in the plugin manager anymore.


image

If I enable IPluginCompatibility on the VST3 the VST2 gets replaced but that’s just the expected behavior of IPluginCompatibility .

Hi Lorcan,
the VST2 opcode stuff is for plug-ins that were not released before. It will not work to replace an already released VST2 plug-in this way with a VST3 one. You need to use the new moduleinfo or IPluginCompatibility interface.

I hope this makes it clear.

Cheers,
Arne

Ok, thanks, although I must say I don’t really understand how useful it can be in this case.

This was/is useful for plug-in developer providing for a new plug-in a VST2 and VST3 version which are compatibles.
a User A could use the Plug-in VST2 version in a Cubase project and give it to a User B which has only the Plug-in VST3 version, Cubase will load correctly the project.

1 Like

Thanks, that clears things up