VST2 vs VST3 Performance Realization

[Keni]

OK... Blindsided me...

I thought about it on occasion but somehow let it pass...

It seems there's a huge difference in resource demands of VST3 and VST2 plugins.

For a long time I've been having a lot of trouble with a number of plugins resource hunger and others tell me they aren't seeing that...

I don't know if this is the reason, but I just realized that when I upgraded to this win10 (from win8.1) system I decided to start using vst3 versions of everything when available. Not for need, only to be more current...

Now I'm discovering many, if not all vst2 versions operate much more efficiently... MUCH more.

Previously work running Cherry Audio's VST3 Memorymode I was forced to 512 or 1024 latency for even simple operation all by itself.

Just now I loaded the vst2 version into a song with Session Drummer 3 (active) and 4 frozen tracks (still live feeding some bus fx etc.) and I can cleanly play most of it's presets at 128!

 

The light is finally on in my brain again?

 

 

Addendum...

Just found that monophonics play fine at 128 in above scenario, but polyphonic reqiores changing that to 256.

Not fabulous, but way better than the vst3 version!

 

Edited November 20, 2023 by Keni

[Glenn Stanton]

sounds consistent with my experience as well. however, in W11, i'm using almost VST3 exclusively and maybe it's the CPU etc but even with stuff that didn't run reliably on W10 on an older machine, the usage meters barely move with either VST2 or 3... that said some products (i've found the Cherry Audio VST3 to consume more resources, not an issue on the new machine, and the Waves Abbey Road Chambers, unusable on W10 & older laptop, now, virtually no resources appear to be consumed on W11 and new machine). so most times, my latency is done to 64-128 samples for recording, sometimes 256, and some old 32-bit ones need 512. mix is still always 2048...

[Keni]

3 minutes ago, Glenn Stanton said:

sounds consistent with my experience as well. however, in W11, i'm using almost VST3 exclusively and maybe it's the CPU etc but even with stuff that didn't run reliably on W10 on an older machine, the usage meters barely move with either VST2 or 3... that said some products (i've found the Cherry Audio VST3 to consume more resources, not an issue on the new machine, and the Waves Abbey Road Chambers, unusable on W10 & older laptop, now, virtually no resources appear to be consumed on W11 and new machine). so most times, my latency is done to 64-128 samples for recording, sometimes 256, and some old 32-bit ones need 512. mix is still always 2048...

Interesting...

My usage meters hardly light yet I get problems relieved only by increasing the latency. I'm running 12 cores with multi-threading which Cake shows as 24 cores. Mine barely show any height.  A nudge up from none. So it's not my processor having the difficulty. I'm believing it's the audio interface itself. Mine is somewhat old, but claims a latency of 5ms peak. I can run very little at 64 but run normally at 128 for most things. Some of the new Synths coming out are proving to be very vst3 resource hungry so that's changing things. I'm very happy with running the vst2 versions instead where available. I have no known need of the vst3 features such as side-chaining very often if ever...

 

I freeze all my tracks prior to mixing so I mix most of my stuff at 128 as well. Only some of these new issues spoken of have begun upsetting that but now knowing to default to vst2 when possible, I should do better... I hope. This latency dancing is just too much constant fidgeting!

 

[John Vere]

Interesting observations. This might be distantly related to why I am struggling to get my new system running smoothly.  
Its W11. 
Mostly everything went OK but as always installing all my plug ins is slowly becoming a nightmare. 
At the heart of the issue is Cakewalk simply crashes if I try and open any project with a missing plug in. 
So I’m forced to use safe mode and sort it out. 
Then the mysteries start as most of the errant plugs are actually already installed?  
Turns out they need to be in the exact same pathways are old system or Cakewalk crashes. 
I thought I sorted 90% of this out. 
But now after reading this topic you have given me another reason it might happen.  
My last system I almost always installed both VST 2 and the VST3 versions. This time thinking why bother with the VST 2 and I focused on only installing the VST3 versions. Idiot . 
I now see why Cakewalk is crashing when it seems it shouldn’t.

I guess I’ll go back and re install the VST 2 versions and see. I personally have never seen the difference in the way a plug in works. 
 

You gotta realize the company responsible is Steinberg. A very Mac eccentric company. And they just like Mac love to force you to keep spending money if you want stuff to be completely compatible. 
 

