KVR Audio

Dewdman42 · Post by **Dewdman42** » Wed Jan 15, 2020 9:11 am

I am one of the people that didn't find out about the VST2 license in time to get a signed agreement.

I am trying to work with JUCE to make a midi plugin in VST3, but running into problems and reading about VST3 midi problems in the actual spec. I have heard that some of you have figured out some crafty way to get midi, including CC's, program change, pitchbend and aftertouch...into the VST3 plugin callback somehow...and back out again, even though VST3 doesn't officially support this?

Does anyone know where I can find some information about how to approach this? I feel pretty burned about the license and may just make VST2 anyway, but if I can find a way to get full functionality with VST3, I don't mind...but running into problems with the midi is all at this point.

I'm also a bit concerned if the hack around for midi in/out of VST3 will lose any of the original ordering of various midi events that may have the same timestamp but were in a particular original order in the host before calling back to VST3.

Any suggestions welcome.

signalsmith · Post by **signalsmith** » Wed Jan 15, 2020 12:48 pm

Reading MIDI signals works through the IMidiMapping interface. You can specify an ordinary automatable parameter for a given MIDI controller (0-127) as well as aftertouch/pitch-bend by extra constants. I've used this myself, and it worked so far (although I haven't tested it comprehensively yet). You should be able to change this config dynamically, which I'll need to try soon.

(The motivation here is that parameters have more accuracy, both for values and timing, so this is more future-compatible. Not defending/judging this approach, just explaining.)

For outputting CCs, there is an event type: LegacyMIDICCOutEvent. This was introduced in December 2018, so I don't know what supports it and what doesn't. I also don't know what happens if you output MIDI controllers which are already present, etc. etc.

(I personally think VST3 is usable for MIDI input, but bad at MIDI output, but it would solve a lot if IMidiMapping could be used for outputs as well. However I worry that any mention of VST3+MIDI will end up in the same discussion as many other threads have had already.)

Dewdman42 · Post by **Dewdman42** » Wed Jan 15, 2020 6:22 pm

Thanks for the info. So if I read you right, the host is supposed to package up CC, PB and PC into parameters before calling back to the plugin, yes? Then within the plugin I can find those via the iMidiMapping interface.

For sending out, I can try to use LegacyMIDICCOutEvent, and maybe it will work, maybe not depending on host.

Near as I can tell, the original ordering of midi events will be lost this way. For example if I have a sequence of events on the same timestamp cc-note-cc-note-cc-note; Then what I will see through iMidiMapping for a given timestamp or perhaps for the whole process block of time, would be one cc value (the last one) and the three notes in order in the buffer. Sound about right?

Eduur · Post by **Eduur** » Thu Jan 16, 2020 1:35 pm

On the input: I think it depends on the host if you see 1 cc or 3 cc's. And indeed you cannot see that the cc and notes were interweaved. On the output: I just tried with my code in Reaper. I can send (using my own framework) midi note/on/off but LegacyMIDICCOutEvent is not working. I even tried the newest version 6.03 which supposes to implement but no luck yet. Also, I just looked again at JUCE but I don't see any (real) support for LegacyMIDICCOutEvent (Should be in juce_VST3Common.h at around line 576)

Eduur · Post by **Eduur** » Thu Jan 16, 2020 2:42 pm

How about this in Juce: ( I can't test it, because I don't use JUCE):

VST3Common.h at around line 576
else
{
continue;
}

replace by:

else if (msg.isController())
{
e.type = Steinberg::Vst::Event::kLegacyMIDICCOutEvent;
e.midiCCOut.controlNumber = msg.getControllerNumber();
e.midiCCOut.channel = createSafeChannel (msg.getChannel());
e.midiCCOut.value = msg.getControllerValue();
e.midiCCOut.value2 = 0;
}
else
{
continue;
}

Dewdman42 · Post by **Dewdman42** » Thu Jan 16, 2020 6:39 pm

I think juce wants to provide a common abstraction layer that can be used for both au and vst. So adding vst3 specific functionality has to be done carefully and they haven’t really done it. Since Steinberg added the legacy function, that could be used, but I guess only if the host is complying with that updated spec yes?

My opinion at the moment is that vst3 simply should not be used for midi plugins.

Juce has the additional challenge of providing a way to build a vst3 plugin that complies with what most/all hosts are doing and that also provides a common juce api used by developers to create not only vst3 but also vst2, au etc....

As is juce can make a vst3 instrument and should be mostly fine except for cc key switching has to be done carefully and in a more limited way then can be done with vst2. But basically it will work fine when cc’s are only used in a traditional way to control parameters.

