DAWs do not recognise VST3 as same plugin after migrating to JUCE6

General JUCE discussion
1

In the process of updating plugins from JUCE 5.2.1 to JUCE 6.0.1.
Moving to a full CMake setup but something isn’t quite right.

I’ve attempted to move all of the configuration from the .jucer project but perhaps I’ve missed something.

The filename is the same.

I checked the contents of the .vst3 directory (mac) and found a few difference:

  1. Info.plist has quite a few differences
  2. Resources dir exists in old VST3 but not the new
  3. access permissions are different

I attempted to correct all of these differences by hand (align Info.plist, copy Resources dir across, and fix permissions) but still no luck.

Any suggestions?

1 Like
2

Are you definitely using the same PLUGIN_MANUFACTURER_CODEs and PLUGIN_CODEs as the old Projucer-based plugins?

3

Yes, PLUGIN_MANUFACTURER_CODE and PLUGIN_CODE are identical (unless I’m missing some nuance).

Is it possible I’ve missed some other configuration option?

4

One thing you could try to check for differences is to load both plugin versions in the JUCE AudioPluginHost, and then to check the information displayed in the list of known plugins (Options -> Edit the list of available plugins…). If everything appears the same, you could stick a breakpoint on line 195 of juce_KnownPluginList.cpp and check the contents of the found OwnedArray after dragging and dropping each plugin version into the AudioPluginHost window. Ideally, the PluginDescription structures for both plugins should be identical.

1 Like
5

Excellent advice. Thank you!

Definitely got a little bit farther with it. The VST3 type was not set and defaulted to “Fx”.
However, the pre-JUCE6 plugin has:

Category: Spatial|Fx|Ambisonics

However, when I set: VST3_CATEGORIES Spatial Fx Ambisonics
the order in AudioPluginHost becomes: Fx|Spatial|Ambisonics

I am not sure if this incorrect order is a problem (and VST3 is still not recognised as the same plugin).

Note: In CMake API.md, VST3_CATEGORIES does not include “Ambisonics”. Perhaps this is an issue?

I will try the breakpoint suggestion you made and get back to you.

6

You could try setting it in your extra preprocessor definitions and specify the order you want, e.g.:
JucePlugin_Vst3Category="Spatial|Fx|Ambisonics"

7

This is probably not a good idea. JucePlugin_Vst3Category is already set by the Projucer/CMake, so defining it again will lead to duplicated or inconsistent definitions.

8

Perhaps then we could be given a way to re-order the categories which have been selected.

9

It’s doubtful that the order of those has any importance at all.

10

Last time I looked into this the first you list is the only category Cubase will show your plugin in, which isn’t always the preferred category. Being able to control the order would help.

11

Ah, well, if that’s true, then that would be a nice improvement. But in the context of this thread, it’s not likely relevant to a VST3 plugin not being recognized at all. (Debugging the creation of the plugin might help spot where it’s failing.)

12

If everything appears the same, you could stick a breakpoint on line 195 of juce_KnownPluginList.cpp and check the contents of the found OwnedArray after dragging and dropping each plugin version into the AudioPluginHost window.

The only difference I could find when doing this is the category. However, I rebuild my plugin after modifying JUCEUtils.cmake to hardcode the category and this still has no impact on the plugin being recognized.

13

ah, perhaps I’m misinterpreting you but the plugin can be loaded without a problem (it is not “not being recognized at all”) it just isn’t recognized as the same plugin compiled with JUCE5 (and no CMake).

Which is problematic because any saved DAW sessions will break if we send out an update.

14

Is this affecting your VST2, AU and AAX versions too or only the VST3?

15

AU works correctly.
Have not yet setup VST2.
AAX fails as well (Pro Tools actually says it’s not a valid plugin and refuses to allow me to load it).

16

VST2 appears to backwards compatible.

AAX I have not tested yet.

VST3 is still a problem.

17

There is one crucial difference I have been able to find:

For the VST3 plugin produced with JUCE6 + CMake, the plugin presets seem to be included in a list with the heading Factory Presets (in Reaper, all these Factory Presets are under the heading --- VST built-in programs ---).

However, the older version of our plugin uses presets installed on the filesystem of the machine.

Any thoughts about what could be producing this difference?

edit: found the culprit for this but it does not seem to be the problem.

18

Glad you found the culprit, I was just investigating but didn’t get very far. I’d be interested to know where the difference comes from if you don’t mind sharing.

19

Oh, sorry, I meant: found the culprit for the --- VST built-in programs --- difference between plugin versions.

Still have not figured out why backwards compatibility is broken :frowning:

20

This is why a CMake exporter in the projucer for migration into the new CMake world would be great. I fear similar issues when moving the CMake.

I’m sure there are a lot of projucer plugins that need to be ported to CMake in the next years. It would be a huge time saver and the JUCE team also can deprecate the projucer somewhere in the future with a good migration path this way.

3 Likes