EvilDragon wrote: ↑Tue Jan 26, 2021 2:27 am
The problem that dewdman42 explains is real, you've got the usecases explained where it is real and current VST3 "way to deal with that" is flawed because not all DAWs support VST3 fully, so there is no real solution that would behave identically across all DAWs.
All you said is true, but I just want to clarify one point. Even if all vendors came together, the basic design of VST3 completely prevents synchronization of different midi event types on the
output from VST3 plugins, because they use the separate midi stream in the legacy out, eventually running into event type synchronization problems that nobody can hack-around, not even Cubase. VST3 simply should not ever be used for a
midi plugin without expecting those kinds of issues sooner or later. Only VST2 should be used for midi plugins, IMHO. Presuming you have a license that is.
VST3 could theoretically be used for instrument plugins where the midi doesn't continue thru, and if a host were following the VST3 concept to the letter, then theoretically the exact midi ordering of various things could be ensured while rendering sound in the plugin. This is primarily by means of the NoteExpression concept in VST3. I'm not talking about NoteExpressions in the GUI, I'm talking about in the API itself. The Cubase NoteExpression GUI is just a direct way in Cubase to specify midi events that should be attached to notes, and basically there is an API that mirrors that functionality, its part of VST3. So via the NoteExpression API, a host can ensure that CC's happen in the exact order they want relative to the notes. Theoretically. I've never done it, but that is my understanding.
The problem is that 99% of host DAW's do not have any kind of NoteExpression GUI, and possibly could be even a patent problem to add it I might add. My view is that most third party VST3 hosts are not using this part of the VST3 api at all. They are using other means to provide simple expression values to the plugin..which creates event synchronization problems, at the least. Even Cubase itself does not look to be doing anything with this part of the API except for when you actually use the NoteExpression feature in the GUI! Try putting CC switches into expression maps and note how often people end up complaining about problems in certain situations. Cubase is broken too!
I think it all traces back to this fundamental problem that Steinberg chose to disregard completely the importance of respecting the atomic order of different midi event types intermixed, not only coming from hardware, but as stored in midi track data, as well. Musicians have been using this feature of midi for several decades to reach their musical goals. As you said earlier, how can Steinberg pretend this does not exist?!?!
What they all would need to do, including Cubase, is to examine all midi events before calling the plugin, and when it sees that there are CC events on the same sample offset as notes ( or perhaps within same process block)...it would need to implicitly call the NoteExpression API for those...to make sure they will be handled in correct order by the plugin. That is assuming of course, that the plugin is even looking for NoteExpression data...which I think the vast majority are not. So any host that did that, would probably break a lot of plugins.
Steinberg simply did not think this through very well and they have made it increasingly worse by tacking on the legacy out feature, which created as much problem as it solved, and then blocking new devs from even being able to use VST2 anymore...they have just increasingly worsened the situation. Its still not clear to me if they even understand the problem or if they do understand it but are choosing not to solve it for some self-interested motivation. It baffles me honestly. I don't even see what's in it for them, I doubt they are getting more Cubase sales this way. More likely there are internal Steinberg politics at play, and they architected Cubase a certain way, around VST3...so to change VST3 would mean they have to go back and make a lot of changes to Cubase..which is costly and also might cost someone their job...etc..
On top of all that we have JUCE and iPlug, etc. These are taking over the plugin development world. I think hardly anyone develops directly to the VST sdk anymore, nor to the AU sdk either. There are some cases where people have to do so because until now JUCE and iPlug simply do not provide complete access to those underlying API's. For example, JUCE still cannot handle multiple midi ports with VST3/AU3. But in any case, there are very practical reasons for using a cross-platform SDK such as JUCE for developing plugins....and that is why many people have chosen it. Or others. But these systems also increase the VST3 problems since they are modeled much more closely around the VST2 concept, and that is also unlikely to change anytime soon.
Steinberg has another problem too in that they granted all those VST2 licenses and I'm not sure they can ever legally take them away from those that already had them. So as long as that exists, there will always be a few VST2 developers around, for many years to come, that can and will continue to develop VST2 solutions. NI for example....nowhere near VST3 as of yet. So what motivation do VST host developers have to radically change their internals to use the complicated VST3 stuff that is needed to even get close to proper midi operation? They have very little motivation to do so.
Steinberg must be thinking that by cutting off new developers from VST2, new developers will be forced to use VST3 and then perhaps host developers will get more into VST3, but there is simply too much momentum already with VST2 from people that will not change exclusively to VST3 anytime soon. All this does is cut out new developers from helping us all with solutions in the midi domain.
