Bye bye VST2

[JerGoertz]

The unfixable structural problems with VST2 are well documented:

• ...
• Loose/inaccurate timing of MIDI/automation events due to being coupled with the audio buffer
  ...

I didn't know about this one. MIDI timing issues is one of my big pet peeves and this might be enough to move me to VST3.

[baconpaul]

VST2 remains as a Standard today. In fact there are no VST2toVST3 or VST2toCLAP adapters.
Polac released a free VST3toVST2 some years ago. CLAPtoVST2 is unknown.

There is zero technical reason that the current clap wrapper, which projects clap into vst3, auv2 and standalone (And soon aax) could not project a clap into a vst2, although that would be a far lower resolution experience than a native clap or the clap projected into vst3 of course. Honestly I think it would take about 2 days to write from where we are with the wrapper now. The problem is entirely license based, and steinberg being unwilling to let folks ship vst2 software.

The clap license is not encumbered in the same fashion as vst2 or vst3; no party has the ability to stop clap programs or source projects from being distributed now or in the future.

[jamcat]

project a clap into a vst2, although that would be a far lower resolution experience than a native clap or the clap projected into vst3 of course.

People like VST2 for its lo-fi vibe.

[Urs]

The unfixable structural problems with VST2 are well documented:

• ...
• Loose/inaccurate timing of MIDI/automation events due to being coupled with the audio buffer
  ...

I didn't know about this one. MIDI timing issues is one of my big pet peeves and this might be enough to move me to VST3.

MIDI timing is sample accurate in VST2, regardless of buffer size.

What's not in VST2 (but in AU/VST3) is timestamped parameter changes for automation, but when asking hundreds of developers, one would find that nobody has ever implemented this. Maybe because popular frameworks such as JUCE do not support it. I think that's because all of these formats implement automation events concurrently to MIDI, and MIDI always wins, and nobody can be arsed to mitigate the concurrency.

Hence, in practically all plug-ins using common formats MIDI is accurate, Automation isn't.

That's where CLAP shines because it does not implement automation and MIDI in a concurrent way. With its unified event queue we were able to implement time stamped automation within a single day. We still smooth automation events, but whatever influence buffer size had, it's gone in CLAP.

[JerGoertz]

That's where CLAP shines because it does not implement automation and MIDI in a concurrent way. With its unified event queue we were able to implement time stamped automation within a single day. We still smooth automation events, but whatever influence buffer size had, it's gone in CLAP.

Interesting. Would you say CLAP is a superior format overall to VST2/3?

[Urs]

That's where CLAP shines because it does not implement automation and MIDI in a concurrent way. With its unified event queue we were able to implement time stamped automation within a single day. We still smooth automation events, but whatever influence buffer size had, it's gone in CLAP.

Interesting. Would you say CLAP is a superior format overall to VST2/3?

I'm a little bit biased here. Might be better to ask someone else who creates plug-ins or hosts with VSTx and CLAP, but who wasn't involved in the design of either.

[Calagan]

Clap is what we all need...

[baconpaul]

That's where CLAP shines because it does not implement automation and MIDI in a concurrent way. With its unified event queue we were able to implement time stamped automation within a single day. We still smooth automation events, but whatever influence buffer size had, it's gone in CLAP.

Interesting. Would you say CLAP is a superior format overall to VST2/3?

I'm a little bit biased here. Might be better to ask someone else who creates plug-ins or hosts with VSTx and CLAP, but who wasn't involved in the design of either.

I'm going to bypass the licensing discussion, which has been discussed before, and where the CLAP license is clearly superior to the VST3 licensing scheme, since I don't think that was the intent of your question.

And so "Superior" is difficult to judge and full of bias. But you can look on technical merits.

VST3 and CLAP both support sample accurate parameter automation and CLAP VST2 and 3 both have timestamped midi. (VST2 puts all automation events at the top of the block so it is block size dependent).

There's some programming reasons why implementing VST3 parameter automation is very painful, though, mostly involving the queue structure presented by the API to the developer. One of the things in CLAP which is clever is all events, no matter their nature or provenance, come in a single sample time ordered event in every block. This is much easier to implement.

As such, implementing sample accurate CLAP automation is natural, whereas in VST3 its quite tedious, and so many bits of code and popular frameworks retain the vst2-style 'grab the last'.
the same is true for note expressions, which again are a powerful but infrequently implemented VST3 feature. It's worth asking why, with what 15 years of VST3, these aren't things we all use.

As Urs mentioned, the popular frameworks have also not adapted to these features. JUCE (which is basically a 'wrapper' approach on `juce::AudioProcessor` which is roughly a VST2-look-alike semantically) doesn't provide sample accurate automation, just MIDI. (And even a subset of the MIDi was wrong until fairly recently because the VST3 treatment of MIDI as a non-existent protocol for software). the JUCE team has plans to fix this in JUCE 9; and the clap juce extensions currently give you a get-out-of-jail-free option which lets your JUCE-clap skip directly to the CLAP api. This is how Surge XT CLAP gets polymod, note expressions, sample accurate automation, etc... despite being a JUCE plugin for the other formats.

Funnily, the easiest way to implement VST3 note expressions and sample accurate automation today is probably to write a CLAP and use the CLAP->VST3 wrapper, which has done the painful and annoying work to unpack and repack the vst3 queues into something useful. That's how six sines and short circuit get note expressions and automation.

Hope that helps.

[JerGoertz]

Thanks for the in-depth explanation!

[BONES]

