Bye bye VST2

[chk071]

Give me something tangible like that in regard to VST 3 vs VST 2.

Industry standard support and maintenance is pretty much the core of any software's longevity and survival.

Are you for real? I see you just opened this account yesterday so God only knows who you were in a previously incarnation to come here with this mountain of manure. Boggles my mind how somebody can say absolutely NOTHING in 16 words.

Can somebody, ANYBODY, tell me how VST 3 is better than VST 2?

I'm still waiting for an answer that doesn't sound like an advertisement for some drug where they only tell you the side effects but don't tell you what the damn drug even does.

Sheesh.

This, again, reminds me a bit of the argumentation of 32-bit users. What would you tell them, when there's stuff which is hard to measure (like, properly written 64-bit software is faster, or, that you can adress more than 3.5 GB of RAM), but, everyone uses a 64-bit system, and devs can't be arsed to go on maintaining 32-bit, because the majority already uses 64-bit? What would you tell a Christ about his god? That he doesn't exist, because there is scientific proof that the earth wasn't built in 7 days?

Anyway, Robert Randolph listed a couple of things which VST3 has that VST2 doesn't have.

The VST2 SDK is not available anymore, so, any dev who will begin to code plugins today won't be able to use it, unless there's something i'm missing. Steinberg obviously wants developers to develop VST3 plugins, so, sooner or later, people have to move on.

[noiseboyuk]

What would you tell a Christ about his god?

Boom. Peak KVR.

[EvilDragon]

Yes, multiple MIDI ports is about the most important thing VST3 brings over VST2. Just about the most useful. The rest is all, eh, could live without it.

[chk071]

What would you tell a Christ about his god?

Boom. Peak KVR.

You gotta admit though that the hate on VST3 becomes a bit of a religious topic, when it comes form people who don't actually develop VST3's, thus only can rely on hearsay.

"I don't know anything specific, but i heard that…"

I don't know much about it either, but, at least i don't strictly decline VST3. Actually, i more and more use VST3, when the plugin installs a VST3 on my system. I don't see much of a difference. Some VST3's are quite buggy (Novation V-Station *cough cough*), while others seem perfectly stable, and without obvious issues.

Let's also not forget that this industry is 1. notoriously slow to adopt new technologies, and 2. flooded with one-man, or small businesses who will always moan when they have to adapt and learn new stuff.

[aciddose]

I really prefer not to post in such an idiotic thread generally since it'll probably make page 9000 and go on for years in a blathering shit-flinging contest.

That said, I can't help but toss in my own shovel-full to add to the pile.

1) 64-bit is actually not 64-bit:

Originally Intel developed the Itanium IA-64 platform which was far, far superior to x86. It had a register stack rather than using pre-defined named registers and rather than having 8 or 16 it had 64 IIRC, among numerous other significant "advantages", technically speaking.

The problem was everyone would need to re-engineer their software "from scratch" during a period of time in which hard-coded x86 assembly was still common place to take advantage of sse/mmx and other platform-specific features. It wouldn't be possible to run even one x86 32-bit program on Itanium without an emulation layer (a virtual machine) running in software. Nobody wanted to do this because software developers were so heavily invested in x86 with 90%+ of the market running x86 hardware.

The Itanium managed to penetrate into the server market, very slowly, but only due to its false price advantage which disappeared when Intel started selling the processors at their true manufacturing cost rather than under-cutting themselves to earn market share. The engineers had expected the replacement of x86 to be swift with most new PCs containing Itanium processors... unfortunately this never materialized and I'm not aware of ANY mass-market PC containing an Itanium, ever!

Years later, along came AMD with the AMD-64 platform... this was basically x86 with 64-bit wide registers (the same ones!) and a few extra SSE registers/instructions along with new 64-bit instructions, but full backward compatibility between the instruction sets because they were the same thing.

The AMD-64 came with a built-in emulation capability and was fully capable with only "minor" (not really, but comparatively) support from the OS and software layers of running x86 32-bit code directly and at full speed.

The technical details are a little bit complicated... but basically VST3 (Itanium) died and VST2.x (AMD-64) won after it was upgraded to VST2.5, VST2.6 and so on rather than stupidly forcing everyone to drop a full capable and working system and replace it with something nobody actually wanted.


