VST3 and MIDI CC pitfall

End User and developer here. Steinberg is EXTREMELY short sighted to remove midi CC from VST3. There are many uses for these other midi besides the limited cases that have been outlined here. They are useful messages for various reasons, such as articulation management in numerous DAW’s and instruments and many other reasons. It is fine and good that CC’s are mapped directly to parameters for those cases where people are using sliders to control parameters. that is the simple obvious case, but this message, as well as PC, PitchBend and Aftertouch are used for all kinds of purposes to trigger things to happen in both plugins and external devices. It should very well be possible to allow these other kinds of midi events to appear in the midi buffer of the plugin callback. That fact that Steinberg has removed it is absurd.

I am trying to develop a midi plugin with VST3 and its causing so many headaches because of this.

Also, the sequential ordering of midi events has been, for decades, serialized, so that a sender could send a series of midi events in a certain order and be sure the consumer at the other end would receive those events in the same order. Even with the parameter hacks that people are using to get around VST3’s severe deficiency in this regard…that hack loses that ordering of events that have the same timestamp. For example of the event list has a sequence of cc-note-cc-note-cc-note, all on the same timestamp…what will show up inside VST3 plugin will not have this ordering still intact because the CC’s will have been abstracted out of that serial stream into parameters…and that inherent serialized ordering is lost!! Many people have been working with midi for decades and relying on that.

With articulation management in numerous hosts, including Cubase, it can be beneficial to have a VST plugin to assist in ways that ExpressionMaps fall short, for example. But here again is a situation where VST3 cannot handle it because CC’s are stripped out of the stream…and even if we hack them back in, the original order is lost. VST3 has cut off many creative uses for midi messages from even being possible. This is particularly problematic for articulation management.

Why not describing the use-cases you want to implement which you are struggling with? The one use-case I can decipher from your rant is to talk with external devices. In this case the answer is, talk with the device directly. Then you can be sure that your messages are send to the correct device, not filtered or changed in any way by the host.
For articulation: note expression and key switch handling are features natively available in VST3.


key switching of sample based instruments as of 2020 requires the complete midi protocol in serial order. That is just one case. Midi users have been using this protocol for decades in myriad of ways beyond simply as a parameter adjuster for effecting notes. That includes within plugin signal chains, not just externally.

steinberg’s view on the matter is limiting users from what they have been able to do previously for decades. At this time vst3 cannot be used for midi plugin development in some cases because of this limiting point of view about the role of cc messages. For the time being, those people with the old license can continue to provide vst2 solutions, but new developers will be unable to provide certain midi plugin solutions due to steinberg’s narrow point of view about what each type of midi message can and should be used for.

The main problem is that the vst3 abstraction, though elegant from a computer sci point of view, destroys the serial order that has existed for decades in the past, both externally from the daw in virtual midi device buffer, in the midi cable itself sure but also in the vst2/au midi buffer that order was preserved and all midi events were delivered in the exact same order from the host’s event list to the plugin’s callback, and from one plugin to the next plugin in the chain of routed that way, etc always with that order maintained and every single message delivered as sent.

Vst3 abstracts all but the notes themselves and obliterates that possibility for midi users to count on all messages making it to their favorite plugin in the designated order.

Keyswitching of sample instruments with cc is one place this has broken functionality entirely.

In order to get around these vst3 limitations some hosts are hacking around it to get midi into the plugin. Not all hosts are. Even cubase is broken. Try to create a chord in cubase in the same timestamp with a different attribute expression map articulation attached to each note of the chord. Then monitor the output. You will see that only one of the expression map articulations wins and all notes of the chord will be treated as if one expression map articulation was in effect for the complete chord. Steinberg can hack around the vst3 limitation too if they want but I doubt that will be approved code change :wink:

It’s entirely possible also that if you have a sample Instrument that requires say two cc messages from the same controller # as two switches in a row ahead of the note to switch articulations, again it can be broken if the host decides to only remember the last cc as the parameter value provided to the plugin. The two cc message sequence is lost. It turns out that Cubase is making sure to pass all CC events to iMidiMapping and so the plugin can get them in order, ahead of the note. But its not guaranteed that all hosts will be sure to do that step.

I have run tests with Cubase, constructing an event list with cc-note-cc-note-cc-note on the same timestamp. Cubase sends those events in that order always to external device. However when sent to a VST3 plugin…it will scramble the order…the interleaving of cc’s and notes in that intended order is lost and impossible to reconstruct inside the plugin.

your frustration comes from the misunderstanding that you can build MIDI plug-ins with VST. VST describes an audio plugin API. That you could misuse version 2 for building MIDI plug-ins was not intended. You need a MIDI plug-in API which does not exist across hosts. And for key switching support in VST3 see : https://steinbergmedia.github.io/vst3_doc/vstinterfaces/keyswitch.html


