Add support for sending Midi CCs out of VST3 plugins

General JUCE discussion
1

Upon entering the rabbit hole of investigating why I cannot generate any MIDI Controller Messages (or Pitch Bend for that matter) in my VST3 MIDI Plugin and have it show up at the output, yet it works perfectly fine in my AU version of the same thing, I have discovered that apparently passing MIDI CCs to the output of a VST3 was removed by Steinberg in the initial spec, but has been added back in as of December 2018. That’s almost a year ago.

Searching this forum, I have come up with multiple threads discussing this problem, the fact that Steinberg added it back in, and the fact that JUCE does “not yet” support it.

I’m wondering why has this change not been reflected to JUCE yet? And when might we expect it to happen?

For myself, I am writing a MIDI plugin that generates Controller Messages, as well as notes and pitch bend. I need to send all of this stuff to the host and have it appear at the output. The fact that it works in an AU plugin but not VTS3, when it’s now possible for it to work in a VST3, is disappointing. I don’t mean to complain, I really like JUCE so far and kudos to the team, and Jules.

Reference:

https://www.kvraudio.com/news-print.php?id=43543

https://forum.juce.com/t/generating-midi-messages-within-a-vst-plugin-and-passing-them-to-the-host/31472/3

https://forum.juce.com/t/missing-events-on-midi-out-from-vst3-plugin/30927

https://forum.juce.com/t/generating-midi-messages-within-a-vst-plugin-and-passing-them-to-the-host/31472/6

https://forum.juce.com/t/midi-cc-messages-in-vst3/34031/14

2
3

I wonder how much time it will take Steinberg to understand that:

  • VST3 makes it unnecessarily difficult for developers to produce MIDI effects.In the video in the above post they already admit it at the beginning: they are only addressing those designing MIDI instruments. Not a single mention to the many MIDI effects that have been (and are still released) as VST2’s. In VST3, it is neither straightforward nor always possible to translate perfectly from MIDI to the “VST3 protocol” and viceversa, so it is perfectly understandable that the JUCE developers haven’t been able to do it yet in a convincing way.
    You might argue against the usefulness of MIDI effects but even Logic decided to include a MIDI effect version of their AU a few years ago. Ableton has MIDI effects and Cubase too but their users are forced to use the ones provided by the DAW which, by the way, feature very limited UI’s.

  • In the video they claim that the “VST3 protocol” shields Steinberg from changes in the external protocols when it looks to me that the MIDI protocol has been much more stable that their own (this legacy method to send Midi CCs is a perfect example of it). Specially after MIDI 2.0 addresses in consensus with the other manufacturers some of the parts that VST3 was trying to improve unilaterally, why the need to include yet another protocol to translate to and from? In the video you see that in Cubase they have to translate from Cubase Internal Format to MIDI2 and VST3 in different steps. I think this is even harmful for the Steinberg developers and adds unnecessary complexity to their products!

2 Likes
4

After watching that ADC video I am struck with the feeling that the near feature is going to be a confusing mess related to midi… We have MIDI1 and VST2 which have worked very well for decades…and then we have MIDI2, MPE and VST3…all from too many cooks in the kitchen, as far as I can see, each protocol was developed by separate parties with different interests. And we are going to have a more complicated then ever issue in front of us.

The thing that really got me, Steinberg set out to create something where they hoped the API would not change over time. However, by going down the road they have gone, which has proven problematic for 3rd party developers, now MIDI2 is out…and is not following VST, instead there are numerous conflicts between the two approaches that have to be resolved by the host. WHAT? so plugin devs have no control over the host usually…we will be suffering for at least a decade with this host does it this way and that host does it that way… IMHO this is all a complete screw up in the industry and I am left completely discouraged about spending time to develop MIDI Plugins, with JUCE or without JUCE. Legally I’m not allowed to develop one in VST2 with the old simple paradigm that basically works as expected, granted with 7bit midi events, etc…but still…it works reliably and predictably in all hosts (well all hosts that are old enough to have a license for VST2 hosting that is). VST3…MPE…MIDI2…that is a complete open question with so many conflicting issues that are going to be hitting this industry like a ton of bricks in the coming years…and meanwhile we’re not allowed to develop for the old VST2 standard anymore.

I feel like my hands are tied actually…some of the midi plugins I have in mind require VST2 reliability in terms of midi serial event ordering, which has been lost entirely by Steinberg’s effort to abstract everything into what they have viewed as a superior API and way of working in their API as an abstraction layer above midi. That, in and of itself, has been problematic for many people…including JUCE’s partial adoption of VST3. Now with MIDI2 and MPE also out there…the division between what Steinberg decided to do 12 years ago with VST3, and the new midi standards coming out now…is growing even wider in my view. Yet another reason to stick with VST2 development for the time being until it all sorts itself out…but alas, as a new developer, I am not allowed.