I think I’ll stick with the VST2 versions for now too.  
 

Oh and I work at 256 buffer for last 15 years. I never change it.  Because I use my interfaces direct monitoring I never notice any latency when recording.  

Edited November 20, 2023 by John Vere

[Glenn Stanton]

1 hour ago, John Vere said:

My last system I almost always installed both VST 2 and the VST3 versions. This time thinking why bother with the VST 2 and I focused on only installing the VST3 versions. Idiot . 

this is why i only exclude the VST2 in CW when i have the VST3 (i can't remember who else said to do that? ?) but always install the all the 64-bit versions - even aax versions (in case i need them in PT) - then if the VST3 is merely a wrapper (without proper memory management that allows it to degrade nicely when it's corresponding VST2 is missing thus tearing holes in protected memory), at least the file is there even if CW has it on its exclude list...

Edited November 20, 2023 by Glenn Stanton

[Keni]

1 hour ago, John Vere said:

Interesting observations. This might be distantly related to why I am struggling to get my new system running smoothly.  
Its W11. 
Mostly everything went OK but as always installing all my plug ins is slowly becoming a nightmare. 
At the heart of the issue is Cakewalk simply crashes if I try and open any project with a missing plug in. 
So I’m forced to use safe mode and sort it out. 
Then the mysteries start as most of the errant plugs are actually already installed?  
Turns out they need to be in the exact same pathways are old system or Cakewalk crashes. 
I thought I sorted 90% of this out. 
But now after reading this topic you have given me another reason it might happen.  
My last system I almost always installed both VST 2 and the VST3 versions. This time thinking why bother with the VST 2 and I focused on only installing the VST3 versions. Idiot . 
I now see why Cakewalk is crashing when it seems it shouldn’t.

I guess I’ll go back and re install the VST 2 versions and see. I personally have never seen the difference in the way a plug in works. 
 

You gotta realize the company responsible is Steinberg. A very Mac eccentric company. And they just like Mac love to force you to keep spending money if you want stuff to be completely compatible. 
 

I think I’ll stick with the VST2 versions for now too.  
 

Oh and I work at 256 buffer for last 15 years. I never change it.  Because I use my interfaces direct monitoring I never notice any latency when recording.  

Yeah... I hear you!

I too use direct monitoring when recording via mics, but I now use virtual guitar/bass amps which lay in the demands and increases latency.

I've often wondered about what changes there are between vst2/vst3. The only feature I know of is side-chaining which is something I rarely do these days. I don’t remember the last time I did. So what else fhanged causing them to be so much more resource hungry?

 

I've switched back to all vst2 except the few items that now are vst3 only.

 

Edited November 20, 2023 by Keni

[HOOK]

I was under the impression that VST3 are supposed to be less cpu intensive because they don't DO anything until audio passes through them.

 

[John Vere]

Just now, HOOK said:

I was under the impression that VST3 are supposed to be less cpu intensive because they don't DO anything until audio passes through them.

 

This is supposed to be the way it is but one regular member here has said this is just marketing hype and is not true. Possibly it was @User 905133

[John Vere]

I've had to avoid using Guitar Sims in real time because my Motu M4 would stutter at any setting below 256 even on a fresh project. My new Zoom L8 can easily do 64 now. I've always used 256 but I think I could now safely go with 128 as a working setting because of the new computer. 

Running Cakewalk generally seems no different but I made a video yesterday to see and it was mind blowing editing and rendering. On old machine if I didn't save every 3rd edit Movie Maker ( Vegas)  Plat 17 would freeze. The preview was always real slow to refresh and you couldn't preview things like transitions.  And rendering ( export)  would be 10 plus minutes for a 3 minute video. Yesterday I worked for hours and only saved randomly no freezing, The preview was perfect,  and export of a 3 minute video took exactly 80 seconds, I timed it.  This is probably mostly because I now have a real Video card. I'm sure it will be a good thing to have with the new Graphics in Sonar. 

[Keni]

1 hour ago, John Vere said:

This is supposed to be the way it is but one regular member here has said this is just marketing hype and is not true. Possibly it was @User 905133

just an immediate thought is that no demand when audio not passing may save something, but that doesn't mean the plugin will perform better. Needing to constantly turn on/off may have it's own issues. All the calls needed to do this may actually increase the system demands. But I'm not a programmer. I don't know...