is there a midi related api? I wasn’t talking only about midi-only plugins. This problem will always exist as long as you have the possibility to use cc switching of instruments. Vst3 audio instruments receive midi to drive the instrument. That is how things work in the daw world in 2020. Poly articulation chords are an impossibility with vst3 plugin instruments today in the year 2020. Perhaps someday in the future there will be a fully capable api that provides these capabilities and all daws fully using it; but today in 2020 users need the midi to go through to the instrument in the proper order, which today it does not in VST3.

For poly articulation see https://steinbergmedia.github.io/vst3_doc/vstinterfaces/noteExpression.html.

I guess as soon as you force all daw makers to conform to that approach then maybe it would work but today in 2020 that is not the situation and musicians need solutions that work today.

1 Like

I would like to say that it is not the first time that musicians « misunderstand » an instrument and get a sound from it that it was not intended to produce. Would you lock the lid of a grand piano so that its strings can not be plucked and therefore it stays on tune longer?

Here there are three examples of misuse of the VST2 API:


I really struggle to understand the point of « deprecating them ». The fact that Logic accommodates them as AU MIDI Effects indicates that not everybody in the industry is against a standard for MIDI effect plugins.

Cubase and Ableton Live chose not to host external AU MIDI effects but Reaper and Logic did and Protools also allowed AAX MIDI plugins.

1 Like

Studio one also supports au but not aumfx yet.

Windows users are completely subject to vst rules

1 Like

Also it would appear that cubase itself may not be using note expressions under the covers to handle multiple expression map articulations on the same timestamp. So even cubase is missing this problem, much less all other hosts.

In order to make everyone happy, all hosts need to detect cc-note-cc-note sequences on the same timestamp and convert that to the right series of note expressions and notes before calling back to the vst3 plugin. Trying to use parameters for that will lose the sequence. So all hosts including cubase would need to detect that and handle it with internal note expressions instead of parameters.

Likewise all vst3 plugins everywhere need to be looking for note expressions which not all are. But they should be anyway before shipping a vst3 plugin.

As noted earlier, cubase expression maps are unable to resolve this problem either. Poly articulation chords are impossible with cc keyswitches in the instrument.

1 Like

So i guess one way to work around this the VST3- way, would be to build midi processing into a plugin which also sub-hosts another VST3 instrument plugin from inside my plugin. That way I can do any kind of midi processing I want and send it directly to the instrument rather then trying to send out midi back to the DAW to do it.

Anyone know if there is any good hosting example code out there, particularly for hosting an instrument plugin from within another instrument plugin?


am I getting this right? VST3 is not supporting CC messages? I just started developing aVSTi modifying the Again example. Evervthing worked well so far until I wanted to include the damper pedal. I figured that in the eventList there are only noteOn and noteOff messages. Pedals and controller are missing. So how do I get the pedal message? I hope that I am just to blind to see. How does an instrument work without CC?

Arne Scheffler wrote: ↑Fri Jan 17, 2020 12:04 pm
your frustration comes from the misunderstanding that you can build MIDI plug-ins with VST. VST describes an audio plugin API.

A VSTi has at least a midi input. Is that not supported by VST3?

Thanks for your help!

Hi Chris,
in VST3 an instrument declares all its changeable properties via parameters. In your case, you create a parameter for the damper pedal and you can use IMidiMapping to tell the host that this parameter should map to the damper pedal MIDI control change message. The host will then translate the MIDI CC message to a parameter change and send it to your audio processor.


Thanks Arne. Is there a simple example showing how to to this? Thanks a lot…

You could check the examples:

  • public.sdk/samples/vst/again/source/againcontroller.h
  • public.sdk/samples/vst/note_expression_synth/source/note_expression_synth_controller.h

which supports IMidiMapping interface.


Does this mean that GRM Tools will not be able to progress their plugin development beyond VST2.4?

MIDI is a foundation aspect of GRM Tools and what they do - they could not exist without MIDI input - there is an entire experimental music and sound design community based around GRM tools and live performance manipulation using MIDI.


MIDI input is not a problem, it works rather well. :slightly_smiling_face: The DAW translates MIDI events into either note-events or automation envelopes (so MIDI CCs are indistinguishable from parameter automation) for the plugin. The plugin provides a default mapping using IMidiMapping.

MIDI CC output is awkward, emitting kLegacyMidiCCOutEvent - so the DAW translates MIDI to automation, but you have to translate it back yourself.

(I personally still think we should be able to tag output parameters using something similar to IMidiMapping, and instruct DAWs to either translate back to MIDI or automatically hook up to any following IMidiMapping-tagged plugins as sample-accurate automation, as required.)

AFIAIU, the official stance is that MIDI output support in VST2 was kind of an accident, everyone should have just realised this and probably not used it (?), so we don’t get to be frustrated that VST3 removed it. The lack of widely-supported alternatives is our problem, not Steinberg’s responsibility (even I suspect alternatives are rare partly because VST2 covered it so well).


Thanks for the clarification

We have just signed the license agreement of VST3 and have started our work. But now reading about this issue here and in other forums is frustrating. IMHO dropping such a support is a big step backwards. We have to reconsider our plans whether to use VST3 at all.