VST3: New Standard for Virtual Studio Technology
https://www.steinberg.net/en/company/technologies/vst3.html

 

?

 

old news

 

lol
32 bit is no longer the standard either, I head it's 64 bit nowadays.

 

Move this to humor?

 

Hey! While the VST3 standard may not be a new concept, perhaps some users who are knowledgeable about the differences between the audio plugin formats (both pros and cons) could help others (like me ;p) understand the differences?

For example, I have noticed that when using the VST3 versions of FabFilter plugins within FL Studio, that the user can right-click and directly 'create automation clip,' whereas (due to perhaps FL Studio) when using the VST2.4 versions thereof, the user must use other DAW-based methods (i.e. no direct automation from the plugin wrapper itself).

Is this a pro/con from using VST3/VST2.x, or is there some other explanation that you guys might know of - as to the extended functionality of the VST3 wrapper in that DAW?

A few other bits, from the OP's link...

• 64-bit processing - VST3 plug-ins are generally able to process audio data in 64-bit.

What does this mean exactly to the end user. Is there any tangible benefit in doing so?

• No MIDI restriction for parameter value transfers - VST3 has a dedicated interface for event handling that carries a much wider range of functionality than standard MIDI events would be able to provide. This opens up a big range of opportunities for musical use cases with very high potential for innovative product design. For example with VST3 some controller events (for example, pitch) can be referred to a note event (using a note unique ID). This offers the possibility to e.g. modulate only a single note which itself is part of a chord.

