VST3: Is it worth supporting?

[AdmiralQuality]

As a composer with classical training I have the level of abstraction needed to be able to understand both the "improvisatory" approach that is apparently defended by Admiral and the more rational approach defended by Gol. Both can and should cohexist.

I too said that both should coexist, what I wrote is
"music can & is also made by crafting on a screen, using a mouse."

And that's the ONLY way your host will let it be made. Restrictive where you could have been inclusive. Just like Stein-aha.

and the even more exoteric RPN and NRPN, which allow basically EVERYTHING.

you can make anything out of NRPN's when you -agree- on a protocol. And this is then exactly like.. a new API.. but with all the hassles of 7-bit crap & limited messages.
Even what IS standard in MIDI is very poorly adopted by software. You wanna send a pitch bend range RPN to VST's? Count how many will properly interpret it (none?) vs how many will think it's just CCs automating something else.

Besides, things have changed a lot, there are many peripherals out there, that should be the #1 reason for plugins not to know about controllers that are attached to the sequencers, & thus not MIDI because MIDI is clearly not the best abstraction protocol.
Other non-MIDI instrument protocols, mice, Joysticks, Leap Motion, touchscreens.. they're all valid peripherals & plugins shouldn't know/have to know about them (but that's an old discussion)

Why does the controller need to know the pitch bend range of the instrument? It doesn't (unless it's a guitar controller). Again, you're trying to restrict, limit and disable the user when you should be enabling them. Just how some of you guys roll, I guess.

Look, if a host wants to translate MIDI into automation events, I think that would be great. As long as it still allows access TO THE ORIGINAL MIDI for PLUG-INS THAT WANT IT. But when we leave it up to Steinberg to decide what attributes our instruments are allowed to have, we all lose.

[tony tony chopper]

Why does the controller need to know the pitch bend range of the instrument?