5

I find it both sad and ironic. With MPE and MIDI 2.0, an update to the VST standard would certainly makes sense. Unfortunately Steinberg chose to do it 10 years too early, and as a consequence had no clue what they should be aiming for in terms of MIDI support.

Talk about premature optimisation.

I can’t but help think of VST 3 as the Windows Vista of the audio world. But - after strong arming the entire industry into adopting the VST 3 standard prematurely - Steinberg is hardly in a position to admit their mistake and just move on to the next major version like Microsoft did.

4 Likes
6

I think that’s all true. I also think that they made some assumptions about midi that were short sighted and lacking vision of how people have been managing midi for decades, even with everything they knew 12 years ago.

For example, midi has been for decades a serial protocol, where the order of midi events is respected by virtue of the protocol being serial. That has been true whether you’re talking about midi sent down a wire, or midi events sitting on a queue in software.

With VST3 they decided to change the way midi data is handled in a VST3 plugin, such that CC and other non-note events need to be placed in a different queue then the notes themselves, thus losing serial order. In the cases where a timestamp of a note and CC on different queues is the same, the exact output ordering is thus undetermined and lost, not withstanding that other plugins, processes, programs or midi devices further back up the chain may have put those events into a serial order assuming that order would be preserved.

Their assumption at the time was, I guess, that serial order should not be respected and that only timestamp should be respected, and that in the case where events have the same time stamp, undetermined order should result. Well I’m being tongue in cheek, I don’t think they wanted undetermined order, I think they just missed the fact that many midi related components have no ability to timestamp anything, and certainly there are many cases where midi events can be on the same timestamp but still need to be processed in a certain order. For example midi chords are often stored in a DAW’s region with the same timestamp. There may need to be other messages inserted in between each note of the chord for various purposes…which has always been possible using the event editor of your favorite DAW if nothing else, but by other means as well. And with VST2, that order will be respected. With VST3 plugins, it is undetermined.

That is but one simple example…

7

Does anyone know if there are plans to implement LegacyMIDICCOutEvent in JUCE? Or does anyone have this working in a fork?

Since there is support for this in VST3 now, it seems like an unnecessary limitation…

8

Well, I never put it into a fork, but I did an experiment awhile back to see if I could get it to work:

At the time, I was more thinking about VST3 plugins, rather than hosts…

9

don’t forget midi in too.

10

So I’ve been reading up more about the VST3 midi problem. Gaining a better understanding since I can’t get a VST2 license.

What I understand is that VST3 basically is anti-midi. :wink:

CC’s are not sent into VST3 plugins through the normal midi buffer. Only notes. CC can’t be generated and sent at all. Many people complained.

Steinberg issued a small update with an extra CC legacy function that can be used to send CC events, this was added to VST3, however such a thing would be not ideal for JUCE because we basically want the JUCE api to be the same across VST2, VST3, AU, etc.

VST3 only gains access to incoming CC midi events by assuming the host will place CC’s into a separate area of parameters which can be accessed from inside the plugin, when using VST3 directly. Again, this would be outside the scope of what should be done with JUCE because we want the API to be common with the other plugin formats.

Also this hack around that people are using in VST3 to handle CC incoming midi, has many downsides… But one of the downsides not mentioned often is that the serial ordering of CC events intermixed with note events can be lost for any given process block window of time, or perhaps per timestamp. For example if you have cc-note-cc-note-cc-note on the same timestamp (or perhaps within same process block), then what comes into VST3 plugin is one parameter value for the last CC message received in that time window, and then three midi notes, which should be in proper order in the buffer with the same timestamp. But the additional CC messages are lost and even if they weren’t lost, there is no way to interleave them back in between the notes before handling by the instrument.

In short, VST3 is fundamentally problematic… midi-in is broken, midi-out is only available through a special added function from Steinberg last year that would be a VST3-only thing, not desirable for JUCE use.

I would like some clarity about what exactly JUCE is doing in order to handle midi in VST3 instrument and midi plugins?

I am more and more of the opinion I may have to take my chances releasing VST2 midi plugins even though I don’t have a signed license. I don’t see any other way fgrankly because the timing issues mentioned above are critical for what I want to do. Steinberg has been very short sighted with VST3, even recently I see their devs arguing with 3rd party devs on the SDK forum.

1 Like
11

