how to work around midi in VST3?

[Dewdman42]

In addition to the above, the output from a VST3 plugin is also problematic. So if someone is attempting to make a helpful midi plugin for processing switching or other complicated stuff that is currently not supported by ExpressionMaps, for example, then they might write a VST3 midi plugin...except...that in addition to problems with the midi coming into the plugin in separate queues or data structures...the only way to get some of those non-note events out of the plugin is via the legacy option..again...seperate queue....so exact event synchronization will be lost.

[Jeff McClintock]

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.

This is absolutely about the difference between hardware and software systems.

Software plugins don't use a serial bus. They use timestamped events. Timestamped events have no 'order' beyond the timestamps themselves.

The answer is not to twist software into conforming forever to some ancient hardware spec, but rather to adapt to the new reality.

[Dewdman42]

you are incorrect again Jeff McClintock. Software also uses "queues" which are essentially the same thing as a serial hardware bus. Why would you choose to arbitrarily ignore that when it is still needed and useful? You are mis-characterizing completely the point of this. has nothing to do with hardware and nothing to do with 7bit raw data.

[Dewdman42]

to what dragon said earlier...if Steinberg found a way to actually and literally FORCE all VST3 developers to use all the advanced features... we probably wouldn't be in this mess, though Steinberg would also need to change VST4 to also provide a way to synchronize midi events coming out of the plugin as well, right now it just slapped on the legacy out feature, but synchronization is lost with that.

So VST4 needs to be a proper and complete abstraction that provides for this synchronization.....AND....force all VST developers to use those abstractions....not only plugin developers, but VST host developers as well.

As things sit right now...VST3 is broken for certain midi application and that is just a point of fact...that apparently....Steinberg continues to wish to ignore...but the problem does in fact persist...and from the sounds of it, will continue to persist for many years to come.

simply stating that all VST hosts should update their code to Steinberg's abstractions is not realistic and it has left musicians in the cold and confused for over 10 years.

[Dewdman42]

and even further to all of that...if Steinberg would fix these glaring midi problems with VST3, I think just about all plugin developers would be ready and willing to leave VST2 behind for good. The reason a lot of people continue to use VST2 is precisely because of these problems with VST3. So then Steinberg basically got frustrated with the fact that so many people are avoiding VST3 and they made the legal announcement that new developers can't get VST2 license any more.

That has not solved the problem at all!

People that still have VST2 licenses continue to develop for VST2 because of these problems, not because they are too lazy to move to VST3...great for them, but new developers can't get the license...and can't solve their problem either because VST3 is broken for the midi scenarios I have outlined. So the situation we are in now, at an industry level is that....workable solutions for musicians using a wide variety of DAW hosts cannot be provided by VST3, for the reasons stated...and VST2 cannot be provided either since Steinberg laid down the legal hammer.

[arne]

I give up, you don't want to. Have fun.

[Dewdman42]

and so we go....the denial continues...

[S0lo]

Don't live in the past.

To ignore MIDI is to live in medieval.

MIDI is a nice protocol to connect hardware.

And to connect hardware to software. What else do you have as an alternative in VST3 to connect hardware to software (thats is currently supported by most hardware) ?

Just read thru the MIDI 2.0 spec, do you guys really want to implement all that stuff in your plug-ins,

Not all per plugin.

or do you want to stay forever with the MIDI 1.0 spec with its 7 bit values, ordered controller data etc.

The 14bit standard is already there in MIDI 1.0 yet very few seam to use it. And you don't even need NRPNs to do it.

[timefreezer]

MIDI is a nice protocol to connect hardware. --> and hardware is to connect to the humans!

I am not convinced to abandon MIDI 1. MIDI 2 is not even better than OSC, which has been mostly abandoned for no good reason.

[Jeff McClintock]

The 14bit standard is already there in MIDI 1.0 yet very few seem to use it. And you don't even need NRPNs to do it.

Did you realize that the 14bit standard has been flawed since the beginning?
Basically to support 14-bit MIDI CCs one has to choose between two kinds of broken:

• Accurate timing but inaccurate glitchy values which occur between the time of receiving an MSB and an LSB

• Unwanted latency after receiving an MSB while you wait for a matching LSB (that may never arrive, because LSBs are optional).

more discussion here:

Basically, 14-bit MIDI is a mess. The next person that asks me “Can you implement 14-bit MIDI?” I’ll tell them their request is not specific enough.

https://community.vcvrack.com/t/14-bit- ... -0/1779/50

