Ok so since we previously were not using VST3_MANIFEST_ENABLED the lines below were not added to each configuration’s section in the generated build script. Now that they are added it fails because juce_vst3_helper is not in the path for whatever reason:
CMake should automatically insert the correct path to juce_vst3_helper in the post-build script. Have you tried reconfiguring the project from scratch, i.e. generating a whole new build folder, rather than reconfiguring an existing build folder? If so, do you get the same result?
I confirm there’s an issue with juce_vst3_helper - I cannot compile vst3 on a mac (error is thrown) and in PC it “seems” to compile, but when I go and check, the vst3 is a folder (?) and next to the VST3 folder there’s a folder called VST3 Manifest Helper with file juce_vst3_helper.exe in it.
The way I “solved” it was to use the ‘release’ version of procujer.exe placed in the development branch folder, I am not sure if there is any conflict, it seems to work, but I assume this doesn’t cut it.
Additionally, for some reason, a “VST3ManifestHelper” is added in the solution while it didn’t exist on the ‘release’ version of juce
The manifest helper is a recent addition. The manifest helper is a commandline tool that loads the built VST3 and generates a manifest file (moduleinfo.json) that lives inside the plugin bundle. The purpose of this file is to allow hosts to scan plugins without needing to load them, which should speed up plugin scanning for hosts.
Will get back to you reg. all the questions when at the office, but for now I can tell you that:
The plugin is an ‘old’ plugin that compiles perfectly fine with the current release version of juce… if I use the “release” version projucer using the dev. branch files, it compiles fine (although I guess this might bring its own issues? not sure), but if I try to compile with a home-built projucer, it won’t compile.
Also, in Windows, everything works normally.
So yeah, VST3 builds and loads perfectly fine either using the current release version of juce OR the release version of projucer using the dev. branch files.
Also, all characters are ordinary English and numbers, nothing “weird” going on in that regard.
Thanks, I think I see the issue. When the hardened runtime is enabled, all targets use the hardened runtime, so the helper tool has strict library validation enabled when it tries to load the plugin, which fails because the plugin isn’t release-signed at that point.
Given that the helper tool should never be distributed to end users, we can disable the hardened runtime just for that target:
Please try out this change and see if it fixes things for you.