how to work around midi in VST3?

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

arne wrote: Mon Jan 25, 2021 11:09 pm I give up, you don't want to. Have fun.
This is exactly the problem. Steinberg doesn't listen to plugin vendors (or if they do, the response is very slow to come, it took how many years to reintroduce the legacy methods for CCs and stuff to VST3?) and just do things their own way, and it's their way or the highway...

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. That is the crux of the issue, and this is why Steinberg should have had sat down with a bunch of plugin and host developers BEFORE VST3 was released to sort all this shit out. The problem is real, but the worse problem is Steinberg doesn't want to admit there are problems.

Post

MIDI was already old-fashioned as early as 1982 when it came out.
before time there was no time

Post

arne wrote: Mon Jan 25, 2021 11:09 pm I give up, you don't want to. Have fun.

Steinberg as usual
What do you expect from this guy.
Steinberg often points out the ability to switch the vsti off when no audio is running through as one of the big advantages of VST3.... but tell the cubase users to turn this feature off as its buggy as hell....no words

Post

EvilDragon wrote: Tue Jan 26, 2021 10: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.
MacPro 5,1 12core x 3.46ghz-96gb MacOS 12.2 (opencore), X32+AES16e-50

Post

Well, what they could definitely do is make the next major version of Cubase not support VST2 at all... You know it's gonna happen eventually.

Post

I think they might be foolish enough to try that, but then Cubase sales will drop radically. The simple truth is that everyone still needs VST2 plugins and I think Steinberg gains more from having VST2 available in Cubase...that will not change until VST2 plugins are far more scarce then they are today. Well they might try to do it, but it would be a foolish move on their part, IMHO. I for one, would definitely not upgrade to that version of cubase.
MacPro 5,1 12core x 3.46ghz-96gb MacOS 12.2 (opencore), X32+AES16e-50

Post

timefreezer wrote: Tue Jan 26, 2021 5:34 pm MIDI was already old-fashioned as early as 1982 when it came out.
Just like guitars, pianos, flutes or violins. I've heard that still some people use these antique devices today.

Post

Dewdman42 wrote: Tue Jan 26, 2021 11:38 pmSteinberg 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.
Yeah. Add to that the myriad of developers who missed the VST2 license deadline.
www.solostuff.net
Advice is heavy. So don’t send it like a mountain.

Post

EvilDragon wrote: Tue Jan 26, 2021 11:43 pm Well, what they could definitely do is make the next major version of Cubase not support VST2 at all... You know it's gonna happen eventually.
I think (not sure, may be imagining) that I saw once a wrapper that can encapsulate VST2 code and output VST3 binary. I imagine it's not impossible to do. May be eventually this is what would end-up happening to those VST2 devs who missed the train or just don't want VST3.

Albeit MIDI out won't work as intended and a couple of other things.
www.solostuff.net
Advice is heavy. So don’t send it like a mountain.

Post

EvilDragon wrote: Tue Jan 26, 2021 11:43 pm Well, what they could definitely do is make the next major version of Cubase not support VST2 at all... You know it's gonna happen eventually.
Yeah, and when they do ... did you see what happened in Washington DC at the capitol building on Jan. 6? Like that. :D

Post

You can bet they will do it and not care. I don't think they want to allow Cubase to load VST2 on Apple Silicon either (and my crystal ball tells me the next Cubendo will be the Apple Silicon compatibility release, among other things).

Post

There are already ways to wrap vst3 around a vst2 binary but then the vst2 will inherit all the vst3 problems that have been mentioned. Fortunately I don’t depend on cubase. If they do drop vst2 then that will be the end of the line for me unless they improve vst3
MacPro 5,1 12core x 3.46ghz-96gb MacOS 12.2 (opencore), X32+AES16e-50

Post

EvilDragon wrote: Wed Jan 27, 2021 11:20 pm You can bet they will do it and not care.
Only time will tell for certain. However, my bet would be that they will care rather a lot when Cubase sales plummet, as inevitably will happen. My money would be on them changing their mind within the year.

Post

Nah. Cubasers gonna Cubase. They tend to be a very faithful breed and I'm sure they have everything they need as VST 3 at this point. I bet the next major rev will see VST 2 dropped, or at the very least, deprecated, i.e. them saying this will be the last version too support it.
I started on Logic 5 with a PowerBook G4 550Mhz. I now have a MacBook Air M1 and it's ~165x faster! So, why is my music not proportionally better? :(

Post

believe me, Steinberg has a marketing dept that couldn't care two cents about VST2 vs VST3. They care about sales and I promise they are taking all that into consideration. It makes zero financial sense from a marketing perspective for Cubase to drop VST2 hosting capability today in 2021.

I am also pretty sure the Steinberg engineering dept is pushing for VST3-only since a long time ago.

So what happens politically inside that company will determine whether this scenario happens or not, but someone inside Steinberg engineering will have to convince someone inside Steinberg marketing that dropping VST2 would increase revenue. I see that as very unlikely to happen anytime soon. Never know though.

Steinberg is just another company with many moving parts and numerous personalities inside pushing their own little career agendas, etc... They are not a monolithic Borg attempting to consume all DAW users everywhere into a VST3 cube.
MacPro 5,1 12core x 3.46ghz-96gb MacOS 12.2 (opencore), X32+AES16e-50

Post Reply

Return to “DSP and Plugin Development”