However, the version of the VST3 SDK built into JUCE is 3.7.2, so the above mentioned framework cannot be used.
The update of the SDK has stopped for more than 2 years, is there any reason for not updating it?
Of course I can update the SDK only for my environment, but I expect JUCE official to actively update the SDK.
What functionality are you hoping to use? Just updating the SDK version that JUCE uses won’t cause the moduleinfo.json files to be automatically generated. To support that, we’d need to update the CMake/Projucer scripts too. Similarly, the hosting code will need to be updated to use the information from the moduleinfo.json.
I understood that it is not enough to just update the SDK, the JUCE side needs to be implemented as well.
What I am hoping for is a reduction in scanning time for plugins.
Our team develops both hosts and plugins, so it would be great if JUCE could support moduleinfo.json for both hosts and plugins.
This functionality is now available on the develop branch.
Plugins can now implement VST3ClientExtensions::getCompatibleClasses to inform the host of any classes that are compatible with the current VST3. This information will be exposed to the host via the IPluginCompatibility interface.
A moduleinfo.json containing this compatibility information can be written during the build of a plugin, either using Projucer:
or CMake:
Note that the moduleinfo.json is supposed to live in the Contents subdirectory of the bundle, but this isn’t allowed according to Apple’s guidance on code signing: Technical Note TN2206: macOS Code Signing In Depth. For this reason, moduleinfo.json generation is disabled by default.
Finally, the hosting code has been updated to scan the moduleinfo.json if available:
@reuk, as the technical note is very long, can you repost the part where it states that it’s not allowed to place non-code into the Contents directory? I cannot find this restriction. The note only talks about “code-locations”. Thanks.
Nested code is expected in a number of standard locations within a bundle.
[table including Contents directory]
These places are expected to contain only code. Putting arbitrary data files there will cause them to be rejected (since they’re unsigned).
… Note: While strict compliance with these rules may not affect your app today, anything that doesn’t meet these requirements note may be rejected by code signing verification (and the Mac App Store validator, in the case of Mac App Store apps) at any point in the future without notice.
Later on, in the FAQ section:
The ‘code’ codesign complains about isn’t code. It’s just some data files.
If a file is in a code location, it must be code, and it must be signed.
Do not put data files into code locations. Move these elsewhere, such as Contents/Resources.
Note that codesign does currently complain when trying to sign a bundle containing an unsigned Contents/moduleinfo.json. Signing the moduleinfo.json then the bundle does work, but stores the signature in the extended file attributes of the moduleinfo.json file. You can search for “extended attributes” on the linked page to find out why that is discouraged.
