juce_VST3PluginFormat.cpp broken after updateMidiMappings() function addition

Hello,

After version 6.1.0 when the function “updateMidiMappings()” was included in the file juce_VST3PluginFormat.cpp in commit “VST3 Host: Avoid calling IMidiMapping functions on the audio thread”, my audio plugin has failed to load some VST3. I’ve tracked the issue to that function where it stucks in the “storedMidiMapping.storeMappings (*midiMapping);” call and then end on “JUCE Assertion failure in juce_win32_Windowing.cpp:2299”

My current solution was to disable the call to “updateMidiMappings()” as my plugin does not use MIDI.

I hope the information provided helps to solve the issue and please, I’ll be happy to provide more details if needed.

Thanks.

1 Like

Are you running the very latest develop branch? There was a problem with midi mappings in VST3 plugins that was fixed in this commit:

You’ll need to be running 6.1.2 or later to use this fix.

If you’re already using 6.1.2 or later, please let us know:

  • In which hosts, and on what platforms are you seeing problems?
  • Have you tried running the JUCE example plugins in the same hosts to see whether they also have the same problem?

I tried all releases after 6.1.0 and they are all the same (6.1.0 causes the problem too). I just used the last develop branch and same thing.

After running some tests with the JUCE Audio Plugin Host, the same problem happened exactly as described.

Tested on Windows and macOS; standalone, Logic, Reaper, Live. The VST3 I’m trying to host are Waves plugins, one of them is “True Reverb”, the problem happens with many of them but not all.

Running on Windows 10, I just tested TrueVerb VST3 13.0.0 and 12.7.0 in the AudioPluginHost, building with JUCE 6.1.0 and develop. I did see a couple of crashes, but only the very first time the plugin editor was opened after scanning. Once the plugin editor had been opened once, subsequent runs of the AudioPluginHost were able to load the plugins without problems. The crashes seem to be related to first-time setup code in TrueVerb itself - I’m not sure that it’s an issue in JUCE’s hosting code.

At the moment I’m not able to reproduce the problem that you’re seeing. Were you seeing problems with a specific version of TrueVerb? Are there other plugins which also trigger the problem?

It would also be useful to know exactly how you’re triggering the problem - does it happen when loading the plugin, showing its editor, calling prepareToPlay, or something else?

I’ve tested the same way you describe (same versions) and the behavior indeed changed. I was using V10 of Waves plugins, updating to V13 made it work as you said.

So I guess we can conclude it’s a Waves code problem?

In case it still helps, more detailed information:
What happened is you just load the plugin, it first freezes the plugin/host for around a minute then it crashes.
While debugging I realized the freezing time was while the code goes through every MIDI channel on this loop:

void storeMappings (Steinberg::Vst::IMidiMapping& mapping)
    {
        for (size_t channelIndex = 0; channelIndex < channels.size(); ++channelIndex)
            storeControllers (mapping, channels[channelIndex], channelIndex);
    }

After going through 16 channels it would crash. The editor won’t even show up.

Also, another plugin which would have the same behavior is Renaissance Reverb from Waves too. After updating to V13 same thing, it only showed that frist crash, then it works just fine.

Thank you for helping figure this out!

Thanks for getting back to me. It sounds like this is a Waves bug, so I’m not going to investigate this further. However, if you happen to find any other (ideally non-Waves) plugins that crash please let us know and I’ll take a look.