Are VST3 widely adopted now?

[arne]

VST3 does not submit a midi channel for noteOn and noteOff events

Reading the documentation may help: https://steinbergmedia.github.io/vst3_d ... Event.html

[arne]

And further reading here : https://developer.steinberg.help/displa ... I+in+VST+3

[Markus Krause]

Dear Arne,

you're right with the midi channel. But all the other problems do remain and are ignored by Steinberg (you?).
It would have helped us devs if you provided a proper documentation before 2018.

I am also wondering why Steinberg/you continously ignore the feedback from developers and customers.
You just should have done your work properly and have fixed your design-flaws years ago instead of doing strange anti-patterns as workarounds.

I am a full-time audio-developer. The VST3 SDK was the most horrible experience I had within the last 25 years of software development. I used the VST3.7 SDK for Warlock and your code is a complete mess. It's overengineered and obfuscated and fails compiling in many places. Instead of focusing on my audio code I wasted most of the development time with the interface.
That's why I recently moved from VST SDK 3.7 to Juce. I will not further waste my time with a an obfuscated and broken SDK that has tons of bugs.
And please don't advice me that I 'just should visit Steinberg's developer forum' to get help. I had already done this and don't need to receive insulting ('you're a stale old programmer') and un-helpful feedback ('use the latest SDK we do not longer support this version') from your team.

I once was a big fan of Steinberg, but meanwhile I am not longer a fan.
What really upset me was:
- Steinberg's lawyers take actions against open-source projects that use the VST2.4 SDK by sending DMCAs
- Steinberg's lawyers take actions against freeware websites with 'VST' in the name (vstplanet.com etc) by sending DMCAs
- By using contracts you force us developers to use the VST3 SDK that is inefficient for our demands. This hinders us from working efficiently.
- Steinberg doesn't make the VST 2.4 SDK open source for no valid reason
- Cubase on the Mac does not support audiounits and apearently will drop support for VST2.4

But I am sure you'll get your shitstorm from the M1 Mac customers when a large part of their plugins will stop working.

[arne]

Dear Arne,

you're right with the midi channel. But all the other problems do remain and are ignored by Steinberg (you?).
It would have helped us devs if you provided a proper documentation before 2018.

I am also wondering why Steinberg/you continously ignore the feedback from developers and customers.

I'm unsure why you have such a hate against me personally. But OK, this is the internet...

But it's just wrong that Steinberg ignores developers that can explain their issues in a way that is not a rant.
There were many additions to the SDK directly from developer feedback. As an example is the LegacyMIDICCOutEvent or IMidiLearn. And also the license was changed because of feedback.

And just to make it clear, your other technical claims that VST3 would not support MIDI program change or that you have to expose dozens of parameters to support MIDI CC is just the result of not reading the documentation properly.
And regarding MIDI 2.0, there's no DAW or anyone supporting it yet, so don't give the impression that this is a problem of VST3. The way VST3 will handle this is by far the most efficient way. Only the hosts need to be updated. VST3 Plug-ins will work out of the box with most of the new features. Sure if you don't support Note Expression before, MIDI 2's per note controller will not magically work in your plugin.

And please, don't make "me = Steinberg". There are so many good developers @ Steinberg it is unfair that you give me all the credit.

[Markus Krause]

Hello Arne,

But it's just wrong that Steinberg ignores developers that can explain their issues

Sorry for the rude way of expressing myself. It was not targeted towards you as a person.
I explained my issues many times in a friendly way in the past and got ignored or received short, snappy or unhelpful answers from your team.
I also wasted one (!) complete year of development with the VST3 SDK. Just to find out that it doesn't work properly and move to Juce.
I hope you can understand my frustration. I must create and income and feed my family.

to expose dozens of parameters to support MIDI CC is just the result of not reading the documentation properly.

So appearently the Juce team, U-he and myself didn't read the docs porperly? Sadly this ugly anti-pattern is necessary if you want to support Midi learn within your own interface or have a mod matrix.
https://forum.juce.com/t/vst3-plugins-h ... ters/28536

please, don't make "me = Steinberg".

I was under the impression that you're one of the leading developers of the VST SDK. Who is the responsible person behind the VST3 SDK architecture then? Are you doing VSTGUI only?