Clap is what we all need...

You're kinky, I've spent most of my adult life trying to avoid it.

[jamcat]

I've spent most of mine trying to contract it.

[baconpaul]

Thanks for the in-depth explanation!

You're welcome.

Theres a bunch of other things which make CLAP great (thread pools, poly mod, non-destructive automation) which VST3 doesn't have, just like theres a bunch of things that make VST3 a necessity (live and cubase, for instance).

But most devs who have coded both find CLAP a more sensible code path.

And of course, I brushed over the license issues, but they really really matter.

[wikter]

VST1.0 was just a bare-bones I/O system for processing extensions via .dll, and VST2 just tacked MIDI 1.0 onto it. VST3 was designed to address structural problems in VST2 and be far more adaptable, robust, forward-looking, and future-proof than VST2 was (think MIDI 2.0, sandboxing, etc). That was the reason VST3 needed to happen. There isn't any such need for a VST4.

there you have it, from our resident expert on structural problems in APIs.

The unfixable structural problems with VST2 are well documented:

• Fixed number of input/output channels
• Parameters identified only by numeric indices
• Only basic MIDI 1.0 messages rather than abstracted events
• Loose/inaccurate timing of MIDI/automation events due to being coupled with the audio buffer
• Audio processing and GUI handling were intertwined
• Lack of API standards for side-chaining, surround sound output, plugin states, or presets
• The VST2 SDK did not adhere to C++ coding best practices

Each bullet point listed above was enough to require a rewrite on its own.

Those problems mainly happened in Steinberg Cubase, and certain old 2.0-2.3 plugins/hosts. For 25 years i've used or tested throughly:
Cubasis (cant remember versions, VST2 support)
Cubase VST3.7/5
Cubase SX 1/2/3/4
ProTools 4, 5, 7, 8
Logic Pro 4/5/7/9/X
Ableton Live 2/3/4/7/10
Reaper 1/2/3/4/5/6/7
Presonus Studio One 1/2/3/4/5/6
Bitwig 1/2/3/4
Jeskola Buzz 1/2
Stagelight 2/3
Zenbeats 1/2/3
Tracktion, Waveform and almost any DAW or Host left to mention.

And honestly, Cubase audio SynC didn't matched their competence until Cubase 4, after erasing those SX of Cubase SX3.
And Jbridge has done a lot for those old VST2 32bit plug-ins like ReFX Claw or The Bassline, as an example of plug-ins that went crazy on SynC in fast notes sections.

[jamcat]

Those aren't merely problems that happen in Cubase.
They are universal deficiencies in the VST2 protocol.

[wikter]

They are universal deficiencies in the VST2 protocol that Cubase amplificated.

FROM A USER PERSPECTIVE:
Fixed number of input/output channels
- most multichannel plugins allows for changes with a simple plug-in reload. Easier than hardware disassembling, drilling, soldering... Easy to fix.

Parameters identified only by numeric indices
- Oh... That makes V1.x hard to upgrade, and developers should keep automatable parameters from One versión to another. Of course, not the BEST choice from Steinberg, but nice for users, again, fixed specs doesn't hurt users.

Only basic MIDI 1.0 messages rather than abstracted events
- VST3 lost MIDI compatibility, WTH??? Most vst3 can't handle a basic Program Change, It relies on DAW (Cubase was good at this)

Loose/inaccurate timing of MIDI/automation events due to being coupled with the audio buffer
- Incorrect, U-he & baconpaul explained It. As a USER i've automated more than 100 parameters in Logic 5.5 & Studio One projects and NEVER noticed a real synchronization problem, just a small buffer increase up to 192 samples and everything is fine.

Audio processing and GUI handling were intertwined
- Probably Steinberg API worked like this, like that obtuse idea telling "VST2 IS not resizable" (Synth 1 is realizable since 2003, Steinberg plug-ins never catched those japanese skills)

Lack of API standards for side-chaining, surround sound output, plugin states, or presets
- sidechain requieres an audio input, no real need to tag It as sidechain, fashionvictimis.
- Surround outputs requieres multiple mono outputs and there are more Standards than fingers. That's more of a host job, again fashionvictims.
- Plug-in states needs started with P4 denormals, most developers found a way into this. DAW or Host have Cheap active solutions to make a plug-in rest while it's offline. But not Cubase.
- Preset managing using banks & patches is easier than those hidden folders in VST3. Choose a folder, be methodic and keep track of everything for centuries. I keep a structure of D:/#Patches/VST/"pluginname". For me, VST3 folders location solution is CRAP & a disadvantage.
The VST2 SDK did not adhere to C++ coding best practices
- That's what? Audio & MIDI notes work fine, not my job.

Summing up: VST3 preset managing, MIDI compatibility loss & file location needs a fix, VST4 is needed. As a methodic musician/producer I can't find a real advantage over VST2 and some annoyances that Steinberg NEVER fixed since 2008. Steinberg Cubase lacked some of the solutions that other DAWS implemented to fix & complete VST2. Of course, I ended using It around 2010 but at that time ALL of the VST2 "real problems" were fixed & handled by most of the DAWS available.
Steinberg lost it's punch when It was sold to Pinnacle... Yamaha just started to fix all the flaws.
The real problem of VST Standard is Steinberg.
Synthedit & Synthmaker gave wings to the VST2 users & pushed Code developers to a higher minimum quality & specs. Hopefully Clap be supported by Synthedit... So VST3 IS finally pushed to its 2008 real position, out.