VST3 and MIDI CC pitfall

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.

1 Like

Hi,
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

Cheers,
Arne

1 Like

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.

2 Likes

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.

3 Likes

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?

1 Like

Hey,

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!
Cheers
Chris

1 Like

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

1 Like

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

1 Like

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

2 Likes

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

3 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 Log In - Steinberg Developer Help 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 (Log In - Steinberg Developer Help) “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.