Regarding "features only VST3 supports": technically speaking you're totally incorrect. Only Stainberg has the ability to patch VST because they're total authoritarians about it and do not accept outside advice or influence. Therefore although there are countless very simple improvements and features that VST2 technically does support: you have to drive a Trabant!



Millions of garbage Trabants available, or you can try the all new shitfest VSTrabant3, but if you want a pair of socks you're out of luck buddy!



I also want to make this comment:

If you engineer a solution for idiots to use, only an idiot will want to use it.

[chk071]

Regarding "features only VST3 supports": technically speaking you're totally incorrect. Only Stainberg has the ability to patch VST because they're total authoritarians about it and do not accept outside advice or influence.

Isn't that the whole point of a proprietary format?

[Robert Randolph]

Many VST3s don't even have sample accurate automation implemented, though (at least AFAIK)... And audio in for VSTis was possible with VST2 (but obviously not supported in Cubase because Steinberg).

Better parameter and preset management - only if host implements it?

Yep, totally true.

However VST3 allows this 'officially' and makes it easier to implement it as a target for multiple compliant hosts.

We're still a ways away from every DAW supporting all of the things that VST3 can offer, but it does offer some benefits should plugin and host authors choose to support it.

[aciddose]

Regarding "features only VST3 supports": technically speaking you're totally incorrect. Only Stainberg has the ability to patch VST because they're total authoritarians about it and do not accept outside advice or influence.

Isn't that the whole point of a proprietary format?

Yes of course. We shouldn't be using such a format, but unfortunately that's simply the way things worked out. Sometimes the course nature takes seems very nonintuitive or incorrect, but it is always the course of nature and inherently "correct".

Moving forward I would expect something like the GPL Vestige headers (GPL-compatible VST2) to be improved further and perhaps made LGPL (for wrappers) or BSD (for full closed-source code). In addition we should eventually see the interface fixed and adopted by a consortium and engineered via a collaborative effort.

There are certain issues like passing naive pointers (c-strings without a length value) but these issues all have very simple solutions if only someone would publish the solution and say "hey, if you make a host: we've all agreed to do it this way, so moving forward please add this single line of code to make your hosts and plug-ins compatible!

The list of things like that is endless but the owners of the standard have sat on the ass doing almost nothing for a decade!

[farlukar]

Moving forward I would expect something like the GPL Vestige headers (GPL-compatible VST2) to be improved further and perhaps made LGPL (for wrappers) or BSD (for full closed-source code).

Would an ISC license do?

[aciddose]

I'm sure any BSD-alike license would be accepted fully and immediately. The only "more free" license is something like WTFPL.

Each release could be signed with a signature key to maintain "control" of the "officially published standard", but obviously anyone would be free to make their own edits and adjustments. A license could be applied to a sub-key used to sign software/plug-ins as "officially VST2.x compatible" with terms requiring that only the official unmodified headers/interface may be signed. This would only require voluntary "honor system" enforcement since anyone noticing "hey, V9.6 of wackysyn9000 isn't actually compatible with VST2.x": the author would say "opps, you're right, sorry here is a version without the signature!"

Hosts could then say "we will try to load this plug-in but it isn't signed as compatible: the plug-in reports it is interface version: xxx-xxxxx" or similar.

That isn't even really needed though. The only reason you'd fear incompatible plug-ins is if you thought it would damage your trademark/brand, which is the whole problem with "VST". They attempted to make it Cubase's brand rather than "Cubase". For a while "VST" was recognized that way but today we simply call them "plug-ins". Ideally any plug-in should not be marketed using format-specific trademarks like "VST" or "AU" today, they should simply be offered in every format the author is capable of delivering in.

[Ichad.c]

VST3 is not anything like "the future", it's mostly a failed attempt to be clever - How can they even create a plugin API that can't output proper Midi?

That is probably the worst part of it. Technically speaking Midi doesn't really exist in VST3, the DAW strips the Midi data down to the most basic, converts it, and then sends an "Event" to the plugin. Think the only way they might be able to save face is with the upcoming MIDI-CI standard(under development) which is also fully backwards compatible with the Midi V1.0 spec. If that is fully implemented and by fully I mean plug-in side and not just DAW-side, it would basically be a cure-all.

A bit technical - but there is pictures
https://www.midi.org/articles-old/midi- ... cification

VST3 allows

