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
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
SOLVED! Thank you!!!
2 Likes
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 
4 Likes