What I do know is that repeatedly if I replace my vst3 devices with vst2 equivalents, My system runs leaner/better...

[Patrick Wichrowski]

3 hours ago, John Vere said:

My last system I almost always installed both VST 2 and the VST3 versions. This time thinking why bother with the VST 2 and I focused on only installing the VST3 versions. Idiot . 
I now see why Cakewalk is crashing when it seems it shouldn’t.

 

I always install both VST2 and VST3 because of these inconsistencies.

[Starship Krupa]

I'm probably the deflator of VST3 hype that John is thinking of. To recap my usual points:

1. VST2 plug-ins that support sidechaining do so just fine on every DAW except Steinberg's. The "VST3=sidechaining" stuff is only true for Cubase and Nuendo.
2. PreSonus came up with a widely-used extension to the VST2 spec (so widely used that it was incorporated into the VST3 spec and hyped as being new) that allowed for plug-in UI resizing.
3. The "plug-in goes to sleep when no audio is being passed" is a nice idea in theory. In practice, it's not that big a deal because just like any processing, plug-ins usually only eat resources when they're actually processing something other than silence. Also, implementing that part of the VST3 spec is not mandatory. No part of the VST3 spec is mandatory; it's a spec, not a law. There is no authority enforcing compliance. Of my VAST plug-in collection (Cakewalk has it at almost 500 FX), there is only one manufacturer I have seen implement silence=sleep, and that manufacturer, MeldaProduction, also implemented the feature in the VST2 versions of its products. Think about it: how many projects have you ever done that would benefit much from turning off a couple of plug-ins when they were idling?
4. Due to slow uptake of VST3, most plug-in manufacturers still provide VST2 versions of their products. Since they are less likely to want to code two separate versions, that results in their VST3's being restricted to a VST2 feature set.
5. The one single big advantage of the VST3 spec that I perceive is that it has a canonical location for the DLL's. But even that isn't without issues, as anyone with a 256GB SSD for their C drive and a large plug-in collection can tell you. Yes, you can circumvent this with sym links, but relatively few people have the knowledge and skills to implement that.

Regarding Cherry Audio's products not working so well in VST3 form, this, unfortunately, is less of a surprise than it should be. Cherry Audio shares staff and management with Acoustica, makers of Mixcraft. When Mixcraft first started supporting VST3, the otherwise rock solid Mixcraft was so crashy and buggy with VST3's that I gave up on VST3's for over a year waiting for the next version of Mixcraft, which worked fine with VST3's. It appears that even now, they may not have cozied up to the VST3 spec?

It's been a long time since I've run into VST3/VST2 issues, but one notable exception is Acustica (not to be confused with the DAW manufacturer) Multiply, the excellent freeware chorus. From its initial release, the VST3 version of Multiply will not work in CbB.

[Keni]

1 hour ago, Starship Krupa said:

I'm probably the deflator of VST3 hype that John is thinking of. To recap my usual points:

1. VST2 plug-ins that support sidechaining do so just fine on every DAW except Steinberg's. The "VST3=sidechaining" stuff is only true for Cubase and Nuendo.
2. PreSonus came up with a widely-used extension to the VST2 spec (so widely used that it was incorporated into the VST3 spec and hyped as being new) that allowed for plug-in UI resizing.
3. The "plug-in goes to sleep when no audio is being passed" is a nice idea in theory. In practice, it's not that big a deal because just like any processing, plug-ins usually only eat resources when they're actually processing something other than silence. Also, implementing that part of the VST3 spec is not mandatory. No part of the VST3 spec is mandatory; it's a spec, not a law. There is no authority enforcing compliance. Of my VAST plug-in collection (Cakewalk has it at almost 500 FX), there is only one manufacturer I have seen implement silence=sleep, and that manufacturer, MeldaProduction, also implemented the feature in the VST2 versions of its products. Think about it: how many projects have you ever done that would benefit much from turning off a couple of plug-ins when they were idling?
4. Due to slow uptake of VST3, most plug-in manufacturers still provide VST2 versions of their products. Since they are less likely to want to code two separate versions, that results in their VST3's being restricted to a VST2 feature set.
5. The one single big advantage of the VST3 spec that I perceive is that it has a canonical location for the DLL's. But even that isn't without issues, as anyone with a 256GB SSD for their C drive and a large plug-in collection can tell you. Yes, you can circumvent this with sym links, but relatively few people have the knowledge and skills to implement that.

