Is VST3 worth it?

[DarkStar]

OK, so VST3 is a new improved (and still improving?) plug-in specification.

For VST3 to be of any benefit to users:
(a) the DAW host must support its functionality,
(b) the plug-ins must make use of that functionality.

So my questions are:
Q1: what aspects of the VST3 new / changed functionality does Reaper support?
Q2: what aspects of the VST3 new / changed functionality does the (<insert name here> plug-in implement?

After all, a developer could take a VST2 plug-in, build it into the VST3 format, without adding any support for the new /changed functions, but it would still be a VST3 plug-in.

Or, have I missed the point?

I'll get the pop-corn and pitchforks!

[Coachz]

https://www.steinberg.net/en/company...gies/vst3.html

[ivansc]

All well & good IF the devs of third party plugs actually follow Stenbergs system fully and implement it all correctly.

I am slowly un-convincing myself that its worth bothering till things improve significantly.
Not seeing any real advantages here so far.

[Xenakios]

All plugin developers who started their work after October 2018 or didn't apply for their official VST2 development license from Steinberg before that, can only release VST3 plugins now. So eventually as new developers appear on the scene, you will only be able to use VST3 plugins from them anyway.

If you have VST2 plugins that at the moment work OK for you, there wouldn't appear to be any reason to switch to the VST3 versions, if they are available. (Unless it happens to be that some VST3 specific feature has been implemented both by the plugin and the host application.)

[ejanejarr]

By the way, is there any reason some plugins seem to use pretty more CPU in VST3?

My ToneBooster's Equalizer 4 has to be used in VST3 for sidechaining, yet even comparing with a non sidechaining preset, it uses more CPU than the VST2 version.

I played a little some time ago with a Softube Console 1 and it was eating roughly double the CPU in VST3 (which would suck since VST3 seems to be the only way to have it fully integrated in Reaper).

It seems as if few plugin developers keep an eye on CPU efficiency. For me, if I have to build a new computer to use new plugins, well you do the math. And the you'll read people reviewing 16Gb RAM i5's laptops and saying "It should be fine for Office and Youtube".

[PitchSlap]

Originally Posted by Xenakios

All plugin developers who started their work after October 2018 or didn't apply for their official VST2 development license from Steinberg before that, can only release VST3 plugins now. So eventually as new developers appear on the scene, you will only be able to use VST3 plugins from them anyway.

If you have VST2 plugins that at the moment work OK for you, there wouldn't appear to be any reason to switch to the VST3 versions, if they are available. (Unless it happens to be that some VST3 specific feature has been implemented both by the plugin and the host application.)

Thanks, saves me from starting a new thread.

About to start the arduous task of reinstalling all my plugins on a new computer and didn't know the current state of the VST2 vs VST3 debate.

All these years I've only installed VST2 unless the plugin was VST3 only and haven't had issues so will probably stick with it, though I might pay more attention to plugins/instruments really taking advantage of VST3 features (i.e. audio inputs).

[Joe90]

My understanding is that VST3 has two potential advantages over VST2 -

- Sample accurate automation. VST2 plugin automation is rounded to the nearest buffer size, at a large buffer size this can be an issue for time sensitive automation. I believe this is the same for sidechaining too. VST3 is capable of sample accurate automation, irrelevant of buffer size (I believe).

- Lower CPU use when no sound is being processed. VST3 has a feature that allows the plugin to stop drawing from the CPU if it's not actually doing anything. VST2 does not have this I believe.

HOWEVER - these advantages aren't automatically built in to the VST3 architecture, each specific developer has to decide how they will implement it in their VST3 plugin, or if they are going to bother at all.

[mschnell]

Re sample accurate Automation:
As a plugin (like the complete audio processing) is done for full audio blocks, that would mean that in the API all automation parameter changes (as it's done with midi events) are attributed with "count of samples into the block) Is this the case in this way ?

Re CPU when not processing:
By default Reaper switches off the processing for VST2s when a track is muted. Is this more versatile with VST3 ?

-Michael

[Xenakios]

Originally Posted by mschnell

Re sample accurate Automation:
As a plugin (like the complete audio processing) is done for full audio blocks, that would mean that in the API all automation parameter changes (as it's done with midi events) are attributed with "count of samples into the block) Is this the case in this way ?

Re CPU when not processing:
By default Reaper switches off the processing for VST2s when a track is muted. Is this more versatile with VST3 ?

The sample accurate automation works more or less like that in VST3. The plugins themselves are still responsible for doing any needed interpolation/smoothing internally and could of course omit doing that, if the developer didn't want to go to the trouble.

VST3 adds some API level support to dynamically turn the processing on/off. But that has never strictly been needed, the hosts could have done that themselves with VST2 plugins too. It is not an entirely trivial problem though, since there are issues like how long the plugins keep outputting valid audio after the host is no longer inputting audio or MIDI into the plugins. IMHO it's a thing better implemented inside the plugins themselves and can be done with VST2 already.