[BUG] VST3 Wrapper and MIDI AllNotesOff event

So I found a problem if you host VST3 plug-ins and the MIDI includes an AllNotesOff event… some Waves plug-ins are moving their knobs to infinity (but audio isn’t affected).

in the VST3 wrapper in toEventList() I add at line 525:

                    if (msg.isAllNotesOff())

Then this is fine… but if I remove it and step through the code to



            MidiMessage msg (midiEventData, midiEventSize);

            if (midiMapping != nullptr && parameterChanges != nullptr)
                Vst3MidiControlEvent controlEvent;

                if (toVst3ControlEvent (msg, controlEvent))
                    Steinberg::Vst::ParamID controlParamID;
                    // if (msg.isAllNotesOff())
                    //     continue;                <<----  This works if uncommented

                    if (midiMapping->getMidiControllerAssignment (0, createSafeChannel (msg.getChannel()),
                                                                  controlParamID) == Steinberg::kResultOk)
                        // This never gets stepped into

                        Steinberg::int32 ignore;

                        if (auto* queue = parameterChanges->addParameterData (controlParamID, ignore))
                            queue->addPoint (midiEventPosition, controlEvent.paramValue, ignore);


getMidiControllerAssignment() can’t be stepped into and seems to be messing up… 'cause it should call:

    tresult PLUGIN_API getMidiControllerAssignment (Steinberg::int32 /*busIndex*/, Steinberg::int16 channel,
                                                    Vst::CtrlNumber midiControllerNumber, Vst::ParamID& resultID) override
        resultID = midiControllerToParameter[channel][midiControllerNumber];

        return kResultTrue; // Returning false makes some hosts stop asking for further MIDI Controller Assignments

but if I put a breakpoint in there it’s never hit… and when the msg is AllNotesOff it doesn’t return Steinberg::kResultOk and hits the continue!! Which should behave the same as my commented out code.


I chatted with a Waves developer on the JUCE discord channel and he thinks that in the AudioProcessorGraph if the node’s processor doesn’t accept MIDI it shouldn’t be passed the MidiBuffer… but I’m not sure if that’s the cause of this issue.

To duplicate the issue… use the JuceDemoPlugin and feed the stereo audio out into a Waves CLA-76… and feed the JuceDemoPlugin with some MIDI which includes an AllNotesOffEvent.

EDIT: You can actually duplicate the issue without making any audio connections.



We’re looking at this, but it’s a confusing one. I’ve not made much progress, but I did fix this annoyance on the way:

Thanks Tom for looking into this.

It kinda looks like something is tromping over the memory space.



If you spoke to someone at Waves, did they mention what they were doing in getMidiControllerAssignment?

No, he was more focused on the fact that we were sending MIDI via the graph to a plug-in which doesn’t accept MIDI. I wanted to fix the wrapper issue first before following that path.

I’ll email him to check out this thread.



Yes, not sending MIDI is the fix

I’m just a little surprised how calling getMidiControllerAssignment could make things go so wrong.

1 Like

Hey @t0m, thanks for looking into it!
(I’m Eyal from Waves).

It’s certainly possible that some of our plugins have bugs when it comes to answering some callbacks in VST3.
What I asked Rail on the chat was to see if this bug is still reproduced after the routing issue is fixed - I would assume many plugins that don’t have MIDI might do weird things when MIDI is sent through them…