and here

There is some time Δt between the CC and CC+32 messages. If I can’t assume that all CC messages are guaranteed to send both messages (because some are 7-bit), I can’t wait on CC+32 after receiving CC. I have to set the upper 7-bits immediately. This would result in non-monotonic jitter as you monotonically increase the value of the controller.

https://community.vcvrack.com/t/14-bit- ... -0/1779/17

[Dewdman42]

None of that is relevant to the vst3 midi problem

[S0lo]

Did you realize that the 14bit standard has been flawed since the beginning?
Basically to support 14-bit MIDI CCs one has to choose between two kinds of broken:

Yes there are issues, but they are not unsolvable. As I've implemented 14bit my self:

http://www.solostuff.net/product/SD20-M ... Interface/
http://www.solostuff.net/product/SD13-C ... Converter/

The main problem is that the standard is not clear about which message to send first. MSB or LSB. Assuming that LSBs are optional, one could say that MSB has to be first. There is a solution for both situations detailed in the links above.

You have to realize that MIDI was made in the days of 8bit hardware. So I don't really know if it was feasible back then to send 16bit messages. It seams thats why they broke it to two 8bit messages (hence MSB and LSB). They did what they could with available tech.

[Jeff McClintock]

The main problem is that the standard is not clear about which message to send first. MSB or LSB. Assuming that LSBs are optional, one could say that MSB has to be first. There is a solution for both situations detailed in the links above.

So you have 3 solutions ("Hold LSB", "Drag LSB" and "Off").

Your website describes the problem "Off" mode has as - "If you think of it for five minutes, you will figure out it should work but can cause very brief incorrect value jumps"

"Hold LSB" is described as "It saves the LSB value but never applies it to the output CV until the MSB is received."

The MIDI standard specifies "the second byte (LSB) of the data value can be omitted." i.e. it's optional. So "Hold LSB" mode does not handle this situation.

"Drag LSB" is described as "designed to work better when the sender sends MSBs before LSBs, it temporarily changes the current LSB value in a way that smooths transitions until the real LSB is received"

The MIDI spec specifies "When an MSB is received, the receiver should set its concept of the LSB to zero.". So this mode is not compliant with the MIDI spec either.

Look, I am sure you are making a quality product and are doing your best to provide the best possible experience to your users. You have put a lot of thought and effort into this. But's let's face it - If MIDI had been more carefully designed you would never have had to resort to all these hacks. 14bit controllers are fundamentally broken.

[S0lo]

"Hold LSB" is described as "It saves the LSB value but never applies it to the output CV until the MSB is received."

The MIDI standard specifies "the second byte (LSB) of the data value can be omitted." i.e. it's optional. So "Hold LSB" mode does not handle this situation.

Yes. Hold LSB is designed to work better when LSBs are sent first. i.e it expects it to be always sent. If the user chooses this mode but only an MSB was sent the code is clever enough to apply MSB regardless. But it's not ideal.

"Drag LSB" is described as "designed to work better when the sender sends MSBs before LSBs, it temporarily changes the current LSB value in a way that smooths transitions until the real LSB is received"

The MIDI spec specifies "When an MSB is received, the receiver should set its concept of the LSB to zero.". So this mode is not compatible with the MIDI spec.

If you are sure about that zero. Then yes I deliberately don't follow the standard in this case. A value of LSB is temporarily chosen to be either the maximum (127) or minimum (zero) depending on the direction of the MSB movement until the actual LSB is sent. This would result in a smoother transition than the "set to zero". Even if the LSB was omitted.

Look, I am sure you are making a quality product and are doing your best to provide the best possible experience to your users. You have put a lot of thought and effort into this. But's let's face it - If MIDI had been more carefully designed you would never have had to resort to all these hacks. 14bit controllers are fundamentally broken.

Thanks. Sure MIDI is not ideal. But one has to say that it stood the test of time for 35 years. As I've mentioned the primitive hardware back then didn't help. It has been designed under strong constraints of bandwidth, controller speed and memory. Apparently they needed to send 16bit messages over 8bit chunks. I do agree there was room for improvement but I wouldn't go as far as saying that 14bit is completely broken. If you always send MSB first and drag the LSB it's very workable. In this case you can even omit LSB and still work well.

[EvilDragon]

14-bit MIDI ain't more broken than VST3 separate note and CC streams.

But it is true that 32-bit MIDI 2.0 is a cleaner and more modern solution.