Are VST3 widely adopted now?

[mystran]

i thought i read the vst3 sdk includes vst2 and wrappers for vst2, au, aax. and the license thing changed with vst3 but also included vst2. but maybe i misread that.

It used to be that VST2 was included, but they've dropped it since.

[AndyMusician]

As a new developer, I can't release VST2 plugins, I would need a license for that and Steinberg stopped giving it in October 2018 if I remember well.

[Lind0n]

As a new developer, I can't release VST2 plugins, I would need a license for that and Steinberg stopped giving it in October 2018 if I remember well.

Correct, if you want to make VST plugins of any flavour - and you dont already have a VST2 license from S'berg then VST3 is your only option.

[EvilDragon]

Native Instruments still do not accept VST3 in their apps for the keyboards (Komplete Kontrol) they sell. This is really something to be ashamed. It is not so hard to switch to VST3. But I will not return to VST2 now.

Except Super 8 R2 that was released is VST3 and opens in KK and Maschine. VST3 support for other plugins will be coming down the line.

sample-accurate automation (very important)

And very very few VST3 plugins actually use it, because this also means you cannot really smooth your automation sufficiently, which can lead to glitches in the DSP (which is usually block processed). Block processing of automation has its benefits.

How many DAWs actually implement sample accurate automation? How many plugin wrappers -- I don't think juce does.

I know at least Cubase and Reaper do, not sure about others. S1 perhaps as well.

[Markus Krause]

Please note:

- Resizing the GUI is not a VST3 feature. It works also with VST2.4.
- Very accurate automation is also possible with VST2.4.
- silent output (=bypass processing when there is no input) is possible with any plugin

Please do also note:

- VST3 has no real Midi support
- It is much more complicated to develop a VST3 plugin

I recommend the use of the VST SDK 2.4 or 3.6.9 (still inlcudes 2.4 support).

[mystran]

Please note:

- Resizing the GUI is not a VST3 feature. It works also with VST2.4.
- Very accurate automation is also possible with VST2.4.
- silent output (=bypass processing when there is no input) is possible with any plugin

Please do also note:

- VST3 has no real Midi support
- It is much more complicated to develop a VST3 plugin

I recommend the use of the VST SDK 2.4 or 3.6.9 (still inlcudes 2.4 support).

Side-chains with VST2.4 also work with just about any host other that those from Steinberg.

[EvilDragon]

Resizing the GUI in VST2.4, while possible, can have way more issues between different hosts, based on how you do your UI lifecycle. It can work perfectly in some hosts but have weird issues in others, simply because different hosts make different assumptions on how the UI should be created/destroyed and order of various operations. VST3 API is standardizing this at the very least, so plugin scaling behavior is a lot more consistent between hosts supporting VST3.

It's still a mess of an API, but it's not as if it doesn't have ANY positive points.

- VST3 has no real Midi support

This particular thing... I go back and forth on it. Hard-coding MIDI 1.0 into your API really limits the possibility to support i.e. new features that MIDI 2.0 will bring. From that perspective, Steinberg did good to abstract the MIDI implementation to a data-agnostic protocol. Now the way they went about it and limited various things that were possible with direct MIDI support is uncool, sure, but the abstraction itself as an idea is a good one, since with VST3 it will be much easier to support MIDI 2.0, whereas I foresee VST2.4 plugins won't be able to take advantage of additional MIDI 2.0 features that are not backwards-compatible to MIDI 1.0 (32-bit floating point CCs, 16384 registered CCs, note on/off messages carray more data with themselves, bidirectional communication, etc.).



That said, it's really nigh time to move everything to VST3, because VST2.4 won't work natively on ARM Macs ever (and you can bet Apple will kill Rosetta 2 eventually), and VST3 already supports that.

[Markus Krause]

Midi 2.0 or MPE can be sent and submitted also trough any midi 1.x device. It's just a bytestream.
So it's possible to support it with a VST 2.4 plugin - as long as the host forwards midi-stream to the plugin.
I sucessfully implemented MPE in a VST 2.4 plugin (Icarus2).

