How to debug recognizing new VST3 plugin for old? [SOLVED]

We’ve got an old VST3 plugin that we’ve updated to JUCE (5.3.2), but the VST3 version is not being recognized on the PC as a replacement for the old one. On the Mac, it works with no problems, but not on the PC.

I’m unsure how I can tell what is going wrong, but I suspect that it has to do with the registration of the processor and/or editor component classes. The old method of generating the UID was to use a macro called DEF_CLASS2:

	DEF_CLASS2(	INLINE_UID( 0x4A40DB94, 0x2034456E, 0x8C943958, 0xDB9461F5 ),
				PClassInfo::kManyInstances,
				kVstAudioEffectClass,
				"OurPluginName",
				0,
				Steinberg::Vst::PlugType::kFxPitchShift,
				FULL_VERSION_STR,
				kVstVersionString,
				MySingleComponentEffect::createInstance )

This allowed us to use the VST3SDK’s “SingleComponentEffect” class to combine the processor and editor into a single class. To make this work (on the Mac) in JUCE, I added this code to the VST3 wrapper:

    #if (defined(OLD_VST3_IDLONG1) && defined(OLD_VST3_IDLONG2) && defined(OLD_VST3_IDLONG3) && defined(OLD_VST3_IDLONG4))
//
 DECLARE_CLASS_IID (JuceVST3EditController, OLD_VST3_IDLONG4, OLD_VST3_IDLONG3, OLD_VST3_IDLONG2, OLD_VST3_IDLONG1)
 DEF_CLASS_IID (JuceVST3EditController)

 DECLARE_CLASS_IID (JuceVST3Component, OLD_VST3_IDLONG1, OLD_VST3_IDLONG2, OLD_VST3_IDLONG3, OLD_VST3_IDLONG4)
 DEF_CLASS_IID (JuceVST3Component)
#else
// end changes (top part)
#if JUCE_VST3_CAN_REPLACE_VST2
...

(Since we can’t use the same UID for both components, we simply reversed the order of the editor component’s hex values, to (hopefully) generate a different unique ID.)

As I said, on the Mac, this works. But neither Cubase 10 nor Studio One 4 see the new plugin as a replacement for the old one on the PC.

I don’t know what the problem is, and am having trouble trying to figure out where it fails. (By the way, the plug-in name has changed between the old and new versions, but that doesn’t seem to matter on the Mac.)

How can I tell what the problem is, if the host doesn’t see my plugin as a replacement? It doesn’t seem to call any of my code when loading the old session, so my guess is that the initial class registration (when opening the DAW in the first place) is where it fails, possibly by producing a different UID than what the old session specified. But that’s just a guess.

If it was the name, then why does it work on the Mac? Simply changing the name of the resulting .vst3 file does not fix the problem, but I haven’t tried changing the name setting inside the JUCE project, to see if that fixes it. But we’re renaming the product, so not changing the file name is not a desirable option (especially since some DAWs display the file name as the plugin’s name).

Any ideas how I can find the problem on the PC side of things?

Using the VST SDK’s plugin host, I was able to examine the IDs that the host sees our plugins report, and found the problem. It turns out that the old plugin used different IDS for Mac and PC! So in order to maintain backwards compatibility, I need different IDs generated for Mac versus PC as well. Doing that resolved the problem. (Although this means that saved sessions are not cross-platform compatible, at least with host that use the Processor’s ID to identify the plugin).

1 Like