You could probably get away with that as long as your operation is small and you can fly under the radar. But I think releasing a purely “legacy” VST plugin is likely to prompt some kind of reaction from Steinberg if they take notice (not necessarily full on litigation though).

I actually ditched the first 2 ideas I had for MIDI plugins, mainly because they would only work as VST2. I wouldn’t have any serious moral qualms about publishing VST2 plugins without a license but I’m trying to build a business and I want it to rest on a solid foundation. I might bend a rule or two as long as no one get’s hurt, but probably better not to break them :wink:

YMMV

12

That’s about how I feel about it. I mean first of all there will continue to be literally thousands of vst2 plugins in circulation for years to come. And while it might be possible for Steinberg to tell me stop distributing my vst2 plugin I don’t think they could prove any damages to themselves as long as cubase still hosts vst2.

If they even bothered to do that. I’m never going to be a big developer, just some little tools and no employees. Pursuing that legal action would be even more stupid then what they have already done. That being said I’m not at all opposed to making vst3 if and when midi works properly. Especially with juce it’s easy for now though juce is not currently really conforming to vst3 in my view because of all the differences. From what I can see it’s severely crippled in vst3 terms, for valid reasons. But still juce removes the alleged vst3 complications that some people talk about, so why not. My vst3 versions will just be crippled.

But I also think that the mere fact they are allowing only select older companies to distribute vst2, Including themselves while restricting new competition through that license is a severe anti trust issue that nobody is big enough to fight them over it but if they sued me I’d sue them back and there are a lot of holes in their position and bad PR also they would go along with it.

13

I’m not defending Steinberg, but to be fair, they allowed a very long, and very public, period of time in which anyone could sign up for a VST2 license. The process was very easy—you sign the form and send it in. They sign it and send it back. In my case, it took less than two days.

And, I am a very small entity, definitely not one of the “big players”.

I do agree that they should allow for VST2 hosting for legacy reasons. That would be to their benefit, IMHO.

14

And what if you were not developing plugins at that time, but now you are, and you want to work on a plugin that acts as a host for other plugins? (and not a whole DAW…)

15

Until midi is fixed in VST3, there is still a problem with needing VST2 for midi plugins also if you want to be able to host your plugins in Cubase or on windows.

16

I’m not defending Steinberg, but to be fair, they allowed a very long, and very public, period of time in which anyone could sign up for a VST2 license. The process was very easy—you sign the form and send it in. They sign it and send it back. In my case, it took less than two days.

Hurray for you. Unfortunately, while obtained the SDK many years ago and may or may have gotten signed anything, I can’t recall now. I never released anything so I wasn’t too worried about it until such time that I would be releasing something.

I was not developing or paying attention when Steinberg dropped this bomb in Sept 2018 out of the blue without any warning. Otherwise I would have done as you and many others in the know did…rush to get a signed agreement. In any case, it doesn’t matter. What if I had never developed before and was trying to get into it now? I have no reasonable ability to put time into plugin or host development while competing against you lucky suckers that managed to get signed agreements while excluding the rest of us. That is practically the definition of anti-trust.

17

As I recall, the deadline was in October of 2018. But, they announced the end of licensing for VST2 several months before that. My VST2 license is dated June 27th, 2018. I no longer recall when they originally announced the deadline, but it was well before June of 2018, because I procrastinated a few months before dealing with it. So, it is unfair, and inaccurate to characterize it as dropping a bomb.

Again, I do agree that VST2 hosting should not be restricted for legacy reasons.

18

I was not actively involved with development at any time during 2018. never heard about it. Give it a rest dude. glad to hear you are part of the secret VST insiders club.

19

It was known 3-4 months before September 2018 that they would no longer issue VST2 licenses : Steinberg closing down VST2 for good.
In June someone from Steinberg confirmed on that thread that after October 2018 new developers will not be allowed to distribute products making use of the VST2 SDK.
But if you’re completely new to the game then it sucks balls as there was no way of knowing that.

I still think there is an argument that disallowing VST2 hosts for new developers may fall under some EU competition rules, if you’re an EU citizen you could try talking with your MEP about it.

20

it was not known by me. I am not totally new to development, but I was not involved with any of it during 2018.

In my view if they were going to make a move like that it should have been a year long period to give everyone a chance to find out and get licensed. But let’s be real, that’s not what Steinberg wanted. They wanted to lock people out. And they have! But now I’m discouraged from developing on that platform because I’m not allowed, but you lucky people that were in the know in 2018 get to keep doing it indefinitely. Lucky you! Enjoy your privilege and please stop defending such immoral business practice by Steinberg.