Can you please give us more detailed info why VST 2.4 should not work natively with ARM Macs?

[FigBug]

That said, it's really nigh time to move everything to VST3, because VST2.4 won't work natively on ARM Macs ever (and you can bet Apple will kill Rosetta 2 eventually), and VST3 already supports that.

I'm pretty sure this isn't true as I've built both a VST2 ARM host and plugin, there doesn't seem to be any issues.

[EvilDragon]

Midi 2.0 or MPE can be sent and submitted also trough any midi 1.x device. It's just a bytestream.
So it's possible to support it with a VST 2.4 plugin - as long as the host forwards midi-stream to the plugin.
I sucessfully implemented MPE in a VST 2.4 plugin (Icarus2).

I am not talking at all about MPE, which is a MIDI 1.0 spec extension. I am talking about MIDI 2.0 specific messages and features that are not MIDI 1.0 backwards compatible. I wonder how would you make them work with VST2.

[Markus Krause]

The MIDI 2.0 protocol is an extended version of the 1.x protocol. To support Midi 2.0 you need to add some code to handle the stuff.
https://www.midi.org/midi-articles/deta ... y-exchange

[EvilDragon]

Yep, and that is probably not gonna be possible for VST2, since it's not supported anymore, right?

[EvilDragon]

That said, it's really nigh time to move everything to VST3, because VST2.4 won't work natively on ARM Macs ever (and you can bet Apple will kill Rosetta 2 eventually), and VST3 already supports that.

I'm pretty sure this isn't true as I've built both a VST2 ARM host and plugin, there doesn't seem to be any issues.

Well, ok, but for that host VST2 plugins would also need to be ARM compiled, no (in a future after Apple inevitably kills Rosetta 2)? Good luck with that

[fese]

I prefer VST3 wherever possible. Installation is easier, no need to filebrowse again and again to your VST directory or get mad at stupid installers that just install them to whatever they think is the standard, of which there is none. VST3 just goes into the default directory and gone are the days of endlessy organizing plugins in folders.

I have never noticed that VST3 plugins had more bugs than VST2, if a plugin was crashing the DAW it was with either format.

Don’t see big differences between VST2 and 3 when using them, i gotta admit, apart from VST3 being sidechain capable in Cubase. And I don’t care that other DAWs can do that with VST2 because I don’t use other DAWs.

[syntonica]

Resizing the GUI in VST2.4, while possible, can have way more issues between different hosts, based on how you do your UI lifecycle. It can work perfectly in some hosts but have weird issues in others, simply because different hosts make different assumptions on how the UI should be created/destroyed and order of various operations. VST3 API is standardizing this at the very least, so plugin scaling behavior is a lot more consistent between hosts supporting VST3.

It's still a mess of an API, but it's not as if it doesn't have ANY positive points.

- VST3 has no real Midi support

This particular thing... I go back and forth on it. Hard-coding MIDI 1.0 into your API really limits the possibility to support i.e. new features that MIDI 2.0 will bring. From that perspective, Steinberg did good to abstract the MIDI implementation to a data-agnostic protocol. Now the way they went about it and limited various things that were possible with direct MIDI support is uncool, sure, but the abstraction itself as an idea is a good one, since with VST3 it will be much easier to support MIDI 2.0, whereas I foresee VST2.4 plugins won't be able to take advantage of additional MIDI 2.0 features that are not backwards-compatible to MIDI 1.0 (32-bit floating point CCs, 16384 registered CCs, note on/off messages carray more data with themselves, bidirectional communication, etc.).



That said, it's really nigh time to move everything to VST3, because VST2.4 won't work natively on ARM Macs ever (and you can bet Apple will kill Rosetta 2 eventually), and VST3 already supports that.

A couple of things. Resizing in VST2 is just a quick call to the host telling it the new size you want and it says yea or nay. If true, then just redraw to your new size on the next redraw cycle. You may get a glitch for a frame or two while the host redraws the window frame, but its usually not noticeable since it all happens in a couple of frames.

ARM easily supports VST2. There's nothing special about it. As long as the host compiles to ARM with support in.