Is VST 3 REALLY important

[Nigel Mackay]

Not sure where else to ask.

I have seen comments that side-chaining can be a  problem/difficult with VST2. I have also seen comments that VST2.4   means that VST2 is just as good as VSR3.

Should I even think about it?

 

[Michael A.D.]

Not sure about the side-chaining issue, but (and I might be wrong) I like that VST3 usually have scaling capabilities that VST2's lack.  So, with a VST3 I can enlarge it to a size/view I like.

[reginaldStjohn]

Just my opinion: If a plugin has a vst3 version I install that and not the VST2 versions. It is the current standard for VSTs so as long a a particular plugin works in vst3 mode I use it.  However, Some DAWs still don't support vst3 or a particular plugin may not have a vst3 version so in those cases I use the vst2 version.

Edited February 6, 2020 by reginaldStjohn

[marcL]

If there is a Vst3 version, then I use that one most of the time.

But there are some plugins that were developed to use the standard Vst2 preset handling (you can open a list box in most DAWs to select one) and this makes it very cumbersome in CbB to select presets in their Vst3 version (e.g. some plugins of Plugin Alliance). In such cases I prefer the Vst2 version over Vst3.

[scook]

Depends on the plug-in. DX, VST2 and VST3 can all implement a sidechain feature but is it  up to the manufacturer. So to with plug-in bypass. The advantage VST3 has over other formats is these features are part of the spec so rely less on the skill of the developers.

Some manufacturers notably Waves only support sidechain in VST3 for CbB.

Steinberg has deprecated VST2 so it really has no future.

 

[Starship Krupa]

As I understand it through reading various fora and my experience with plug-ins, the VST3 spec added a few features that were already being implemented by many, if not most, plug-in manufacturers within the VST 2.4 spec. These were most notably sidechaining and UI scaling.

Sidechaining is not inherently "difficult" with VST2.4 or DX plug-ins. The ones that implement it have a button or checkbox in the UI to turn it on, and the hosts interface with it in their own ways, just as with VST3.

Similarly, there were/are plenty of VST2 plug-ins that implemented UI scaling before VST3 was published. All VST3 does is define how everyone should implement it if they choose to do so.

Another thing to be aware of: as with most industry specs, just because sidechaining and UI scaling are defined in the VST3 spec, plug-in manufacturers are not obligated to do it. Nor are hosts. AFAIK, there is no organization that enforces compliance with the specification. Anyone can publish a plug-in and say "it's a VST3."

In my experience, the only advantage that the VST3 spec brought was defining the install location as C:\Program Files\Common Files\VST3\

One big disadvantage is that as @marled mentioned, preset handling changed somehow. It used to be that when I installed a VST2, it could install presets to the host natively, but that seems to have been abandoned with VST3 in favor of each plug-in having its own poorly-implemented preset manager.

Both plug-in and DAW manufacturers seem to be having a rocky time making the transition from VST2 to VST3. I've had several instances of crashy/buggy plug-in syndrome in different DAW's where the cure was to switch to the VST2 version. Cakewalk itself has had past issues with state-saving (now happily fixed) due to certain plug-in manufacturers being sloppy with their VST3 implementation.

Unfortunately as scook says, Steinberg has deprecated the VST2 spec in favor of the VST3 spec, so going forward, we'll have the format that doesn't yet seem to work as well. I don't see any hosts except for maybe Cubase and Nuendo dropping VST2 support. It'll be a drag for Cubase users because they'll be stuck with libraries of legacy VST2's that they can't use.

My current policy is to install the VST3 version if the plug-in has it, switch to the VST2 if it crashes my host(s).

Edited February 7, 2020 by Starship Krupa

[Nigel Mackay]

Thanks, everyone. Some interesting info there,

[Hidden Symmetry]

The main reason I started using VST3;

"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."

Edited February 7, 2020 by Hidden Symmetry

[marcL]

14 hours ago, Starship Krupa said:

In my experience, the only advantage that the VST3 spec brought was defining the install location as C:\Program Files\Common Files\VST3\

IMHO this is not really an advantage, because only the major location is specified. Whether a plugin provider defines a company subfolder or even an additional plugin subfolder is totally free. So in the end you get a real mess in the VST3 folder. If you want to improve this (I do, have them grouped by type), then you have to do a lot of stuff manually and for each version again, because only a few plugin provider support location configuration for VST3 as all of them do for VST2! Just a big step forward to the past!

[Starship Krupa]

On 2/7/2020 at 4:48 AM, Hidden Symmetry said:

Instead of always processing input signals, VST3 plug-ins can apply their processing economically and only when it is needed.

Oh, the hopes I had for that part of the spec. Unlike the rest of it, which is redundant rubbish, this is something that I could get behind. That's really using your heads, thinks I. Instead of sitting there churning away, all these programs-within-a-program can intelligently go into a sleep state so that the processor-intensive cabinet simulation convolver you're using on nothing but the 4-bar guitar solo can just pop in and do its thing and then politely release its resources.

Ah, but a couple of things about this spec that even I, as a cynical, informed veteran of the consumer software industry, didn't pick up on immediately.

First, I'm going to hazard a guess that there's some kind of signaling protocol that comes from the host that tells compliant VST3's that they are allowed to go sleepy. Only if this=TRUE may VST3 go sleepy. Otherwise we play it safe and stay "on." This would be for processing FX that have long "tails" and perhaps for troubleshooting and such. So right off the bat the host has to be able to give it the okay to sleep. Maybe some hosts will decide that it's not worth the effort and just leave the condition=FALSE so that VST3's never go offline.

Second, and this is most important, notice how the pitch says "can" rather than "will" or "must." That means that it's only a feature that the plug-in may implement or not at the choices of the developer. For now, most developers are still coding their VST plug-ins in both VST2 and VST3 formats. With the exception of Waves, have any of them touted any features that are exclusive the VST3 version of their product that are or were not available in the VST2 version? That would be a good way to find out.

I am pretty sure that as much as possible they are keeping a common codebase for both the VST2 and VST3 versions, and/or in some cases, using their own portable VST2-to-VST3 wrappers. All of which seems to preclude using the "processing economy" feature.

If I am remembering correctly, someone asked Vojtech on the Meldaproduction forum if he were using the feature or had any plans to in the immediate future and he replied that he had experimented with it and decided not to for whatever reason. He seemed a little dismissive, but dismissiveness toward other people's technology is kind of his default mode.

From what I've seen on DAW forums in general, I've yet to find anyome who noticed a difference in resource usage doing side=by-side tests of the same plug in VST2 and VST3 versions.

Still. I use VST3's wherever possible, because that's the way the industry is headed and if there are problems, I want the people I get my pluggies and hosts from to know about them.

[marcL]

I am pretty sure that in the end the creation of the VST3 standard produced more damage than benefit for the DAW users:

• A lot of development manpower has been exhausted to create and handle errors of Vst3 versions that could have been invested in improvements and in new plugins.
• A lot of development manpower has been wasted to adjust the DAWs for Vst3 and fix upcoming errors.
• Many users have a lot of trouble handling the double standards along with 32-bit plugins (some). The installations and configurations in the DAWs are actually more complicate than before Vst3!
• Plugin errors are sometimes not transparent, because it has to be checked which version(s) have been used. This is especially delicate if a Vst2 version of a plugin has been replaced by its Vst3 version in the same project or if both versions are used in the project. We all know far too well that the Vst2/3 versions behave not always the same!
• and so on ...