how to work around midi in VST3?

[Jeff McClintock]

clarification:

it is not clear whether timing information is included in that legacy out function. And they are on a separate queue from notes, as per the above, so synchronization between notes and CC's cannot be absolutely guaranteed at a fine level.

The LegacyMIDICCOutEvent includes the field 'sampleOffset' as do note on/off events. MIDI CC's are sample-accurate. It is therefore possible to synchronize the timing of MIDI CC events with note events (which are also sample-accurate).
However, VST3 has no concept of 'order' between events that fall on the same timestamp. i.e. it is not meaningful to say that one CC happened 'before' or 'after' another CC with the same timestamp. They happen at the same time.

[Dewdman42]

incorrect. Its possible and often desirable to ensure serial order...even on the same sample offset. this is often the case, for example, when attempting to play cc or pc switch events in front of notes in a chord, all of them on the same sample offset. This is a glaring problem with VST3 in certain applications.

[Dewdman42]

and as I said earlier... VST2 ensured that serial order...even on the same timestamp...by virtue of the fact that all events were in the same queue. Because VST3 separates them to separate queues...the serial order cannot be maintained.

[mystran]

incorrect. Its possible and often desirable to ensure serial order...even on the same sample offset. this is often the case, for example, when attempting to play cc or pc switch events in front of notes in a chord, all of them on the same sample offset. This is a glaring problem with VST3 in certain applications.

+1 this is a real problem.

[arne]

Just use the dedicated API like key switch in VST3 and you don't have to depend on some order of hardware events.

[EvilDragon]

Except switching articulations via CCs is a very valid workflow for composers, because hosts do chase CCs and not all hosts chase notes properly. And as you know, not all hosts are happy to implement note expressions etc. for one reason or another - why doesn't Steinberg persuade them to achieve feature parity? Isn't this what a "standard" is supposed to do, to ensure consistency of implementation? VST3 fails hard at that!

In fact there's a number of sample libraries that are using not just keyswitches but combine it with CCs and so on to provide articulation switches (for good reason too).

So with VST2 it was easy to ensure that serial order of incoming MIDI events was kept, while with VST3 a dev needs to go through all sorts of workarounds (AND also depend on hosts if they implemented event timestamping properly or not!) to achieve the same. How is that an improvement?

So much of these problems would have been solved 15 years back if we had a none-profit standardization committee/association that have representatives from major software and hardware makers sitting together and making sensible decisions that fit all pockets and publishing detailed standards. Well that's actually how MIDI was initially made when Dave Smith sat with Roland and Yamaha and made it happen 35 years back.

Something like the IEEE association or ACM. These are the reason why all these electronics, WIFI, 3G, 4G, Ethernet etc... of today works together. Same thing should be at place for music.

Excellent point, S0lo!

[Dewdman42]

arne,

I understand the elegance you attempted to create with VST3, but the simple truth is that Cubase would literally be the only host DAW that would work in that approach. Today in 2021, if a plugin wants to be usable on all Hosts....it cannot rely on absolute VST3 conformity to using NoteExpression api, etc for attaching CC switches to notes. And still, VST3's legacy output will lose serial ordering if what you are needing to do is have a plugin that adds some switches or other things as a filter on the way to another plugin hosting an actual instrument. VSL's Vepro is an excellent example where we need to use the VST3 version of VePro in order to use 48 midi ports...but unfortunately, as the data passes through the VePro.vst3 plugin and sent on to VePro...the ordering of CC switches can be lost when they are on the same sample offset. And this sometimes is also the case even when using Cubase expression maps, much less other host DAW's that do absolutely nothing with NoteExpressions or other elegant VST3 solutions. JUCE library also does not use those capabilities and many plugins and hosts are now based on JUCE for obvious reasons.

This is the current reality we are all trying to make music in and create solutions that work TODAY.

I will also say furthermore, that this particular topic has been discussed for years now and there are really only a few people that even completely understand how VST3 is supposed to work regarding some of these things. In my view the VST2 approach of passing the raw midi into the plugin as a single queue was much more simple for most people to understand, the VST3 approach...including support for all midi event types...is much more complicated...and frankly, still today poorly understood by the vast majority of people attempting to develop midi plugin solutions. I understand the elegance it is attempting...and in particular it is also much more ready to provide an abstracted layer that will be ready for MIDI2.0, I totally get it...but the other side of it is that it has created all kinds of chaos and misunderstanding and broken functionality across many different hosts and plugins, many musicians suffering with CC ordering problems as they try to compose and can't figure out why things are not working properly, and the answer is because VST3 is fundamentally broken in this regard...and not all DAW's nor plugins, are correctly using VST3...even today now after more then a decade... etc..

[EvilDragon]

