We’ve just released plug-in updates using JUCE v7.0.7 and it seems that the updated VST3 plug-ins do not load on a variety of hosts on Windows 10, including River Media Center, Reason, Studio One. Reverting back to JUCE 7.0.6 seems to fix the issue.
I can reproduce the issue with JRiver Media Center v31 and the VST3 JUCE GainPlugin demo - it simply won’t load the plugin at all, but works fine with the VST2 version. Haven’t figured out yet why but just as a heads up and curious to see if others run into the same issue with the latest and greatest JUCE update?
FWIW I’m using VS2017 (v15.9.04012) to build the VST3 plugin.
We can add Cakewalk by Bandlab to the list of hosts that seems to refuse to load a JUCE 7.0.7 VST3 plugin on Windows… Previous JUCE versions work fine.
Strangely the JUCE wrapper VST3 entry point doesn’t even seem to get called?
This might be related to the recent addition to the JUCE generated VST3 plug-ins of the moduleinfo.json file.
If you want to check that, you can search the forum for recent problems regarding VST3s, and you will probably find a few topics about it with proposed workarounds to temporarily disable it. That will allow you to check if that is the problem.
Thanks @yfede. Yes I’m aware of the recent change from a single VST3 file to a bundle format. But this doesn’t seem to be related. Even if I try to load the VST3 file itself outside the bundle context, it still doesn’t load.
The guys at JRiver noticed that they only support class 0 VST3 plugins, while with the JUCE update, this seems no longer supported with JUCE (?). I’m not sufficiently familiar with the VST3 spec to fully understand what this means though but hoping the JUCE team could shed some light on this?
After a VST3 DLL is loaded, the host uses the plugin’s IPluginFactory returned from GetPluginFactory to find information about the kinds of objects (audio components, edit controllers, etc.) that can be created. The factory has a countClasses() member returning the number of distinct classes that can be created by the factory, along with getClassInfo() functions that can be used to retrieve information about the class at a particular index.
At least for JRiver, the breakage was introduced when a new IPluginCompatibility class was added at index 0. Putting the audio component back at index 0 fixes the issue. My guess is that this host is assuming that particular classes are always found at specific indices; it would be more correct to iterate through all of the classes in the factory, and to ignore any classes that aren’t recognised, so I believe that this is a bug in JRiver. I haven’t tested in the other hosts yet; but assuming the patch fixes behaviour in those hosts too, then I think that those hosts are technically buggy too.
I just had a user report that VST3 loads but produces no audio out. Could that be related? Haven’t reproduced yet.
Hello, sir. I’ve downloaded the new version and it doesn’t output any audio.
I thought the problem was on my end so I tried with different DAWs and configurations
Windows. Bitwig, Ableton, Reason.
I use a generic midi controller configuration.
Tried the MPK mini mk3
Roli seaboard
And finally used my Quantum synth as a master keyboard.
It looks like it is receiving data just no audio output
I think it’s unlikely to be the same issue, unfortunately. The original issue is highly DAW-dependent, and is likely to prevent the plugin from loading altogether. If the plugin loads in a variety of DAWs, the problem is probably elsewhere.
