VST3 and MIDI CC pitfall

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.

Cheers,
Arne

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
    or
  • public.sdk/samples/vst/note_expression_synth/source/note_expression_synth_controller.h

which supports IMidiMapping interface.

Cheers

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.

https://inagrm.com/en/store

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).

2 Likes

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.

I’m not sure what you mean by dropping support. Please read https://developer.steinberg.help/display/VST/About+MIDI+in+VST+3 for information regarding which concepts are used in VST3. The good thing is, with VST3 support you get automatic support for MIDI 2 when the host supports it, you just have nothing to do as a plug-in developer all the burden has to be done by the host developer.

Thx for the immediate response.

Our intension was not to create another VST plugin where 1000s great ones exist. Our idea was to create an overall solution where existing plugins can be used. The idea was to use the great VST technology and create a solution based on MIDI. For MIDI - good or bad - all MIDI events are essential including CC events. CCs are part of the MIDI stream. E.g. the timing of CCs related to other events is important. The interrelation of MIDI events is one of the key reasons why MIDI has made it for more than 30 years.

Form our limited knowledge from VST2 we were of the opinion that MIDI events are handled including CC events for MIDIin and MIDIout in VST3, too. It is disappointing reading here that using MIDI in VST2 was a “misuse” and VST3 is just for audio. A “misuse” which is one reason why VST has become so powerful.

We can debate whether the missing MIDI capability in VST3 is a drop of support or not. The fact is that according to the link (https://developer.steinberg.help/display/VST/About+MIDI+in+VST+3) “Unlike in VST 2, MIDI is not included in VST 3.” To me this is a drop of functionality which we overlooked.

The offered alternative is not adequate for our ideas, technically as well as from the license perspective. The license can be terminated with 6/36 months notice (see §9 of the contract) which impacts significant developments.

Looks like our view what opportunities might be possible by integrating VST3 in our solution was too naive. This is the reason why we have to reconsider our plans using VST3.

1 Like

Why don’t you use the MIDI API of the system if you need to communicate with MIDI as a transport layer? Then you can make sure that you send and receive raw MIDI the way you want. The host was always able to mangle the MIDI stream to its liking so that a plug-in eventually did not receive the raw MIDI stream from a device.

Thanks for the hint. We are going to check it.

MIDI-cotrols cannot be assigned always because not all hosts call the routine getMidiControllerAssignment. So the MIDI-input will be ignored. For me it would be normal to have at least the damper pedal, pitchbend, mod-wheel and maybe also aftertouch connected automatically with EVERY host. How can I force to connect?

Which VST3 hosts does not implement IMidiMapping?

In Reaper, getMidiControllerAssignment( ) never gets called. So I do not know how to define the connections between MIDI-CCs and parameters. I could only force getMidiControllerAssignment( ) to be done, but this is not the normal way.

2 Likes

I have verified the same issue with my latest synth plugins and Reaper (MacOS, Catalina with the special Catalina-Reaper version). I also verified it for the VST SDK samples NoteExpressionSynth and AGain/AGainSimple - getMidiControllerAssignment( ) is not being called on either of them.

1 Like

You should directly contact them and inform them about this issue. Thx

OK - thanks. Good to know that this is not a VST3 SDK issue but rather a host issue.

(I am just a beginner in coding VST plugins, maybe i have overlooked anything.)

So it was never thought of designing “real” midi VST3 plugins?

I recentley did this juce beginner tutorial: hxxps://docs.juce.com/master/tutorial_code_basic_plugin.html
(cant post links, so replace xx to tt)
VST2 version works fine upon setting plugin midi in and plugin midi out in projucer. While VST3 plugin simply doesnt work.

What is the solution to get the VST3 version working?

Also Why is it so bad to not allow 3 VST3 plugin versions? MIDI FX, Audio and Mixed aka Synth Plugin?

There is a post above that answers your question:

In other words, Steinberg, Presonus, Ableton don’t want you to create your own MIDI plugins. They want you to use their great (cough) MIDI effects instead. Now that VST2 has been deprecated, if you want to create your own MIDI effects, you have to get a Mac, code them as MIDI effect Audio Units and use them in Logic or Reaper.

2 Likes

I have a similar issue - I’m not trying to create a MIDI effect, just one that uses MIDI CCs for parameters (using IMidiMapping).

Steinberg’s LegacyMIDICCOutEvent workaround has caused ambiguity which actively breaks some use-cases. Here’s a diagram I posted in another thread about how MIDI is passed through an effect chain:

Effects which used IMidiMapping used to all function like (3). WithLegacyMIDICCOutEvent, it’s now ambiguous whether they should act like (5).

Any effect could output legacy MIDI events - so if they don’t, hosts have to guess whether they’re MIDI input-only, or whether they’re deliberately absorbing CCs.