Add support for sending Midi CCs out of VST3 plugins

In the meantime, let’s see what can be done inside JUCE with the current situation.

fwiw I think abstracting MIDI messages into the callback is the wrong model. MIDI is the transport layer for some event messages. VST3 doesn’t provide an abstraction for MIDI but for events to and from the host.

It’s the view of the Steinberg devs that the role of the host is not to supply the plugin with the transport layer protocol, but the events for the host. This includes some things that correspond directly to MIDI like NoteOn/NoteOff but not other things like control changes. It’s their view that mapping CC to parameter changes is the domain of the host, and personally I agree with that. Sourcing events from a plugin that can be explicitly MIDI is exorbitantly problematic in terms of structuring the engine and adds an additional domain of complexity that is not necessary.

The hazard here is that hosts let users synthesize the transport layer messages directly through the midi editors, but I don’t think as a plugin developer you should be privy to those. If you have to think about how something enters your plugin and is routed, like a CC message, then you’re adding much more complexity than just handling parameter changes and leaving it to the host to route them.

The issue is when you want your messages to wind up as output to hardware expecting midi. But in that regard, it’s the domain of the host to talk to hardware. Not plugins. If you want to do such a thing, write a host.

WRT issues with licensing, I don’t want to be harsh but go write your own app with its own API for plugins. Because the plugin APIs are designed to extend hosts, not to allow your code to run arbitrarily in any host made by the original API devs competitors.

Edit: I think a good middle ground here that is hard to do right now in JUCE is allow you to add on to the wrappers to support things that only exist in certain APIs. The plugin wrapper and build approach is not structured to allow this, which makes sense because it’s hard and of little benefit for most devs. But it would be worthwhile. Providing a way to extend the AudioProcessor API to support API specific features would fix a lot of this problem.

ps: VST2 was deprecated in 2013. Everyone had years to move on, and they didn’t for good and bad reasons.

1 Like

so does all this mean vst3 plugins can still not send out midi data in juce? because i am planning on a plugin, one of my most important projects, where i’ll need midi 2.0, vst3 and midi out. it doesn’t matter if it’s a synth- or effect-type, though

Pitch bend would be nice. And mod wheel, although it is technically a control change.

Sorry, but that’s just nonsense.

VST2 is a de facto industry standard. It is used in most established DAWs out threre and is by far the most common plugin format. Thousands of VST2 plugins are not available as VST3, and many of them never will be.

Steinberg controls the VST2 standard, and this puts them in a pretty powerful position. With such a position comes a responsibility to ensure that all players in the market are free to compete on equal terms (at least in the EU).

For plugin developers the problem may not be that severe (although it is certainly a limiting factor), but host developers are pretty much screwed. How would you ever launch a DAW without VST2 support that could compete with Cubase and other established DAWs?

If Steinberg feels so strongly about VST3 adoption, perhaps they should lead the way by removing support for VST2 plugins from their own DAWs (which is obviously not going to happen).

Refusing to grant VST2 licenses to new market entrants may very well violate EU antitrust laws (which are pretty strict… ask Microsoft and Google).

4 Likes

:+1: I couldn’t agree more.

2 Likes

Juce support is one thing, but the main problem seems to be that many DAWs will only pass note on and off messages from VST3 plugin outputs, although (legacy) CC output was added to the VST3 standard some time ago.

