I noticed that my VST3s, either Mac or Windows, don’t pass the VST3 SDK validator anymore when built with JUCE 7.0.6. Even a default audio plug-in freshly created from the Projucer doesn’t pass.
I get the following issues:
Error: The module contains a moduleinfo.json file and the module factory exports a IPluginCompatibility class. Only one is allowed, while the moduleinfo.json one is prefered.
Error: Call to IPluginCompatiblity::getCompatibilityJSON (IBStream*) failed
Thanks for the help
It’s our view that this is a bug in the validator/spec. The issue has been reported to Steinberg here (most recently) and previously here.
If there are bugs in the validator that this feature is driving us into, surely we need an option not to use this facility yet. Even if Steinberg resolves it quickly, not everybody will be updating their hosts right away. I understand the longer term benefits, but it feels not quite time for use in production. I really think we need to be able to opt-in to this rather than it being on by default with no way to avoid using it except by reverting to an older version of Juce because there are other important aspects to the latest Juce release that people need access to.
I tend to agree with @Verbonaut . If Steinberg has jumped the gun by deprecating the single-file VST3 format without ironing out bugs in their validator first and allowing the single file and bundle formats to coexist for a substantial amount of time, IMHO I’d argue that it is too early to force all JUCE users into the new VST3 bundle format; having it optional in the projucer would be a great way to give devs some time to implement the required updates in their build scripts and installers.
I’d be surprised if hosts would drop support for single-file VST3s anytime soon as there are so many VST3s around that would all need to be rebuild and redistributed, which probably will take years.
It sounds like the validator will be updated in a future version of the SDK:
I also want to respond to a couple of points that were made in this thread.
This is only a bug in the validator - I have no reason to believe that any consumer host/DAW would fail to load a plugn that has both a moduleinfo.json and an IPluginCompatility implementation.
I disagree - this would add a fair amount of complexity to two build systems (Projucer + CMake), and I don’t think this complexity is warranted just to work around an issue in the VST3 validator, a tool that only a handful of JUCE developers seem to be using.
That’s not quite what’s happened here. The single-file format has been deprecated since SDK version 3.6.10, released 2018/06/11. Generally, hosts support the newer bundle format automatically, because they tend to search the top-level VST3 directory recursively.
The issue that was reported here, and that causes the validator failure, is that an optional “moduleinfo.json” file is present in the bundle, but the plugin binary also implements the optional IPluginCompatibility interface. This is pretty much guaranteed to work in all production hosts. Either the host will ignore both of these optional features, or it will pick one to use as a source of truth for compatibility information. For a JUCE plugin, it doesn’t matter which source of truth is picked, as they both always contain the same information.
Thanks @reuk for the clarification. Good to know that this shouldn’t cause issues in production hosts.