Does this mean that third party plugins, which have specifically been coded to take advantage of such VST3 feature set, could allow users to perform per-note pitch slides, etc. (similar to how FL Studio's 'Slide notes' work in it's piano roll for Image-Line's internal/stock generator plugins?)

• Sample-accurate automation - VST3 also features vastly improved parameter automation with sample accuracy and support for ‘ramped’ automation data, allowing completely accurate and rapid parameter automation changes.

What does this look like in practice? is the fidelity/resolution of automation data increased, or merely more reliably communicated between plugin / hardware / DAW, etc?

• Improved performance - Managing large plug-in sets and multiple virtual instruments on typical studio computer systems can often be difficult because of CPU performance limits. VST3 helps to improve overall performance by applying processing to plug-ins only when audio signals are present on their respective inputs. Instead of always processing input signals, VST3 plug-ins can apply their processing economically and only when it is needed.

Is this feature essentially like a built-in 'Smart disable' (as it is termed in FL Studio), only built into the plugin itself, without any prompting from the DAW?


Finally, it would be interesting to hear how many users tend to prefer one over the other VST2.x versus VST3 when choosing to install your own plugins.

Personally, I tend to only install the 64-bit VST3 versions of plugins, since I believe that will perhaps offer the best compatibility/longevity going forwards, as I have noticed many developers already dropping the 32-bit versions thereof.

Will perhaps the older VST format also be dropped any time in the foreseeable future?

I am also assuming that perhaps most of the main benefits of the VST3 format may not be focused upon and therefore taken full advantage of by developers, until they drop development of the older VST format and develop only for the newer one?

Any feedback you experienced guys could offer (even if you think it's obvious to you), would be appreciated.

 

VST3 is way superior to VST2, I wish they'd made a stronger case for it and deprecated 2 way earlier. Maybe this way we'd have companies like Native Instruments support it already (NI has just one VST3 plugin out, Super8).

The SDK/API is of course more complex but it brings a lot of benefits (CMake support, yay!) , like ones listed in the post above.

So for me, VST3 all the way.

 

hell it's in c++ .. hard to cmake one..

 

I will say that VST3 is an old standard now. We waiting for VST4 right now

Nice Flower

 

There is an excellent and very long thread about VST3 at KVR that I read long time ago [since VST3 appeared], discussed by the actual developers. The consensus is - they hate it and that's why many developers never jumped ship. VST2.4 plugins are generally [still] more stable than VST3 ones, but new developers who can't get their hands on VST2.4 developer kit don't know any better and make VST3 plugins. Also, all these things Steinberg claims as new had been implemented already by many developers in VST 2.4. long time ago. The quality of VST2.4 plugin depends more on your programming skills regarding these features, however programming in VST3 is more complicated. That's the gist of that thread.

I'm still using VST2.4 plugins when available because they are more stable. When there's no choice, you have to use VST3 plugin with hope the developer programmed it well. It also depends on your DAW, if the VST3 support is well implemented. It took some time for Reaper to implement it well.

Steinberg had to push VST3 because their programmers were unable [?] to implement sidechain and some other VST3 features into their Cubase plugins, but there are many VSt2.4 plugins for Cubase that support sidechain anyway. Cubase lacks the flexibility of routing like Reaper has for example.

So choose wisely.

Cheers!

 

When VST3 came out it was a shitshow for sure, but IMO that resistance still lingers needlessly. The developer experience with the SDK has improved by miles and I personally prefer it to using VST2 now though it's more complex but you get a lot of things for it, multiplatform from the get go for instance. Also the whole licensing thing has been streamlined.

Of course, a lot of people use JUCE, iPlug2 or ASPiK or somesuch, but for me (again, personal opinion) VST3 offers the fastest way to get off the ground.

 

https://www.kvraudio.com/forum/viewtopic.php?f=33&t=561545

There seems to be alot of well known devs in this thread that dont seem to have a good thing to say about vst3.

 

Indeed, VST3 has been out "for a while" now so I have to agree with what you said @phumb-reh . It is more a matter of preference these days, but one should check which version of a plugin works better for them. It complicates things unnecessarily. :/ Some developers simply make better VST2 plugins than VST3 and these days there might even be those that make better VST3 plugins than VST2.

 

If VST3 would've got more love from Steinberg and had they consulted with audio devs at that time for feedback, today we won't have been using VST2 for sure. @Xupito would agree

@TryHard most of the things mentioned their is marketing, devs achieved most of those things with VST2, sometimes in hacky ways. And yes the right-click menu (context menu) has support in VST3, i.e. the plugin lets the DAW know that a right click has occurred and its time to show the context menu, idk about VST2. Infact, if the DAW implements it, the plugin can insert its own actions in the context menu.

 

Blue Cats informative article about VST3 Hosting, this solution works perfectly for me.
https://www.bluecataudio.com/Blog/new-releases/vst3-hosting-released/

 

Cubase 4 will have native support for VST3: http://www.steinberg.net/en/products/musicproduction/cubase4_product.html.

 

VST2 is also "able to do that", so nothing new at all here. the little difference in implementation is nothing the user should care for.

what is new is that it can receive and output 64 bit streams without the programmer has to care about the stream format.

marketing language. doesnt correctly explain the real thing. typically steinberg.

if it makes a difference for you to to able to have 44 different values per millisecond or only one, no idea.

but just like the other two points, it is mostly about how things are going to be implemented.

with VST2 you could also do all these things - but you had to write them on your own and it would only in your own host program.

kind of. if it really means anyting in regards of the CPU usage peak in every possible situation is another question. but it will save CPU cycles in terms of energy. ;)

 

Ah! Thanks for posting that link, it's a very interesting read from those developers. From a consumer's point of view (one with no personal bias or allegience to either VST format,) I'm kind of selfishly glad Steinberg seem to be forcing devs to go the VST3 only route for new plugins.

I just find all the audio wrapper versions too much, and want a unified solution. I mean, it's just a goddamned wrapper anyway, I don't really care what they call it, I just want to be able to install one version of each of my plugins, preferably to one single folder location, and to have them all work for the foreseeable future (would that be such an outlandish request?)

I have little sympathy for plugin developers whining about being forced to upgrade to VST3 after the majority of those same developers appear to have been dragging their heels on VST3 adoption for years now, while many of those same devs have already or would willingly drop all support for 32-bit versions of said plugins. The latter of which has inconvenienced many a user, also. So, a taste of their own medicine, may be bittersweet justice, regarding VST3.

So, I already resigned myself to the fact that 32-bit was effectively a dead man walking, so VST2 might as well be also.
As for all of those other audio plugin formats, like AU, AAX, RTAS, etc. I mean, what's even the point. It's 2021, shouldn't there just be a single, unified, free and opensource format for every developer to use by now?

It just seems rather pointless to prolong all these competing variants when they effectively do pretty much the same basic thing. Just Have all the devs come together, pick the best currently available, then come to a consensus on the best features to include for a unified free standard, going forward, and get coding (how difficult could it really be, all things considered?) Hopefully, if those devs are really annoyed by this and dissatisfied by VST3, that this may prompt them to do something about it, that could benefit everyone, devs and users alike.

 

VST2 and VST3 (when it started) feels to me like Windows XP and Windows Vista. Now several years later, make it perhaps Windows Vista Service Pack 2.
I feel like the next good one will be VST4, like Windows 7.

 

Funny thing is, Vista was actually rock solid once they sorted out the WDDM/new driver model bollocks.

I ran it for years with E-mu 1212m using Ableton with no problems.

But I get your point, what they should do is to listen to some big name devs, make some amends and rebrand it as VST4 (the Windows 7).

There is still a problem, however (maybe it's just me though), that not all plugin APIs are created equal, and to release a commercial plugin you need to support VST2/VST3/AAX/AU pretty much, so a lot is boiled down to a middleware framework (JUCE/ASPiK/iPlug 2 and so on). That means that if a fancy feature Z is available in X but not Y then you don't use feature Z.

If you want to overcome this you'll end up with a shitload of workarounds for each backend which is not, to say it kindly, optimal.

We'll see. I'll stick to VST3 for now for my audiocode fidgetings, at least it gets most of the platforms with minimal flak.