i already prototyped my plugin with midi1 and vst3 in plug`n script in cubase 9.5.5, where it worked nicely, so it seems to be possible in general. didn’t try in other daws myself but some dude used it in reaper succesfully

@Holy_City That is a very narrow view of what cc messages can and are used for by musicians. Musicians have been using cc messages for all manner of things beyond the simple case of parameters to effect notes; for decades. I hear you that it’s a nice abstraction in that one simple case but other uses cases such as key switching are ignored here. And there are many other use cases. The abstraction now is not good enough because event ordering is lost. It might be elegeant from an academic computer science point of view but the result for the midi user is reduced functionality and capability compared to what they have had for decades available to them through the midi protocol

Bluecataudio basically did the hack around. His scripter provides a callback with midi buffer just like juce. I would assume the midi order is lost in some cases there but I need to test that

1 Like

i’d be interested in your opinion after testing it. pns is my favourite framework for just testing stuff and having fun but it has a bad cpu performance so it’s definitely not where you’d wanna finish your work. i only used their midi functions a bit yet so i’m not sure how powerful and correct they are, but so far i had only good experiences with them

I’m not super expert with that scripter I just know he has been working for a while to hack around the vst3 midi problem and recently announced it can handle it. Like juce, pns has a processblock call back with a midi buffer where all the events are expected. Like juce, you would not want to expect a user script one way for vst2 and a different way for vst3. But I will try to make a test later, and I’m reasonably sure that as a vst3, some midi event ordering will be lost.

1 Like

I think that it adds depth to a DAW to be able to write modular virtual MIDI controllers, custom MIDI sequencers, Chord Generators and LFO’s to control plugin parameters to mention a few examples of “MIDI Effect” plugins. This is only possible if you allow MIDI to flow from one plugin to the next one in the chain otherwise you have to come up with solutions such as Max for Live with worse performance and poorer UI’s. I personally think it is overkill to write an entire new host just to add those specific parts, and your reasoning could be extended to the entire plugin ecosystem by affirming for example that side-chained Vocoders and Compressors add unnecessary complexity to the host.

I would agree if I wasn’t a Cubase user :upside_down_face:

2 Likes

i am a cubase user and i can’t agree more. i even wrote a mail to the support about this feature request once because it made me so furious that they just ignore the fact that midi effects have the potential to be awesome. lol, sometimes i feel like the dudes at steinberg aren’t even musicians. else i can’t explain to myself why they would restrict themselves like that

https://sdk.steinberg.net/viewtopic.php?f=4&t=672

I ran a quick test with Cubase and PNS to see what happens to midi. Here are the results, not good.

  1. First I created a short series of midi events using Cubase list editor. Its a chord with a CC in front of each note of the chord, all on the same timestamp:
CC32 = 5
Note C3
CC32 = 10
Note E3
CC32 = 15
Note G3
  1. If I sent this output an external midi monitor, I get the intended result:
Time Source Message Chan Data1 Data2
670687536500589 From IAC A Control 1 32 5
670687536500589 From IAC A Note On 1 C3 127
670687536500589 From IAC A Control 1 32 10
670687536500589 From IAC A Note On 1 E3 127
670687536500589 From IAC A Control 1 32 15
670687536500589 From IAC A Note On 1 G3 127
670687659417255 From IAC A Note Off 1 C3 64
670687659417255 From IAC A Note Off 1 E3 64
670687659417255 From IAC A Note Off 1 G3 64
670688074567299 From IAC A Control 1 32 15
  1. If I send this midi track through BlueCatAudio’s PlugNScript VST3 with no script in it, just pass the midi through it, the midi event ordering is scrambled.
Time Source Message Chan Data1 Data2
671154315226085 From IAC A Control 1 32 5
671154315226085 From IAC A Control 1 32 10
671154315226085 From IAC A Control 1 32 15
671154315226085 From IAC A Note On 1 C3 127
671154315226085 From IAC A Note On 1 E3 127
671154315226085 From IAC A Note On 1 G3 127
671154438126447 From IAC A Note Off 1 C3 64
671154438126447 From IAC A Note Off 1 E3 64
671154438126447 From IAC A Note Off 1 G3 64
671154852521847 From IAC A Control 1 32 15

As suspected, just getting the midi data from the host, in this case Cubase, into the VST3 plugin scrambles the exact intended ordering of events. I don’t think there is anything BlueCatAudio can do about this and it makes no difference to the actual BNS script, it will not have midi data available as originally ordered.

1 Like

I also ran a test where the input event list is several CC32 messages with different values in front of a single note. For some strange reason, this makes it through ok, both with and without the bluecataudio plugin inserted. That leads me to believe that all three CC messages are queued up by Cubase using the iMidiMapping interface and PNS is able to retrieve them in the correct order order before handling any notes. In this case there are no interleaving notes in between the CC events so its ok that all the CC’s are passed through followed by all the Notes. In other words, its not only the last CC that will be seen by the plugin… at least with Cubase as the host. Hard to say whether other hosts will all make sure to post all CC events to iMidiMapping on a given process block or timestamp.

I also ran a test using a different script plugin, LuaProtoPlugin. that one loses CC’s entirely. Hehe. That developer will need to do the same hack around that BlueCatAudio did if they want to distribute VST3 version.

I also ran a test with the VST2 version of PNS, and that does NOT lose the correct ordering.

1 Like

i wonder if steinberg will finally update vst3 to work properly with midi once midi 2.0 gets released. maybe they are just waiting for it to happen because they don’t want to work out the same thing twice

I don’t think they see it as a problem. Go to that SDK forum link i posted earlier. read through the end of the thread. Steinberg’s rep on that forum is still arguing about it. They have a narrow minded view about how CC’s should be used.