Regarding Cherry Audio's products not working so well in VST3 form, this, unfortunately, is less of a surprise than it should be. Cherry Audio shares staff and management with Acoustica, makers of Mixcraft. When Mixcraft first started supporting VST3, the otherwise rock solid Mixcraft was so crashy and buggy with VST3's that I gave up on VST3's for over a year waiting for the next version of Mixcraft, which worked fine with VST3's. It appears that even now, they may not have cozied up to the VST3 spec?

It's been a long time since I've run into VST3/VST2 issues, but one notable exception is Acustica (not to be confused with the DAW manufacturer) Multiply, the excellent freeware chorus. From its initial release, the VST3 version of Multiply will not work in CbB.

Thanks Starship!

That was some good info and observations. I didn't know about Cherry's association with Acoustica. Not that it would have mattered to me as I have no 1st hand experience with them... The dll location is of little importance to me between the vst2/vst3 systems and with what you said about the sidechaining not being restricted to vst3, what then is the point of the vst3 "update"?

 

[Promidi]

And then there is the issue that VST3 does not support program change MIDI events.  VST2 does.

[Keni]

Only one day and I'm already happier...

Switching back to vst2 is working great for many things here... I'm so glad this came to light!

 

[Starship Krupa]

23 hours ago, Keni said:

I didn't know about Cherry's association with Acoustica. Not that it would have mattered to me as I have no 1st hand experience with them...

The headquarters of both companies is in a tiny town just outside one of the entrances to Yosemite National Park here in California.

Having participated in their beta program enough to get my name in the credits for the Mixcraft 7 release,  something I can tell you about Acoustica is that they are one of the most quality-minded software manufacturers that I've ever dealt with. So please report your experience and findings about this performance issue to them. They will likely want to know about it and work with you and the BandLab Cakewalk engineers to fix whatever is.

23 hours ago, Keni said:

what then is the point of the vst3 "update"?

Good question, and one that I can't really answer. Without being able to read the minds of the folks at Steinberg, there's only speculation. It could be that there were starting to be too many extensions to the VST spec that weren't controlled by Steinberg, and they feared losing their grip on it.

Maybe they thought that being able to announce a shiny new technology that their own DAW's would be the first to support would be good for marketing.

Maybe the Cubase/Nuendo developers were having a hard time working out sidechaining support in their apps and wanted to force that work onto plug-in developers.

Whatever drove the move, as far as I can see it backfired. Other manufacturers (correctly, IMO) saw little advantage to supporting the new format. Rather, it only increased their coding and testing burden. Adoption was slow. When they finally applied their legal muscle to force new developers to adopt the format by refusing to issue more licenses to develop VST2, it served as an alert to participating vendors that Steinberg had too much of the wrong kind of control and that a more open and flexible spec might serve the industry better. So now there is CLAP, a competing plug-in format.

As for CLAP, as long as Steinberg continues to play nice, I don't think it will become the dominant format. But I'm glad it exists, because it serves to show Steinberg that if they do try any more funny business, the industry has other options

My suspicion is that if you ask anyone in the business of developing plug-ins or hosts for them about VST3, they'll tell you that the canonical DLL location is the only thing that they benefit from. I'm sure it eliminated a LOT of easily resolved support issues. However, I was so used to using custom locations for my VST2 plug-ins that I initially tried doing the same with VST3's, which of course didn't work too well....

19 hours ago, Promidi said:

VST3 does not support program change MIDI events.  VST2 does.

Is it that VST3 doesn't support it or is it that plug-in and/or host manufacturers stopped supporting it?

Communication between host and plug-in regarding presets in general seems to have gotten lost along the way. Where it seemed like most VST2's relied on the host for preset management, and reported their own presets to hosts' preset managers, in the VST3 era, this isn't the case. Now it's unusual for a plug-in to use that part of the spec to report their presets, and every plug-in has its own proprietary preset manager. Which can be hard to find and quirky to navigate, depending on the developer.

The VST3 spec does call for a canonical location for .vstpreset files, but few plug-in companies use it and Cakewalk's support for it is clunky. That's a drag, because I like using the host's preset manager more than the ones within the plug-ins, which have to be learned for each different manufacturer.