It's the instrument that should be able to be told a PB range from the host.
(even though this is a restriction of VST, because in my plugin API there isn't even any PB range, pitch automation is a large control like others & the range only exists UI-wise)

But when we leave it up to Steinberg to decide what attributes our instruments are allowed to have, we all lose.

that, or you can make your own host, make all the decisions, & hope that your plugin API will be adopted by everyone.

[AdmiralQuality]

Why does the controller need to know the pitch bend range of the instrument?

It's the instrument that should be able to be told a PB range from the host.
(even though this is a restriction of VST, because in my plugin API there isn't even any PB range, pitch automation is a large control like others & the range only exists UI-wise)

WHY? The instrument is PLUGGED INTO the host. You can just change it on the instrument. (Again, this concept of a controller just goes right over your little head, doesn't it?)

But when we leave it up to Steinberg to decide what attributes our instruments are allowed to have, we all lose.

that, or you can make your own host, make all the decisions, & hope that your plugin API will be adopted by everyone.

No, that's what you do. I make plug-ins to make hosts, programmed by dull minded, restrictive, unimaginative people, do wonderful things that the host developers would have never thought of. (The whole point of supporting plug-ins, isn't it?)

[fmr]

you can make anything out of NRPN's when you -agree- on a protocol. And this is then exactly like.. a new API.. but with all the hassles of 7-bit crap & limited messages.
Even what IS standard in MIDI is very poorly adopted by software. You wanna send a pitch bend range RPN to VST's? Count how many will properly interpret it (none?) vs how many will think it's just CCs automating something else.

Besides, things have changed a lot, there are many peripherals out there, that should be the #1 reason for plugins not to know about controllers that are attached to the sequencers, & thus not MIDI because MIDI is clearly not the best abstraction protocol.
Other non-MIDI instrument protocols, mice, Joysticks, Leap Motion, touchscreens.. they're all valid peripherals & plugins shouldn't know/have to know about them (but that's an old discussion)

The 7-bit limit is a myth. Since the beginning, the MIDI protocol allowed two messages (MSB and LSB) to be sent together, to make a 14-bit big message. It's not the most elegant approach. but it works, and 14-bit is detailed enough, as far as I'm concerned.
I agree when you talk about other controllers, but the musical world has been taking very little advantage of them (I remember the Nintendo Glove several years go). Perhaps because those devices are very volatile, and become out of order very quick.
About MIDI. AFAIK, MIDI is "blind". The sender sends whatever messages, without caring wether the receiver understands them or not. If the reiver understands them, it plays whatever action it is programmed to do with them. If not, it simply ignores them.
If a sequencer (ANY sequencer) goes up trying to "interpret" MIDI messages, and transforming them, then there should, at least, have an option for not doing that, and I think there is (at least, I know there was such contro until not that much longer). As long as the sequencer just records data, and reproduces it the way it was sent, there will always be a safe option for using MIDI. It's up to the programmers of the receivers to implement the protocolos more or less extensively (and there has been a more and more "minimalistic" approach on this).

[hokkaido]

But I am not against other protocols, as long as they do not imply loosing functionalities. If Admiral is right, too bad. If not, then say where he is wrong. I, personally, find it hard to believe that Steinberg would be so stupid as to cur functionalities. I respect their skills as developers, and their vision (after all, ASIO and VST were created by them - if they didn't, we would still be paying thousands for DSP cards to do what our computers were able to do alone).

They indeed crippled Midi in a way. If you want to receive MIDI, you have to implement IMidiMapping and export every CC you are interested in as a VST parameter. With the help of IMidiMapping the host will translate the incoming MIDI data to your VST parameters.

The problem is that the IMidiMapping interface doesn't give you full control over the incoming MIDI message stream here.

The interface looks like this:

Code: Select all

getMidiControllerAssignment (int32 busIndex, int16 channel, CtrlNumber midiControllerNumber, ParamID &id)

Now, let's have a look at the enum for *CtrlNumber*, defined as *ControllerNumbers*

Code: Select all

ControllerNumbers { 
  kCtrlBankSelectMSB = 0, kCtrlModWheel = 1, kCtrlBreath = 2, kCtrlFoot = 4, 
  kCtrlPortaTime = 5, kCtrlDataEntryMSB = 6, kCtrlVolume = 7, kCtrlBalance = 8, 
  kCtrlPan = 10, kCtrlExpression = 11, kCtrlEffect1 = 12, kCtrlEffect2 = 13, 
  kCtrlGPC1 = 16, kCtrlGPC2 = 17, kCtrlGPC3 = 18, kCtrlGPC4 = 19, 
  kCtrlBankSelectLSB = 32, kCtrlDataEntryLSB = 38, kCtrlSustainOnOff = 64, kCtrlPortaOnOff = 65, 
  kCtrlSustenutoOnOff = 66, kCtrlSoftPedalOnOff = 67, kCtrlLegatoFootSwOnOff = 68, kCtrlHold2OnOff = 69, 
  kCtrlSoundVariation = 70, kCtrlFilterCutoff = 71, kCtrlReleaseTime = 72, kCtrlAttackTime = 73, 
  kCtrlFilterResonance = 74, kCtrlDecayTime = 75, kCtrlVibratoRate = 76, kCtrlVibratoDepth = 77, 
  kCtrlVibratoDelay = 78, kCtrlSoundCtrler10 = 79, kCtrlGPC5 = 80, kCtrlGPC6 = 81, 
  kCtrlGPC7 = 82, kCtrlGPC8 = 83, kCtrlPortaControl = 84, kCtrlEff1Depth = 91, 
  kCtrlEff2Depth = 92, kCtrlEff3Depth = 93, kCtrlEff4Depth = 94, kCtrlEff5Depth = 95, 
  kCtrlDataIncrement = 96, kCtrlDataDecrement = 97, kCtrlNRPNSelectLSB = 98, kCtrlNRPNSelectMSB = 99, 
  kCtrlRPNSelectLSB = 100, kCtrlRPNSelectMSB = 101, kCtrlAllSoundsOff = 120, kCtrlResetAllCtrlers = 121, 
  kCtrlLocalCtrlOnOff = 122, kCtrlAllNotesOff = 123, kCtrlOmniModeOff = 124, kCtrlOmniModeOn = 125, 
  kCtrlPolyModeOnOff = 126, kCtrlPolyModeOn = 127, kAfterTouch = 128, kPitchBend, 
  kCountCtrlNumber 
}

So, together with the IMidiMapping interface, this is a somewhat really restricted affair.

[AdmiralQuality]

But I am not against other protocols, as long as they do not imply loosing functionalities. If Admiral is right, too bad. If not, then say where he is wrong. I, personally, find it hard to believe that Steinberg would be so stupid as to cur functionalities. I respect their skills as developers, and their vision (after all, ASIO and VST were created by them - if they didn't, we would still be paying thousands for DSP cards to do what our computers were able to do alone).

They indeed crippled Midi in a way. If you want to receive MIDI, you have to implement IMidiMapping and export every CC you are interested in as a VST parameter. With the help of IMidiMapping the host will translate the incoming MIDI data to your VST parameters.

The problem is that the IMidiMapping interface doesn't give you full control over the incoming MIDI message stream here.

The interface looks like this:

Code: Select all

getMidiControllerAssignment (int32 busIndex, int16 channel, CtrlNumber midiControllerNumber, ParamID &id)

Now, let's have a look at the enum for *CtrlNumber*, defined as *ControllerNumbers*

Code: Select all

ControllerNumbers { 
  kCtrlBankSelectMSB = 0, kCtrlModWheel = 1, kCtrlBreath = 2, kCtrlFoot = 4, 
  kCtrlPortaTime = 5, kCtrlDataEntryMSB = 6, kCtrlVolume = 7, kCtrlBalance = 8, 
  kCtrlPan = 10, kCtrlExpression = 11, kCtrlEffect1 = 12, kCtrlEffect2 = 13, 
  kCtrlGPC1 = 16, kCtrlGPC2 = 17, kCtrlGPC3 = 18, kCtrlGPC4 = 19, 
  kCtrlBankSelectLSB = 32, kCtrlDataEntryLSB = 38, kCtrlSustainOnOff = 64, kCtrlPortaOnOff = 65, 
  kCtrlSustenutoOnOff = 66, kCtrlSoftPedalOnOff = 67, kCtrlLegatoFootSwOnOff = 68, kCtrlHold2OnOff = 69, 
  kCtrlSoundVariation = 70, kCtrlFilterCutoff = 71, kCtrlReleaseTime = 72, kCtrlAttackTime = 73, 
  kCtrlFilterResonance = 74, kCtrlDecayTime = 75, kCtrlVibratoRate = 76, kCtrlVibratoDepth = 77, 
  kCtrlVibratoDelay = 78, kCtrlSoundCtrler10 = 79, kCtrlGPC5 = 80, kCtrlGPC6 = 81, 
  kCtrlGPC7 = 82, kCtrlGPC8 = 83, kCtrlPortaControl = 84, kCtrlEff1Depth = 91, 
  kCtrlEff2Depth = 92, kCtrlEff3Depth = 93, kCtrlEff4Depth = 94, kCtrlEff5Depth = 95, 
  kCtrlDataIncrement = 96, kCtrlDataDecrement = 97, kCtrlNRPNSelectLSB = 98, kCtrlNRPNSelectMSB = 99, 
  kCtrlRPNSelectLSB = 100, kCtrlRPNSelectMSB = 101, kCtrlAllSoundsOff = 120, kCtrlResetAllCtrlers = 121, 
  kCtrlLocalCtrlOnOff = 122, kCtrlAllNotesOff = 123, kCtrlOmniModeOff = 124, kCtrlOmniModeOn = 125, 
  kCtrlPolyModeOnOff = 126, kCtrlPolyModeOn = 127, kAfterTouch = 128, kPitchBend, 
  kCountCtrlNumber 
}

So, together with the IMidiMapping interface, this is a somewhat really restricted affair.

Thank you. I was forgetting exactly what was f**king stupid about it. That's it!

[tony tony chopper]

No, that's what you do. I make plug-ins to make hosts, programmed by dull minded, restrictive, unimaginative people, do wonderful things that the host developers would have never thought of. (The whole point of supporting plug-ins, isn't it?)

yeah.. without you, sequencers would be short of.. VA-synths...

[AdmiralQuality]

No, that's what you do. I make plug-ins to make hosts, programmed by dull minded, restrictive, unimaginative people, do wonderful things that the host developers would have never thought of. (The whole point of supporting plug-ins, isn't it?)

yeah.. without you, sequencers would be short of.. VA-synths...

I have more in me than just the best VA synth. Stay tuned. (If I can ever get by this platform schism, that is. Something you wouldn't understand, as you RESTRICT your users to only Windows.)

And apologies for suggesting I think I'm good at what I do for a living.

[tony tony chopper]

The 7-bit limit is a myth. Since the beginning, the MIDI protocol allowed two messages (MSB and LSB) to be sent together, to make a 14-bit big message. It's not the most elegant approach. but it works, and 14-bit is detailed enough, as far as I'm concerned.

Try to send CC pairs to a random VST, & see how it handles them.
It only makes sense when you AGREE on it, and no one does, so it's just like an unused API.

I've supported enough MIDI controllers to know that there is nothing generic out there, except notes & 7bit CC's.

I agree when you talk about other controllers, but the musical world has been taking very little advantage of them (I remember the Nintendo Glove several years go).

are you seriously mentioning nintendo's power glove? no need to go further, then..

[hokkaido]

Thank you. I was forgetting exactly what was f**king stupid about it. That's it!

Well the most interesting thing to me would be to know how host developers decide to implement the translation of incoming midi messages to a VST3 instrument.

For instance, in VST3 note information in transmitted by Events which can be of type

Code: Select all

EventTypes { 
  kNoteOnEvent = 0, kNoteOffEvent, kDataEvent, kPolyPressureEvent, 
  kNoteExpressionValueEvent, kNoteExpressionTextEvent, kChordEvent, kScaleEvent 
}

If it's a kNoteOnEvent you can extract the note's velocity, pitch, tuning etc.

If it's kPolyPressureEvent you can extract the pitch and the pressure.

I don't know whether the hosts are smart enough to automatically translate an aftertouch MIDI message to a kPolyPressureEvent. I would assume so, there's nothing in the SDK where it says that host developers are required to do so.

The same vice versa, if I'm sending a kPolyPressureEvent, are the hosts smart enough to translate this into an after touch message when routing this to Midi?

Maybe tony tony chopper knows more about this.

[AdmiralQuality]

I've supported enough MIDI controllers to know that there is nothing generic out there, except notes & 7bit CC's.

And pitch bend and mod wheel! They exist and actually do something! FYI, I know this is news to you.

[fmr]

I agree when you talk about other controllers, but the musical world has been taking very little advantage of them (I remember the Nintendo Glove several years go).

are you seriously mentioning nintendo's power glove? no need to go further, then..

[aciddose]

And pitch bend and mod wheel!

Well, technically "modulation" (wheel isn't included in the official name) is just another controller code. The label attempts to ensure it is used for a modulation of something, but doesn't specify what.

It isn't required by the standard, although it is commonly implemented as a primary controller due to the fact it is the first available control code.

(Obviously you wouldn't use bank-select...)

Actually the fully standardized controllers are limited to RPNs and primary events:

Note off,
Note on,
Pressure, ("polyphonic aftertouch")
Control,
Program, ("program change")
Aftertouch,
Pitchbend,
System.

MIDI is without a doubt one of the dumbest, most haphazard slapped together at the last moment interfaces out there.

The official list of controllers has changed so many times it is hard to keep track. You're limited to 32 different high-word values with optional low-word (for 14 bits) components and no reliable way to accept these pairs. Then you have a handful of additional controllers and a heaping serving of "undefined" values.

Meanwhile they decided there might not be enough "undefined" values hanging around not being used by anything, so they decided anything new should be encoded using the RPN system. Works fine of course, but really we should have replaced "pressure" with it and left "control" as a simple collection of 48 14-bit pairs and 32 other controls like polyphony, pedals, ...

Only steinberg could take an already completely whacked out system and replace it with something worse

[mystran]

You wanna send a pitch bend range RPN to VST's? Count how many will properly interpret it (none?) vs how many will think it's just CCs automating something else.

I certainly interpret pitch bend range properly (specifically to deal with FL with it's weird default cooking for 12 semitones), and I also parse all the other special cases correctly (very few things actually work, but no CC confusion here).

Actually the fully standardized controllers are limited to RPNs and primary events:

Your list is missing hold-pedal, which is pretty standard too... plus (at least outside plugins) everyone should probably support all notes off and all sound off.

[AdmiralQuality]

And pitch bend and mod wheel!

Well, technically "modulation" (wheel isn't included in the official name) is just another controller code. The label attempts to ensure it is used for a modulation of something, but doesn't specify what.

Sure. Probably to not make Roland feel inadequate with their spring loaded mod "buttons" that return to zero when you let go of them. (Speaking of disabling the user!)

It isn't required by the standard, although it is commonly implemented as a primary controller due to the fact it is the first available control code.

All I know is when I load a synth into FLS and try to use the mod wheel it has no effect. Restrictive. (Have they fixed this yet? I only touch FLS when a customer has a bug report.)

(Obviously you wouldn't use bank-select...)

Actually the fully standardized controllers are limited to RPNs and primary events:

Note off,
Note on,
Pressure, ("polyphonic aftertouch")
Control,
Program, ("program change")
Aftertouch,
Pitchbend,
System.

MIDI is without a doubt one of the dumbest, most haphazard slapped together at the last moment interfaces out there.

The official list of controllers has changed so many times it is hard to keep track. You're limited to 32 different high-word values with optional low-word (for 14 bits) components and no reliable way to accept these pairs. Then you have a handful of additional controllers and a heaping serving of "undefined" values.

Nothing compels you to actually use them for those purposes though. Consider them recommended defaults. Surely at the controller end or the instrument end, you can change one of them.

Meanwhile they decided there might not be enough "undefined" values hanging around not being used by anything, so they decided anything new should be encoded using the RPN system. Works fine of course, but really we should have replaced "pressure" with it and left "control" as a simple collection of 48 14-bit pairs and 32 other controls like polyphony, pedals, ...

Only steinberg could take an already completely whacked out system and replace it with something worse

You can call MIDI "whacked out", but I've had a lifetime of success with very little trouble using it. The biggest problem with Steinberg's new system is it's nothing. It's not a standard. It's not an interface that you can plug-in to anything physical, or even communicate to other programs with. It's only between host and plug-in, and it's entirely dependent on MIDI input! (Unless you're entering everything in non-realtime with the mouse.) But it then denies the plug-ins that same MIDI because... why? To shield us from having to understand MIDI? As if they understand it better than me. Like they think their labyrinthine VST3 implementation isn't ridiculously opaque? VST 2.4 already had MIDI mashing problems (it can't take sysex messages larger than usual message sizes). MIDI was always meant to be quick, dirty, cheap, easy and ubiquitous. That was the idea. Graceful wasn't.