Add support for sending Midi CCs out of VST3 plugins

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…)

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.

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.

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.

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.

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.

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.

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.