Again, the main problem is that Steinberg didn't MANDATE exactly how VST3 should be used across all hosts. Every damn host does its own damn thing and they shouldn't be doing that. There should have been some sort of, I dunno, verification step by Steiny in order to ensure a host is properly VST3 compatible. Or, ensuring that various methods can only be called in one exactly specific order. Something like that.

This is how proper protocols operate - by absolutely requiring things to be done in one single and no other way. VST3 fails at that just as much as VST2 did, perhaps even worse.


By all means, go ahead and make VST4. But trim all the bloat and fat that VST3 has, make it nice and simple, yet powerful and functional again, easier for devs to understand and implement, but most importantly: get all DAW vendors in the same room and talk things through, and reach a singular consensus on how things should operate. There really should be an audio plugins committee.

[Dewdman42]

+1

[Dewdman42]

my only request for VST4 is that all considerations for absolute preservation of midi event serial ordering is preserved in some way when calling back into plugins....even when they are on the same sample offset. That could be separate queues or other abstractions sure, but a plugin needs to be able to determine that exact ordering and preserve it while passing the midi back out too.

This problem has caused all manner of havoc.

And also that Steinberg consider that today in 2021, many people are needing and using VST plugins for purely midi processing..and many hosts...INCLUDING CUBASE do not provide any other way for 3rd party midi plugin processing (aside from a couple built in midi plugins in some cases). Regardless of the intention of VST as being meant for that or not...that is the reality today.. This functionality is needed and is actively used across the world. VST4 needs to include proper handling of midi events so that plugins can function with assurance that they are seeing the desired events....whether they are raw midi or as abstractions...in exactly the order they were intended from outside. And also plugins may need to schedule midi events in an exact serial order to be handled by the host in the order specified by the plugin....again...regardless of the abstractions or separated queues. MIDI is a serial protocol. That serial nature has been counted on for decades. Plugins need to be able to count on it too.

[EvilDragon]

Yes. Step number 1 of a successful plugin standard is NOT pretending MIDI doesn't exist.

[arne]

Don't live in the past. MIDI is a nice protocol to connect hardware. Just read thru the MIDI 2.0 spec, do you guys really want to implement all that stuff in your plug-ins, or do you want to stay forever with the MIDI 1.0 spec with its 7 bit values, ordered controller data etc.
It's true that hosts should implement more VST3 interfaces. This will be more when hosts implement MIDI 2.0 and see where this is going...

[Dewdman42]

Arne you are ignoring the problem and presenting a different solution. This is known as a "red herring".

You could still abstract that data without creating synchronization problems. No it is not desirable for us to deal directly with 7bit old-school midi events inside plugins, it is much better to have abstractions. However, where VST3 falls short is in the way you divided things into separate queues...which breaks midi's serial synchronization of events. Regardless of whether you are talking about MIDI 1 or MIDI 2, we are still talking about a serial protocol and people use the serial ordering for sensible purposes, precisely because not all midi is note data. I do think you tried to think of some musical situations that your abstraction should suffice with those abstractions, but you did not think of every situation, which left some situations, broken in terms of midi event synchronization.

Again...to repeat what I said, which you ignored.... the problem is about midi event synchronization....not whether the data be raw midi data or not.

[arne]

Yeah, I don't see where you need this in software. If you want to communicate with hardware, then don't use the host to communicate with it, communicate with the hardware directly. Otherwise nobody guarantees you anything about ordering or if the bytes are even passed thru to it.

[Dewdman42]

We aren't talking now about communicating directly to hardware...seems like another "red herring" deflection.

Since you still seem to be missing the point, let me try to illustrate an example...

Let's say you have a midi chord with several notes on the same sample timestamp. The two notes require a different key switch. One is using CC#20=0, the other is using CC#20=127.

This will be the result in VST2 vs VST3

VST2:
1. CC#20, Value 0 (select sustain)
2. Note-On (trigger sustain)
3. CC#20, Value 127 (select staccato)
4. Note-On (trigger staccato)

VST3:
1. CC#20, Value 0 (select sustain)
3. CC#20, Value 127 (select staccato)
2. Note-On (trigger staccato)
4. Note-On (trigger staccato)

synchronization is lost. This matters because MANY software instruments on the market today do in fact respect that ordering to process the key switches and CC switches in the correct order...but this can not be determined by VST3 instrument plugins (unless they used the advanced features such as NoteExpressions AND THE DAW ALSO HAS TO BE USING THOSE ADVANCED FEATURES WHICH MOST DO NOT.

In fact in the VST3 scenario, both notes will receive the treatment of CC#20=127.

This is just one small example where the serial ordering is CRITICAL for plugin software operation...this has absolutely nothing to do with the hardware.