• sample accurate automation.

Can be done in VST2. Depends on plugin creator.

[*]better parameter management.

Yip, definitely better in VST3, as parameters can be grouped. Useful if a plug has a ton of parameters.

[*]better preset management.

Uhh, nope. But VST2 isn't great either - that is why most developers have their own preset-management system, that is not tied to a plug-in standard.

[*]audio in for VSTis..

Supported by VST2 - probably just not Cubase.

[*]dynamic processing (not using CPU when there's no signal).

Can be done in VST2. Depends on plugin creator. Has been standard in SynthEdit for oh, a decade or so.

The VST2 SDK is not available anymore, so, any dev who will begin to code plugins today won't be able to use it, unless there's something i'm missing.

Yip, that is actually what that official Steinberg statement says (minus the marketing blabber). No problem really for existing Devs and DAWs - it's business as usual.

As for the instability of VST3 plugs I believe this will sort itself out in the long run, because of the historic low adoption rate of VST3, less bugs were being identified, so VST3 has basically been in low-participant beta-testing for the past couple of years; more plugs -> more bugs -> more bugfixes -> more stability. Also remember that it is a two-way street, bugs need to be sorted plug-in and DAW side.

Regards
Andrew

[THE INTRANCER]

The product developers and the user market dictates what the most viable standards remain in place. We might have Blueray disks, but DVD is still the mass profitable market format. The same principal applies to VST2, and personally I completely avoid using any VST3 plugins.

Sorry Steinberg, you might have created the format, but you don't control it.

[Funkybot's Evil Twin]

Did they ever get MIDI Learn working in VST3 or are the hosts still expected to allow for controlling plugins? That's my understanding as to why MIDI Learn doesn't work in VST3 with U-he synths for example.

Maybe Stienberg considers that a "benefit" of VST3. Which is odd, considering how much Remote Controlling plugins sucks in Cubase compared to say Studio One where I don't need special hardware to control more than 8 parameters.

[Robert Randolph]

VST3 is not anything like "the future", it's mostly a failed attempt to be clever - How can they even create a plugin API that can't output proper Midi?

That is probably the worst part of it. Technically speaking Midi doesn't really exist in VST3, the DAW strips the Midi data down to the most basic, converts it, and then sends an "Event" to the plugin. Think the only way they might be able to save face is with the upcoming MIDI-CI standard(under development) which is also fully backwards compatible with the Midi V1.0 spec. If that is fully implemented and by fully I mean plug-in side and not just DAW-side, it would basically be a cure-all.

A bit technical - but there is pictures
https://www.midi.org/articles-old/midi- ... cification

VST3 allows

• sample accurate automation.

Can be done in VST2. Depends on plugin creator.

[*]better parameter management.

Yip, definitely better in VST3, as parameters can be grouped. Useful if a plug has a ton of parameters.

[*]better preset management.

Uhh, nope. But VST2 isn't great either - that is why most developers have their own preset-management system, that is not tied to a plug-in standard.

[*]audio in for VSTis..

Supported by VST2 - probably just not Cubase.

[*]dynamic processing (not using CPU when there's no signal).

Can be done in VST2. Depends on plugin creator. Has been standard in SynthEdit for oh, a decade or so.

The VST2 SDK is not available anymore, so, any dev who will begin to code plugins today won't be able to use it, unless there's something i'm missing.

Yip, that is actually what that official Steinberg statement says (minus the marketing blabber). No problem really for existing Devs and DAWs - it's business as usual.

As for the instability of VST3 plugs I believe this will sort itself out in the long run, because of the historic low adoption rate of VST3, less bugs were being identified, so VST3 has basically been in low-participant beta-testing for the past couple of years; more plugs -> more bugs -> more bugfixes -> more stability. Also remember that it is a two-way street, bugs need to be sorted plug-in and DAW side.

Regards
Andrew

Of course many of these things are possible in VST2, but they are not standardized, and it ends up with everyone doing things differently and causing headaches for most everyone involved.

Now with VST3... you have a new breed of headaches instead.

[Oopi]

VST3 is like that Windows version nobody liked. I mean it has been around like ten years and people still complain so there has to be something terribly wrong with that. It's just not hip or cool or rad like VST2 is. Steinberg should just terminate VST3 right now and release VST4 which would really be VST2 in new disguise.