VST3 plugin not recognized as the same after recent commit

Audio Plugins
1

After 6b08ced (VST3: Add support for parameter migration), Cubase doesn’t recognize my plugins as the same. Plugin and manufacturer code, plugin uid and JUCE_VST3_CAN_REPLACE_VST2 haven’t changed, and yet projects saved for the previous build won’t load the new one.

1 Like
2

Did you read the details in BREAKING_CHANGES.md? This might have an impact:

Change

The return type for VST3ClientExtensions::getCompatibleClasses() has changed from a String to an array of 16 bytes.

Possible Issues

Any inherited classes overriding this method might fail to compile.

Workaround

Either explicitly switch to creating a 16-byte std::array or use
VST3ClientExtensions::toInterfaceId() to convert a string to a 16-byte array.

Rationale

As part of adding functionality to support migrating parameter IDs from
compatible plugins it was useful to switch to a safer type for representing VST3 interface IDs that closer matches the VST3 SDK types.

3

I read them. The plugin compiles, so failing to compile is not an issue. I also don’t inherit from VST3ClientExtensions. I imagine something about this may have changed some ids somewhere, but not the plugin uid, which remains the same.

4

CMake or Jucer project? Did you add a version field to PluginID in your processor constructor?

5

Jucer project. None of the plugin information shown in hosts or set in the Projucer has changed. The jucer project hasn’t changed, and the commit doesn’t change Projucer code. I set nothing like that in the processor constructor. It’s just the same exact project.

6

Try adding the Version field in ParameterID, rebuild, and see if you get a different result.

Also, what does auval/pluginval tell you about your build?

7

Those were already set for all parameters. They’ve not changed either. pluginval doesn’t complain, and I’m on Windows, so no auval.

8

@kamedin let me see if I can reproduce the issue you’re seeing, before I do that though I have a few questions.

  • Have you got both a VST2 and VST3 plugin installed at the same time?
  • Are sessions saved with the VST2, VST3, or both having issues?
  • Is this only an issue on Windows?
  • Which version of Cubase are you using?
  • Have you tested with any other DAWs?

Thanks.

9

I have both VST2 and VST3 installed at the same time. All sessions are saved with VST3. I can only test on Windows. I’m using Cubase 14. I’ve not tested on other DAWs yet, may do that tomorrow. If I compile with the tip of develop with this commit reversed, create an empty Cubase project, add a track with the plugin as an insert, save the project, recompile with the commit readded, and open the project saved before, the plugin is marked as not found.

10

It might be interesting to build and try out a copy of the VST3Inspector project that’s part of the VST3 SDK (info here), which shows the UID of each plugin. This should allow you to compare the UID after building with JUCE 7 and JUCE 8.

It would also be helpful to know what preprocessor/module flags you’re using, just in case some flag is having an unintended side-effect.

1 Like
11

I’ll try everything tomorrow when I’m back at the studio. I thought the uid wasn’t changing because it appears as the same in VstPluginInfo.xml, where Cubase saves it, but now I think maybe it wasn’t being rechecked. This is all 8.0.4 though -the tip of develop with and without this commit.

12

Just to say I think I understand the issue now I’ll try to get something up ASAP likely not until tomorrow at the earliest.

2 Likes
13

Thanks again for reporting this should be fixed on develop now

2 Likes
14

Endianess being different for Windows and Mac? And only for the first two words? Is there a reason for that? Does the Steinberg documentation explain?

15

It’s based on this code

Note that COM_COMPATIBLE is only defined 1 for Windows in this file

16

As far as I remember (and I’m quite old), this was caused by a bad decision made when the vst2 sdk was available for PPC Macs and 32-bit Windows XP 20 years ago.

2 Likes
17

Just to report it’s working now. Thanks!

1 Like
18

I am seeing a new problem with this. I can no longer build a VST2 on the develop tip using MSVC 2022 due to the rewrite of “nasty old-fashioned code” that was perfectly working.

Line 79… of juce_PluginUtilities.h

        const auto uidString = VST3ClientExtensions::convertVST2PluginId (JucePlugin_VSTUniqueID, JucePlugin_Name, VST3ClientExtensions::InterfaceType::component);
        MemoryBlock uidValue;
        uidValue.loadFromHexString (uidString);

uidString is not a string, but a std::array<std::byte, 16>;
loadFromHexString wants a StringRef.

How could this ever compile? Compilation is only attempted when doing a VST2 with JUCE_VST3_CAN_REPLACE_VST2 build btw.
There is also an issue with zero termination here that might lead to allocating a random amount of memory when loadFromHexString does ensureSize(…), and the array is probably not zero terminated.

1 Like
19

Just looking now looks like that one escaped CI because it’s behind two build flags, at one point convertVST2PluginId was returning a string.

1 Like
20

Is there any reason why the CI does a VST2 test without VST3_CAN_REPLACE_VST2? Shouldn’t that be the default case for VST2?