Are VST3 widely adopted now?

[mystran]

And that means that I export 16*127 parameters on top of the existing one, no ?

16* 16384 for NRPN?

[arne]

LegacyMIDICCOutEvent

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

Not the best name, I agree. But normally you are also more talkative...

[otristan]

And that means that I export 16*127 parameters on top of the existing one, no ?

16* 16384 for NRPN?

127 MIDI CC on 16 channels not 127 steps

[EvilDragon]

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

I reckon that is exactly what they're doing.

[Funkybot's Evil Twin]

As a new developer, I have no choice but to develop VST3 plugins. Do people still prefer VST2 or it's a thing of the past?

I prefer VST2 where both are available because it's generally the least buggy, better documented, and more thoroughly supported of the two formats. Where things are VST3 only though, I have no problem using VST3. If you're starting fresh, it's probably easier to just support the one format and troubleshoot that.

[mystran]

And that means that I export 16*127 parameters on top of the existing one, no ?

16* 16384 for NRPN?

127 MIDI CC on 16 channels not 127 steps

I was not entirely serious.

[Markus Krause]

Dear Steinberg-team,

Please stop 'extending' the VST3 sdk with ugly and halfhearted hacks to fulfill the real demands of the industry (SingleComponentEffect, LegacyMIDICCOutEvent, Legacy VST2.4 support, etc).
Fix it *PROPERLY* and REDESIGN YOUR INTERFACE. Please perceive the reality. After 10 years the VST3 SDK has failed. No developer likes it. It's badly designed, over-complicated and inefficient. That's my personal opinion as a professional who has spent that last 20 years with programming software for your interfaces (VST 1.x, VST2.2, VST 2.4, VST 3.6, VST3.7). And most of us audio-devs share this opinion. If the VST3 SDK would be good such projects like JUCE (which even cost money for closed source projects!) would not exist.
Instead of spending even more time into justifying questionable design-decisions your team should sit down and start programming on VST4. Keep it simple, keep it slim and stick to the standards of the industry (MIDI).

[softdevca]

So why are we relying on Steinberg to the define the interface between plugin and host?

[xoxos]

So why are we relying on Steinberg to the define the interface between plugin and host?

because the entry point to computer music for most participants is defined by the marketplace.

[softdevca]

I can appreciate how Cubase/Steinberg used to be the front runner and where the masses got into computer music (unless you went down the professional Pro Tools route). But is Steinberg still filling that role? It seems to me that FL Studio, Live, Studio One, Bitwig, Logic are all much more relevant to the modern scene. I bet VST standard sticks around because it's the current standard rather than a good one. As long as a new standard has a no-install VST bridge to help the transition it's probably less of a big deal for users than we think. I would love to not have to uncheck VST2 32-bit VST2 64-bit, VST3 32-bit, AU and AAX when installing a plugin.

I may have > 20 years of software development experience but little direct VST development so please ignore everything I say on the topic.

[Urs]

But normally you are also more talkative...

It doesn't make any sense to argue, right? You're understandably convinced that VST3 is technically better than some of us plug-in developers make it out to be. We can simply agree to disagree, nothing will change anything. I don't think it ever has.

The support for post-MIDI APIs etc. is deeply embedded in the industry and IMHO part of a bigger problem. Host people commonly seem to want to avoid giving plug-in developers low level access to things. Don't do this, don't do that, don't you dare. The reasons behind that are multi facetted. One easily identifiable cause is the design of the APIs which lead to "bad experiences". And again, we can agree to disagree.

[Richard_Synapse]

In my opinion it would be best to keep VST3 as it is, otherwise we all have yet another format to support. All professional developers need a capable wrapper anyway, due to AU, AAX or even RE. Once that works, it is set and forget.

Richard

[Urs]

In my opinion it would be best to keep VST3 as it is, otherwise we all have yet another format to support. All professional developers need a capable wrapper anyway, due to AU, AAX or even RE. Once that works, it is set and forget.

Richard

The problem is that VST3 simply doesn't stay as it is.

Here's what broke the last straw for me. For years we have asked for MIDI Learn with a non-clumsy method. I can probably find posts or emails where a Steinberg employee officially said, I paraphrase, "do not make 16 x 128 dummy parameters for MIDI assignments, use the VST3 way instead". So we did that. But our users wanted MIDI Learn, and they did not believe us that MIDI Learn did not work in VST3, because Steinberg's own plug-ins had it. We lost customers and nerves and money over this. So we asked Steinberg if they were willing to do MIDI Learn if we coded it for them. They said "yeah, let's see what you got". So we co-financed an effort to do this, and our guy presented the working (!) idea. And Steinberg said "no, we're not gonna do this". And then, after we went back to 16 x 128 dummy parameters, they finally came up with their own MIDI Learn a year to two later. This is so unbelievably frustrating.

[Dirtgrain]

We lost customers and nerves and money over this. So we asked Steinberg if they were willing to do MIDI Learn if we coded it for them. They said "yeah, let's see what you got". So we co-financed an effort to do this, and our guy presented the working (!) idea. And Steinberg said "no, we're not gonna do this". And then, after we went back to 16 x 128 dummy parameters, they finally came up with their own MIDI Learn a year to two later. This is so unbelievably frustrating.

Damn, that sounds awful. I wish there were a coalition of plugin developers that could take the keys away from Steinberg, as what they have done has been unhealthy for the industry. I wonder why they act so. Is it that they are being Bill-Gates-style nastily competitive? But are they truly benefitting from being so, if that is the case? Are the take downs working out for them? I'm hearing more about it in various forums, and Steinberg is looking worse and worse for it.

[Urs]

We lost customers and nerves and money over this. So we asked Steinberg if they were willing to do MIDI Learn if we coded it for them. They said "yeah, let's see what you got". So we co-financed an effort to do this, and our guy presented the working (!) idea. And Steinberg said "no, we're not gonna do this". And then, after we went back to 16 x 128 dummy parameters, they finally came up with their own MIDI Learn a year to two later. This is so unbelievably frustrating.

Damn, that sounds awful. I wish there were a coalition of plugin developers that could take the keys away from Steinberg, as what they have done has been unhealthy for the industry. I wonder why they act so. Is it that they are being Bill-Gates-style nastily competitive? But are they truly benefitting from being so, if that is the case? Are the take downs working out for them? I'm hearing more about it in various forums, and Steinberg is looking worse and worse for it.

Well, it was very frustrating, but it wasn't the end of the world. I don't think anyone at Steinberg is a bad person or deliberately wants to be overly competitive. Let's not exaggerate and and insinuate a conspiracy of giant proportions.

It's just the status quo that's not particularly satisfying, when a standard is tailored around the needs of a single company. Obviously, they won't add things that their own host has no concept for. They also won't publish new things unless their hosts supports them (it needs to be tried and tested after all, behind closed doors).