VST3 and MIDI CC pitfall

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.

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?

1 Like