the license was changed because of feedback.

Good to see this. I was also pretty upset when reading it.

My feedback is:
- seriously listen to developers and customers
- Make the VST2.4 SDK open source
- VST3 SDK is messed up. It needs a redesign. Accept this. Do your work properly and create a VST4 SDK. Keep it slim and downward compatible with VST 2.4 and bring back midi.
- don't abuse your dominant market position
- don't be so aggresive with your trademarks and licensing towards small companies

[arne]

So appearently the Juce team, U-he and myself didn't read the docs porperly? Sadly this ugly anti-pattern is necessary if you want to support Midi learn within your own interface or have a mod matrix.

As already mentioned: IMidiLearn and a proper parameter layout for a mod-matrix will solve this problem without creating parameters for all MIDI-CC.
The problem is that you want to do the same thing with VST3 as it was done with VST2. And this is not how VST3 works (for good, to prevent ambiguity of parameter automation and MIDI-CC automation).
And by the way, we talked with many VST3 host developers and no one (really no one I'm aware of) was unhappy with dropping the direct integration of MIDI. Especially the different MIDI learn UI of every plug-in is seen as a mess.

VST3 SDK is messed up. It needs a redesign. Accept this. Do your work properly and create a VST4 SDK. Keep it slim and downward compatible with VST 2.4 and bring back midi.

The VST3 API was a result of many years and many people discussing and solving the problems of VST2. What you propose is to ignore this knowledge and bring back something that made a mess in all DAWs today.

[otristan]

So appearently the Juce team, U-he and myself didn't read the docs porperly? Sadly this ugly anti-pattern is necessary if you want to support Midi learn within your own interface or have a mod matrix.

As already mentioned: IMidiLearn and a proper parameter layout for a mod-matrix will solve this problem without creating parameters for all MIDI-CC.
The problem is that you want to do the same thing with VST3 as it was done with VST2. And this is not how VST3 works (for good, to prevent ambiguity of parameter automation and MIDI-CC automation).
And by the way, we talked with many VST3 host developers and no one (really no one I'm aware of) was unhappy with dropping the direct integration of MIDI. Especially the different MIDI learn UI of every plug-in is seen as a mess.

While it could make sense for FX, I don't see how this make sense for an instrument.
MIDI CC are great to have high level generic controller.

[arne]

The problem is that MIDI CC has no meaning. It's a kind of black-box wiring. Why should an instrument not be able to announce its capabilities to the host?

[otristan]

For the same reason that you guys don't do it in Halion ?

[arne]

Yeah, it's flawed too in HALion. That's correct. I did not say that Steinberg is flaw free.

[Markus Krause]

So appearently the Juce team, U-he and myself didn't read the docs porperly? Sadly this ugly anti-pattern is necessary if you want to support Midi learn within your own interface or have a mod matrix.

As already mentioned: IMidiLearn and a proper parameter layout for a mod-matrix will solve this problem without creating parameters for all MIDI-CC.
The problem is that you want to do the same thing with VST3 as it was done with VST2. And this is not how VST3 works (for good, to prevent ambiguity of parameter automation and MIDI-CC automation).
And by the way, we talked with many VST3 host developers and no one (really no one I'm aware of) was unhappy with dropping the direct integration of MIDI. Especially the different MIDI learn UI of every plug-in is seen as a mess.

While it could make sense for FX, I don't see how this make sense for an instrument.
MIDI CC are great to have high level generic controller.

That is one of the main problems that I have with the VST3 SDK: It does not properly work for synthesizers. And it does not work properly for complex projects

[otristan]

Except you allow this trick in Halion and do not offer us the same interface. I don't mind having a new way of doing thing but that don't means that the old way is clunky and should be removed

[arne]

Which trick do you mean? The IMidiMapping trick with creating parameters for every MIDI CC. That's available for all.

[otristan]

And that means that I export 16*127 parameters on top of the existing one, no ?
Don't think Halion does that AFAIK.
We use the JUCE wrapper now FWIW.

[Urs]

LegacyMIDICCOutEvent

The naming says it all. The frustration of a committee baked into the name of an otherwise sensible API.