yeah, i saw that. man, that’s terrible. he even believes it won’t make a difference when midi 2.0 drops even though this is literally a whole different thing. i mean in midi 2.0 we’ll be able to apply pitchbend to each note instead of to each bunch of notes and that’s only one example. how can he say that’s the same? or maybe i just don’t get it because i’m still too much of a noob, but i feel like he is just restrictive for no reason. i looked up his website and there are only discontinued products. why does he have something to say in the first place? he might have worked with midi for 30 years already but he doesn’t even aknowledge that many people are unhappy about the situation.
Well… like it or not, it’s Steinberg’s prerogative to make decisions on the separation of duties between hosts and plugins in VST3. They define the standard, and they are under no obligation to ask anyone for input.
But I do think they have an obligation to continue making VST2 available. A very large part of the industry is built on this standard, and just as Steinberg are free to do with VST3 what they want, developers (new or old) should be free to stay on VST2, rather than adopt VST3.
If developers choose not to adopt VST3, perhaps it’s because they don’t see how doing so will bring any value to them and their customers. I think there’s a lot to like about VST3, but unfortunately it also takes things away (plugins being able to do MIDI stuff in particular). So for some developers, VST3 is actually a pretty big step back.
If Steinberg had allowed this thing to run it’s natural course, perhaps we would have seen the industry at large converge on a VST4 standard with the best of both worlds once all the MIDI 2.0 stuff has landed - and who knows, maybe we still will.
But until then, it would be nice to have the option to use VST2 for the stuff that can’t be done in VST3.
2 Likes
This is the problem with a proprietary “standard”.
It could even be that Steinberg are wishing to remove VST2 support from their software in long run. Perhaps they’ll wait an arbitrary length of time, remove VST2 support from Cubase et al and then revoke everyones VST2 licenses en masse (which they are free to do according to the terms of the license) so that it’s not such a “shoot yourself in the foot” move for them.
If that is their plan, then they had better give a bit more notice this time around! 
edit: this was nonsense, I imagined the part where they could revoke the license 
I don’t think so:
§ 9 TERM OF THE AGREEMENT
1. The Agreement shall run for an unlimited period.
2. If the Licensee is in breach of any of its obligations set out in this agreement, Steinberg shall be entitled to terminate this agreement immediately in writing and inform the Licensee verbally about it. In such a case, this license and all the rights granted to the Licensee herein shall immediately cease.
No one in their right mind would invest in support for VST2 if Steinberg could just revoke the license at a whim 
1 Like
That’s why those with a counter signed agreement are still allowed. All others are considered never to have entered the agreement.
You have my full sympathies, I wish it didn’t happen, and yes I regret I didn’t sign it either, because at that time I thought I would stay employed longer…
However, nobody at this forum can do anything about it, so I think repeating what Steinberg should do should be directed to their forum. Even if Arne or @ygrabit read here, they obviously don’t discuss here.
Lets focus here on workarounds and what JUCE can do to remedy this as good as possible.
4 Likes
1 Like
Arne’s stance is that vst is not a midi api, it’s for audio and the fact everyone is using it for midi is not their intention or desire. It’s a bit like talking to a wall honestly, they have dug in their heels and they aren’t going to change anything. I see them as acting irrationally without any regard for end user needs today in 2020. Numerous devs will be remaining on vst2 because of it, which is not Steinbergs desire. They seem to feel they can force the industry to switch to their new API which is not only new and different but also incapable of meeting some current user needs that are met by vst2. Its unfortunate since vst3 does provide new capability they users would also benefit from. So we stuck at an impasse with Steinberg it would seem. The fact that so many devs do have essentially the unblocked license to develop vst2 indefinitely means that situation will not change for Steinberg unless they bend in their point of view about vst3 and midi for one thing; or else provide some compelling new feature in vst3 that everyone runs towards vst3 in order to make marketable products based on it. I find it disturbing that one or a few people are deciding the fate for all daw users and developers everywhere.
I can’t see anything juce can do other then make sure the midi buffer queue that gets called back to process block gets filled with all non-note events inserted in timestamp order with all cc’s in front of notes. And also to look at the buffer after calling processblock callback and pull out cc’s and other events and repopulate various related parameters and/or use the legacy function to send these kinds of events out via vst3.
The ordering problem will still exist, sending out midi events will not work with all hosts either and frankly anyone relying on this ordering or midi out should not make vst3 plugins with or without juce.
There are other vst3 features not really supported by juce and we can talk about that. Like how to support multiple midi incoming ports. Midi out ports are not supported by vst3 according to Arne. But juce I think only supports a plugin with a single midi in port. One main advantage of vst3 over vst2 is the possibility to create a multi timbral instrument that can listen to more then 16 midi channels via ports. Maybe I’m missing it but I don’t see a way to do that with juce today.
2 Likes
Actually a better juce host hack around would be to convert a series of events on the same timestamp to notes and note expressions. Then inside the vst3 before calling the processblock callback, convert that into a properly ordered midi queue.
Juce vst3 plugins should always be looking for note expressions and making that conversion to the midi buffer queue with the current paradigm. At least all VST3 plugins should always be on the look out for NoteExpressions as they are fundamental part of the VST3 midi handling and currently the only way I can see to ensure that a sequence of articulating CC events will always be as intended in front of the desired notes… such as in the cc-note-cc-note scenario of keyswitching.
So in my view JUCE hosting should
-
Be on the lookout for multiple midi events of mixed type on the same timestamp and when found, use internal NoteExpressions for passing into VST3 plugins rather than as CC parameters.
-
At the end of plugin callback, it should make sure to be looking for NoteExpressions also in order to support synchronous CC midi output.
Juce VST3 plugins
-
Look for Notes and NoteExpressions and CC parameters. Build the midi queue buffer for the callback first using parameters, then by handling the notes and related note expressions, so that the resulting midi queue should be the same order that the host tried to provide by using note Expressions. (not all hosts will do that however)
-
At the end of processBlock, take the midiqueue and build outgoing noteexpressions to enhance outgoing notes, so that again, the intermixed order of the events intended by the plugin will be retained when they are on the same time stamp. If JUCE tries to use the legacyCC out function to send CC’s, then its the same problem as going in, separate queue and the order is lost. The only way to ensure order when there is a mixed set of events with the same timestamp is to attach NoteExpressions to notes, the VST3-way and send that back out to the VST3 host where hopefully it is smart enough to look for NoteExpressions also.
-
Provide multiple midi ports for VST3 plugins, and a way to detect those separate midi queues inside processBlock. Likewise, if possible provide multiple midi output ports, but Steinberg might not be allowing that its not clear now.
Sounds great in theory. Can you develop a working model of this in JUCE 5? I’d love to see this as a working model. It does seem like less of a hack than the current options in theory.
I’ve read many of your posts on this subject, and I can relate deeply to yours (and others) perspective on this. I’ve have been in the same boat since the initial release of VST3 back in 2008. I made the decision back then to just ignore VST3 as it failed at upholding the MIDI support already provided in VST2. So, all this new dialog on the subject is just digging up an old grave for me, and a glaring confirmation that our issues with it back then were completely justified. Fast forward 12 years and there still is no real resolve there. It’s strange, because without MIDI, I seriously doubt Steinberg would have ever made it to where they are today.
2 Likes
my primary interest is midi plugins. As such I am probably just going to take my chances on the license and use VST2 honestly.
I’m going to have to look into subhosting as a means to put midi plugin behavior in front of subhosting another instrument. This because many hosts don’t provide a good way to chain midi plugins. I just found out today, for example, that Cubase throws away midi event timestamps when you route one track to another track in order to route through a midi plugin. That’s no bueno either. Steinberg…sheesh…
I dunno, the situation is a mess. I don’t think the whole industry will bend to VST3 as long as so many people are still licensed and able to produced VST2. The only advantage for me on VST3 is the possibility for more than 1 midi port per instrument. That’s a big deal when using VePro.
Some of the things I suggested above will not really work because it sorta depends on all DAW’s and all plugins becoming more compliant with VST3 which I just don’t see happening any time soon.
The best route at this point is probably continue as is for the time being, make VST2 stuff, use VST3 for more ports or whatever, but just be careful not to rely on the serial aspect I’ve been complaining about for the past few days. Musicians should use NoteOn keyswitches always, avoid CC’s like the plague. Fine then, no problem there probably as long as they do that. They might have to stagger some notes on some chords occasionally to get around it.
For Simple changes to JUCE to support VST3, first my suggestion is everyone should keep using VST2 regardless of the license policy. It works as intended and all DAW’s are compatible with it. It just works reliably and predictably. I really don’t think steinberg wants to sue the small guys, they’re just trying to force a change. And if they tried, I think it would not only make them look bad, but probably would not hold up in court either. If everyone just keeps doing it what are they doing to do, sue everybody? We should not bend to Steinberg’s demands. We should make plugins using VST2 tech just like many developers will continue to do and eventually Steinberg will realized they need something better then the current VST3. If they go back to the drawing board and make VST4, it could be done in a backwards compatible and better way and everyone will be on board with it.
Secondly, there are some reasons to need to use VST3 today. Like if you need more than 1 midi-in port for example. So then the question here on this forum is…what should JUCE do to support VST3?
JUCE sorta has to support VST3 because the official line they have to tow is, VST2 is deprecated and VST3 is the standard. So if they really believe that, then they need to overhaul JUCE quite a lot to make it fully functioning according to the VST3 standard, and hopefully in some way that doesn’t break the ability take the same code and build VST2/AU from it.
As it is now, they have kind of a partial VST3 capability. As such I see no benefit to using JUCE for VST3. Zero, other then you’re afraid to release a VST2 due to steinberg’s licensing actions. But in some cases, if your plugin gets into heavy midi, then not only do you gain no VST3 benefits, you lose some VST2 benefits…so really it hurts more than it helps…albeit…legally compliant with Steinberg’s demands.
It would be nice if we could create VST3 plugins with multiple midi in ports. That would be a somewhat justifiable reason to make a VST3 version of an instrument plugin. In order to complete the picture, some midi out would be good. The interleaved mixed type problem mentioned earlier would still be there…but at least you’d have multiple midi in ports(a justifiable reason to use VST3 at the expense of some midi serialization problems in rare cases). And comply with Steinberg license at the same time.
I’m not completely sure what else is in VST3 to make it interesting, but as an end user I can tell you I almost NEVER select the vst3 version unless I want multiple midi input ports, such as with Vienna Ensemble Pro, and that is very big reason.
For the time being I think JUCE should just make more ports available, provide a way inside the process block to see a separate midi queue for each port, and provide something after the callback that takes CC’s out of the midi queue and sends them with the legacyCC function that steinberg allowed. That would be good enough for now I think.
Everything else that involves overhauling JUCE to comply more fully with VST3 api involves getting the entire industry to re-work their hosts and plugins to work the VST3 way, which I just don’t think is going to happen. if JUCE were to do that now, it would become incompatible with everything else out there in some ways.
Maybe eventually they could sneak in some optional features to access NoteExpressions and a few things like that. I think that would be valuable too, but not sure how that can be done without messing up the existing JUCE api such that we can write common code that builds for VST2/AU also. Its a thorny issue.
I have been thinking a lot about this problem over the last few days, and I have come up with an idea that just might work, both technically and legally.
I’m not sure this will fix all of the issues @Dewdman42 has been posting about, but I’m pretty confident it will work for me as I mainly need to be able to output MIDI pitch bend and CC (mod wheel) from my plugin.
I have noticed that VST3 plugins actually do output MIDI pitch bend and CC messages in the AudioPluginHost, so the problem here is that hosts do not implement the legacy CC stuff that was added to VST3 about a year ago (as @stephenk has also noted).
A technical solution to this could be to create a “dedicated” VST2 wrapper for your VST3 plugin (i.e. myplugin_wrapper.vst). You could use the AudioPluginGraph internally, just as the AudioPluginHost does. But rather than presenting the user with a UI to choose which VST3 plugin to host, the wrapper would be hardcoded to simply load “myplugin.vst3” at startup, replicate all its parameters and display its Editor to the user. This could be done in a way that is completely transparent to the user.
In this solution, the VST2 and VST3 stuff is placed in separate binaries that are only linked dynamically at runtime (by loading the VST3 plugin in the wrapper, which in this regard acts as any other VST host). These two binaries need not have the same author/publisher, and they could even be made available under different licenses.
The wrapper could be “published” by a developer that has a VST2 SDK license (it would be “published under his own name”, as the VST2 SDK license agreement puts it). However, the developer of the VST3 plugin could then distribute the wrapper along with his own VST3 plugin. In the installer, the user would accept a separate license agreement for the wrapper, making it clear that this plugin is provided by the VST2 developer and not the VST3 developer. This would be similar to users downloading plugins from a reseller’s website, which to my knowledge does not require the reseller to license any SDKs.
Or you could use one of the reverse engineered VST2 headers that are available under the GPL, e.g. VeSTige or FST. You would have to make the source code of your wrapper plugin available to customers (which shouldn’t be a problem), and the user would have to accept the GPL during installation rather than a license from a 3rd party VST2 developer. I know that Steinberg does not recognise the legality of reverse engineered VST2 headers, but I think especially FST has a pretty strong case for being completely legal.
there might be some thorny tech issues with getting the vst2 wrapper prebuilt binary to display the way you want as a different and unique plugin in the host plugin list for each vst3 that it’s wrapping; without violating the license. Honestly this is something steinberg should just provide in order that new developers can enter the space with new vst3 plugins that work in a backwards compatible way. I know they won’t though so never mind that.
There have been many discussions in the past whether the reverse engineered headers are legal or not and I gave up trying to follow it or have an answer to that question as everyone’s opinion on the matter just clouded the issue entirely. I heard sound arguments both ways. If you are going to use that then you don’t need a wrapper just do the whole thing as vst2 using that header. It may or may not be legal, but at least if you publish the source you won’t be publishing copyrighted material. I think however if you publish a binary that was built with it you could be violating the license. Probably.
No, I would actually build a unique wrapper for each VST3 plugin that is hardcoded to load and wrap its VST3 counterpart on startup. If i have the VST3 plugins “plug1.vst3” and “plug2.vst3”, I would have “plug1_wrapper.vst” and “plug2_wrapper.vst”.
Both VeSTige and FST are only available under GPL, so unless I made my plugin open source I would violate their license.
No. I didn’t enter into any license agreement with Steinberg for the VST2 SDK, and I certainly didn’t use it.In fact, I don’t even have access to that SDK - or the associated license agreement for that matter. There is no way I could be violating the VST2 SDK license agreement.
The guys doing VeSTige and FST are making the same claim. Also, they claim that reverse engineering the interfaces of products that implement VST2 is legal, and that the resulting header files are their property, not Steinberg’s. Hence, they are allowed to license them to me under the GPL.
I just might take their work for it
Hm. I just realized that the GPL doesn’t allow you to link closed source and GPL libraries even at runtine if they execute in the same process (at least not if you provide both libraries).
What a shame… 
But having another developer “publish” the wrapper should still be OK though… I don’t see how that would violate any licenses. The wrapper developer would need to have a license for both the VST2 and VST3 SDKs, and I would need only the VST3 SDK.
Which actually kills any GPL plugin… is that the case?
Seems as plugin developer you have to live with a certain amount of jeopardy.
So it would seem
But… I do believe that the end user is allowed to load your GPL plugin in a closed source host (or vice versa), as long as you are not providing the 2 software components together.
It’s a good point that if we never signed anything then we haven’t made any agreement whatsoever. In that sense I guess it would come down to copyright law as there are no patents here. Use their copyrighted material under their license, use the open source versions under gpl or reverse engineer the interface yourself.
We’re getting into hypothetical territory though and bear in mind that if they choose to sue, you have to pay to defend yourself with almost nothing to gain.from it.
Actually that might be the best solution. It just occurred to me that most (if not all) of the information you would need to make this work is actually available from the FST project: docs · master · IOhannes m zmölnig / FST · GitLab
Copying the FST implementation verbatim would obviously violate their copyright, but following the reverse engineering “guide” they created should be perfectly OK.
That’s very interesting, thanks for sharing! The nice thing those guys did was to document their reverse engineering journal, documented over time in git even. So if Steinberg ever tried to go after them, they have a well documented journal of exactly how they reverse engineered the headers step by step.
You just have to build your own header file, as you said, from their information…and then it should work without violating any copyrights. They note that it is still missing some opcodes and is not 100% complete replacement for the real thing, so presuming that is not a problem also.
I didn’t read it that clearly, but one question I have, did any of the symbol names remain the same as in Steinberg’s docs? If yes, would that violate copyright? If no, does that mean your VST2 app code has to use different symbol names that would not be able to compile with legit SDK in place?
Still… Steinberg could still try to sue. Then you’d have to fight to defend yourself. Will they try? Doubt it.
bla bla bla about legal junk......
Honestly I think even if attorneys were participating in this discussion they they would say that its not a clear cut situation and it could go either way if it ever went to court. I do think the above reverse engineered journal increases your odds. But having been involved in some lawsuits, I can say that people can and will sue over all kinds of meritless things based on complicated legalities, and the lawyers are the ones who generally win.
I don’t personally think Steinberg will file such a lawsuit against anyone, especially a small developer. A small developer would likely cave under any threat of lawsuit and give Steinberg whatever they ask for rather then trying to fight it. Its yet to be seen whether Steinberg will eventually try to round up all the illegitimate VST2 plugins out there and get them all shut down. I personally doubt it.
I think they might file a lawsuit against a new large competitor DAW if they ever tried to use VST2 hosting without a license in their competing DAW. It doesn’t make any business sense whatsoever to sue plugin developers that are developing plugins which enhance the use of Cubase and help it to be even better then it now is! However, if a competitor rose from the dust to create a large DAW that put Cubase to shame…with VST2 hosting and no license…well…maybe they might try to go after that developer. Of course, that developer would and should file anti-trust counter-suit. And it would be interesting. And maybe that will happen in 10 years, we shall see.
Some more wishful thinking...
Personally what I think needs to happen is a new plugin standard needs to come out so that the entire industry can free itself from the clutches of Steinberg’s whim. We need a third party intermediary who doesn’t have a separate financial interest based on a DAW host they make. Perhaps this could a totally independent body like MIDI, but I think that would take too long and probably wouldn’t happen. Could be through JUCE/ROLI perhaps. But anyway, they’d need to release an independent SDK and unique interface API…as well as wrappers to enable these plugins to be used in VST/AU hosts until the hosts themselves catch up. Once they all caught up, then we could all stop worrying about VST forever.
I personally don’t think open source is the answer to this problem, there is always too much GPL red tape involved with the GPL religion. The solution needs to be something that is available to all, for commercial or otherwise. Otherwise it will simply not replace VST ever. It would also have to be substantially better than VST in order to motivate old developers to adopt it.