But vst3 midi output and midi plugin processing in general should probably not be done with or without juce in vst3

Eduur · Post by **Eduur** » Fri Jan 17, 2020 11:22 am

Dewdman42 wrote: ↑Thu Jan 16, 2020 6:39 pm I think juce wants to provide a common abstraction layer that can be used for both au and vst. So adding vst3 specific functionality has to be done carefully and they haven’t really done it. Since Steinberg added the legacy function, that could be used, but I guess only if the host is complying with that updated spec yes?

Juce ofcourse has support for VST3 Midi Output, in fact you can output Note Events, SysEx (!) and channel pressure. The code I suggested just extends that functionality with CCs.
Why they haven't included the CC yet (it's available for at least 7 months) I don't know,

My opinion at the moment is that vst3 simply should not be used for midi plugins.

Well, Steinberg would say: You can get Midi In and you can get Midi Out, so what's the problem? Well the problem of course is that getting Midi In is an awful construction and getting midi out you're using a 'Legacy' constant, suggesting that it will be gone before we know it. Moreover most DAWs don't support it.
Plus, you suggested a use case which was valid before, but not know anymore. So I fully agree and am still hoping for a new, open, easy spec (from Reaper maybe...)

Juce has the additional challenge of providing a way to build a vst3 plugin that complies with what most/all hosts are doing and that also provides a common juce api used by developers to create not only vst3 but also vst2, au etc....