[Keni]

1 hour ago, Starship Krupa said:

The headquarters of both companies is in a tiny town just outside one of the entrances to Yosemite National Park here in California.

Having participated in their beta program enough to get my name in the credits for the Mixcraft 7 release,  something I can tell you about Acoustica is that they are one of the most quality-minded software manufacturers that I've ever dealt with. So please report your experience and findings about this performance issue to them. They will likely want to know about it and work with you and the BandLab Cakewalk engineers to fix whatever is.

Good question, and one that I can't really answer. Without being able to read the minds of the folks at Steinberg, there's only speculation. It could be that there were starting to be too many extensions to the VST spec that weren't controlled by Steinberg, and they feared losing their grip on it.

Maybe they thought that being able to announce a shiny new technology that their own DAW's would be the first to support would be good for marketing.

Maybe the Cubase/Nuendo developers were having a hard time working out sidechaining support in their apps and wanted to force that work onto plug-in developers.

Whatever drove the move, as far as I can see it backfired. Other manufacturers (correctly, IMO) saw little advantage to supporting the new format. Rather, it only increased their coding and testing burden. Adoption was slow. When they finally applied their legal muscle to force new developers to adopt the format by refusing to issue more licenses to develop VST2, it served as an alert to participating vendors that Steinberg had too much of the wrong kind of control and that a more open and flexible spec might serve the industry better. So now there is CLAP, a competing plug-in format.

As for CLAP, as long as Steinberg continues to play nice, I don't think it will become the dominant format. But I'm glad it exists, because it serves to show Steinberg that if they do try any more funny business, the industry has other options

My suspicion is that if you ask anyone in the business of developing plug-ins or hosts for them about VST3, they'll tell you that the canonical DLL location is the only thing that they benefit from. I'm sure it eliminated a LOT of easily resolved support issues. However, I was so used to using custom locations for my VST2 plug-ins that I initially tried doing the same with VST3's, which of course didn't work too well....

Is it that VST3 doesn't support it or is it that plug-in and/or host manufacturers stopped supporting it?

Communication between host and plug-in regarding presets in general seems to have gotten lost along the way. Where it seemed like most VST2's relied on the host for preset management, and reported their own presets to hosts' preset managers, in the VST3 era, this isn't the case. Now it's unusual for a plug-in to use that part of the spec to report their presets, and every plug-in has its own proprietary preset manager. Which can be hard to find and quirky to navigate, depending on the developer.

The VST3 spec does call for a canonical location for .vstpreset files, but few plug-in companies use it and Cakewalk's support for it is clunky. That's a drag, because I like using the host's preset manager more than the ones within the plug-ins, which have to be learned for each different manufacturer.

Interesting stuff...

Clap, huh? I've managed to avoid that one these days. ?

Funny, but I always use Cake's preset mgr. so much easier to me than a dozen different systems.

I guess Microsoft is determined not to upgrade WDM to pick up the slack. It always worked fine for me.

Oh, and I did contact Cherry about their latency issue. The did improve that considerably not long after. If I use the vst2 versions I can operate at 128/256 which is ok with vsynths most of the time.

We're really due a major improvement in digital audio processing speed (latency). It’s truly a severe roadblock.

Edited November 22, 2023 by Keni

[Promidi]

2 hours ago, Starship Krupa said:

Is it that VST3 doesn't support it or is it that plug-in and/or host manufacturers stopped supporting it?

The Former

Host is irrelevant. 

What ever host you use, VST3 VSTi plugins do not respond to program changes

[Starship Krupa]

18 minutes ago, Promidi said:

The Former

Host is irrelevant. 

What ever host you use, VST3 VSTi plugins do not respond to program changes

That is really odd and messed up. I've been thinking about creating projects that will allow me to change synth patches within the song, but it seems like this was made much more difficult.

I also have so many soft synths that it would be nice to make "patch browser" projects that quickly step through the available sounds as a preview. This will be tougher to do as well.

What are the workarounds?

[Promidi]

13 minutes ago, Starship Krupa said:

I also have so many soft synths that it would be nice to make "patch browser" projects that quickly step through the available sounds as a preview. This will be tougher to do as well.

What are the workarounds?

Depends on the synth.  For instance, with Arturia synths,  you can assign CC values to go to the next and previous preset.

With Sampletank, you can do that as well