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

General JUCE discussion
#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
#21

Kunz I couldn’t agree more. Until this kind of stuff is resolved there is no way I can migrate to CMake… It’s just too risky as breaking user projects is about the worst thing that can happen to a plugin manufacturer.

2 Likes
#22

I’ve investigated this a bit now. I created a plugin project using JUCE 5.2.1 and the corresponding Projucer version. I created a Reaper project using this version of the plugin. Then, I wrote a CMakeLists for the same project using JUCE 6, built and installed the plugin, and then tried to re-open the Reaper project.

At first I was seeing the same issue that you’re seeing. After some debugging I realised that the VST3 UIDs were different for the different plugin versions.

When I modified the CMakeLists to include JUCE_VST3_CAN_REPLACE_VST2=1 in target_compile_definitions, the UIDs matched again, and Reaper loaded the JUCE 6 plugin correctly. I also needed to call juce_set_vst2_sdk_path pointing to a local copy of the VST2 SDK in order to build with this flag enabled. Can you check whether you’re using the JUCE_VST3_CAN_REPLACE_VST2 flag?

3 Likes
Is there any way to enable JUCE_VST3_CAN_REPLACE_VST2 after release?
#23

SOLVED! Thank you!!!

2 Likes
#24

This hit me as well – but the other way round. Just wanted to leave it here in case anyone else runs into this, as it took me an hour of work now to find this out.

In my case, the previous Projucer project had this config option set to 0 which I overlooked when porting the project since I did not expect the project to have this flag set to any special value. Therefore, in my CMake project, I didn’t set this config flag at all. But in the juce_audio_plugin_client module header, the flag is defaulted to 1 in case it’s not specified. Explicitly setting it to 0 solved the issues and my old test sessions successfully loaded the plugin again.

Lesson learned: Check ALL your module flags for non-default values when porting a project from the Projucer to CMake :wink:

3 Likes