Since 'most hosts' ignore the VST3 Legacy flag, it perhaps is wise from Juce to not implement it. However, it would be nice if that was somewhere documented (i couldn't find it)

As is juce can make a vst3 instrument and should be mostly fine except for cc key switching has to be done carefully and in a more limited way then can be done with vst2. But basically it will work fine when cc’s are only used in a traditional way to control parameters.

As stated, 'cc input' isn't really a problem, just plain ugly and a bad way how Steinberg solved this, just ignoring the fact that other people may have other needs and that MIDI is the base of everything and was a stable interface for many, many decades (I wrote my first MIDI sequencer in 1986!)

But vst3 midi output and midi plugin processing in general should probably not be done with or without juce in vst3

Completely agree, get rid of this and let's hope for a better way (not that I am holding my breathe for the Midi 2.0 boys...)

Eduur · Post by **Eduur** » Fri Jan 17, 2020 11:25 am

Boy, those reaper boys are quick:
https://forum.cockos.com/showthread.php?t=218129

Dewdman42 · Post by **Dewdman42** » Fri Jan 17, 2020 5:35 pm

Steinbergs official response and attitude is that vst is not a midi api, it’s for audio and they consider it a mistake that people are abusing it for midi.

Midi in on vst3 with various hacks only partially works with the caveate that original event ordering on a timestamp will be lost. That is really not acceptable today. But there is nothing we can do about steinberg’s point of view.

Dewdman42 · Post by **Dewdman42** » Fri Jan 17, 2020 6:10 pm

and yes a big part of the problem is that not all hosts are conforming 100% to steinberg’s vst3 demands. There is no standardized recognition by Steinberg about an actual need for midi in and midi out, in order. Some plugins are hacking around it as best as they can but really the hosts themselves need to hack around it, and good luck getting that to happen at all much less in a consistent way.

Note that even with cubase expression maps it is not possible to put a different articulation on each note of a chord. The exact ordering is lost. Cubase is of course conforming to vst3. But not all plugins are looking at note expressions, for example, for that kind of situation and not all daws are creating note expressions either. That is the documented vst3 way of ensuring cc’s happen in a desired order in front of notes. But as I said good luck getting everyone to conform to that. There is no guidance from Steinberg, only obstinacy.

steinberg has stated clearly that midi out is not intended for vst3, they consider it an audio api. Their view is that everyone abusing vst2 for midi is doing so errantly.

matt42 · Post by **matt42** » Fri Jan 17, 2020 7:01 pm

Dewdman42 wrote: ↑Fri Jan 17, 2020 6:10 pm they consider it an audio api.

I though that the idea was to make the API control standard agnostic, but they just did it in a really bad way

Dewdman42 · Post by **Dewdman42** » Fri Jan 17, 2020 7:07 pm

Well in the long run something like that could be cool but the reality of today and the last ten years is that Serialized midi is how daws are constructed and how different softwares and plugins communicate with each other. And how musicians expect it to work also. Steinberg’s emphasis was on the theoretical rather then the practical and now they are just being stubborn when the industry after ten years simply did not accept it.

With midi2 and mpe I expect users to want to do even more with that serial stream then they have in the past. I’m fine with using an abstraction layer and we can nit pick some of steinberg’s choices there but really nothing would ever be perfect to everyone. But still they failed to account for the serial nature of midi and the expectation by everyone to utilize that serial nature in productive ways, which is the practical side. I think they could have still provided a way to ensure serial ordering while also abstracting things. They still could add that to vst 3.5!

But they appear to be digging in their heels and saying vst is not about midi. But that is just entirely ignorant of the fact that perhaps millions of musicians around the world are using midi ina serialized manner, and literally thousands of existing tools are designed to communicate with each other both through hardware and software using that serialized approach. Someday we might have a truly abstracted paradigm that accounts for all issues and timing related things but today in 2020 and the foreseeable future, that is not the case, midi is part of what we do and it’s a serial protocol.

matt42 · Post by **matt42** » Fri Jan 17, 2020 7:16 pm

I totally agree. I'm just saying I don't think it's supposed be audio only - it's just that they made a mess of making a control standard agnostic API

Dewdman42 · Post by **Dewdman42** » Fri Jan 17, 2020 7:26 pm

matt42 wrote: ↑Fri Jan 17, 2020 7:16 pm I totally agree. I'm just saying I don't think it's supposed be audio only - it's just that they made a mess of making a control standard agnostic API

See this recent post from Arne @ Steinberg: https://sdk.steinberg.net/viewtopic.php ... t=10#p2378

The whole thread is interesting. I've been having it out with him for the past few days, but the thread goes back a couple years.

Dewdman42 · Post by **Dewdman42** » Tue Jan 21, 2020 7:00 pm

Just want to follow up for anyone in the future looking for this information. Have spent a lot of time the past few days on this. Here's my understanding of the current situation in 2020.

VST3 does not pass CC midi events into VST3 plugins, as midi events. DAW's are supposed to translate all midi messages into VST SDK objects which are provided to plugins, but not as a serial midi queue full of midi events, as has been the case with VST2.
CC events in particular show up to VST3 plugins as parameters in a queue. It is a separate queue from NoteOn/NoteOff, so serialized ordering of mixed type midi can not be garaunteed inside VST3 plugins other then through timestamp.
CC events previously could not be output from VST3 plugins, but last year Steinberg added a legacy function to do that. However many DAW's do not yet make use of this added VST3 feature, so trying to output CC midi messages from a VST3 plugin will be unreliable for the time being. Also it is not clear whether timing information is included in that legacy out function. And they are on a seperate queue from notes, as per the above, so synchronization between notes and CC's cannot be absolutely guaranteed at a fine level.
Steinberg says that articulation management and keyswitching should be handled via the VST3 NoteExpression paradigm. VST3 also includes support for exposing keyswitching information to the host. These API's should be used for managing key switches, not simple processing of midi events in serial order as has been possible with VST2
Most DAW's do not yet fully support VST3 SDK, including NoteExpressions, Keyswitching, legacyCC out, etc. Until they do, its not really feasible for a VST3 plugin developer to utilize the complete VST3 sdk without running into problems with many hosts. Paradoxically, using the actual VST3 sdk fully is the only way to ensure complete and accurate synchronization of mixed midi event types processed through a VST3 plugin.
Steinberg does not support using VST3 sdk for midi plugins, they say its an audio SDk that happens to have some midi capability that is being exploited by some developers. They take no responsibility for ensuring that VST3 can be used for midi plugins, as of 2020.
JUCE also does not fully support VST3 sdk, per some of the reasons mentioned above. They have some hack arounds to get midi in and out, but since not all DAW's are looking for the legacy CC out, VST3 plugins produced with JUCE will also not work with all daws, in terms of midi thru. JUCE currently also does not provide a way to have VST3 plugin with multiple event input buses.
VST2 still works, but with the license change, its not possible for everyone to develop with it. So until all DAW's and plugins conform more fully to VST3 approach, we will be stuck in the middle. New developers will have to live with limitations of VST3 broken midi.
Some DAW's such as StudioOne, for example, keep CC's separate from notes internally, making it basically impossible to use a VST2 plugin that generates CC's in any way and have it feed to a VST3 instrument plugin. StudioOne is more compliant with VST3, but breaks the use of mixing VST2 midi plugins with VST3 instruments.
Until further notice, the main thing I see is that VST3 cannot be trusted for outputting CC's and it cannot be trusted for ensuring serial ordering with mixed event types. So that means, don't develop midi-only plugins with it, and don't ever use CC's for articulation keyswitching.

how to work around midi in VST3?