How important is VST3 support for you as a customer

[helium]

While developers complain about having a hard time porting their VST2 plugins to VST3 without any real benefit on their side I'd like to hear the customer's point of view.

[hibidy]

I really don't care at this point in time. Thought there are some standout companies that have done it well (fabfilter comes to mind) the vast majority of beloved stuff isn't. I think many of us are far more concerned about x64 support than vst3. Omg, I just remembered......now there is 3.5

[D N A]

I don't care

[chokehold]

Couldn't care less.

As I recall, the only true step forward with VST3 is sidechaining?
But that's been worked-around in VST2.x plugins, so as long as there are no major compatibility/stability/performance optimizations in VST3 against VST2.x and as long as Hosts continue to support VST2.x, having them ported to VST3 is not much of a pro argument in my eyes.

Dear developers, port your plugins to x64 first...

[EDIT]
I just read about the "new" features of VST3, the list had positions like "audio inputs for VST instruments" in it... WTF? I could've sworn there were plugins with this feature available years before VST3?

Scalable GUI size - who (from a user point) cares. If the "designer" does a good job, this isn't necessary.

Support for x64 technology - uhm... wasn't that available ages ago? Maybe because it's a compiler feature, not a plugin feature? And if this is about "internal precision" ... that's been around for ages as well, so no real revolution there.

Not processing when no signal - wow. Impressive. I recall there's a module for SynthEdit that does exactly this, so if it's in SynthEdit ... it must be available for other plugins. And once again: if the programmer does a good job (and implements this functionality), this isn't a necessary feature.

The whole "what's new" feature list reads like a "what the devs won't have to do anymore" list, and really ... most plugins are expensive enough, so dear devs ... if you're asking money for your plugins, please see to that they work flawlessly with current technology standards (x64) before going to the trouble to port them to APIs that allow you to comment out functions that should already be in there.

[AdmiralQuality]

Couldn't care less.

As I recall, the only true step forward with VST3 is sidechaining?
But that's been worked-around in VST2.x plugins, so as long as there are no major compatibility/stability/performance optimizations in VST3 against VST2.x and as long as Hosts continue to support VST2.x, having them ported to VST3 is not much of a pro argument in my eyes.

Dear developers, port your plugins to x64 first...

[EDIT]
I just read about the "new" features of VST3, the list had positions like "audio inputs for VST instruments" in it... WTF? I could've sworn there were plugins with this feature available years before VST3?

Scalable GUI size - who (from a user point) cares. If the "designer" does a good job, this isn't necessary.

This is supported in VST 2.4 as well. You just don't see it much as it's a daunting task to implement (not due to the VST spec, just because it's already hard enough to design an interface that works well at one size. But there's been sizing VSTs for a long time... look at Arturia's Moog Modular V for just one example.)

Support for x64 technology - uhm... wasn't that available ages ago? Maybe because it's a compiler feature, not a plugin feature? And if this is about "internal precision" ... that's been around for ages as well, so no real revolution there.

Not processing when no signal - wow. Impressive. I recall there's a module for SynthEdit that does exactly this, so if it's in SynthEdit ... it must be available for other plugins. And once again: if the programmer does a good job (and implements this functionality), this isn't a necessary feature.

This is in the realm of the host's responsibility, not the plug-in's. If a VST 2.4 host wants to stop a plug-in from processing, it simply doesn't call it's process function.

True, the ability for the plug-in to say that no more tail is coming could assist the host in knowing when to "sleep" it. But that said, I find this feature silly. I don't want CPU load going up and down as tracks become silent or not. I want the worst case CPU load for whatever plugs I'm running in my project when I start recording (otherwise a perfect take could be ruined when some backing track starts playing and its plug-ins suddenly activate). If I ever wanted to disable a plug-in, I'd just automate a bypass of it (or a mute of the entire track) during portions where I don't need it. But I'd be more likely to just freeze tracks. That's how to manage CPU consumption, NOT by having plug-ins turning themselves on and off at their own whim.

The whole "what's new" feature list reads like a "what the devs won't have to do anymore" list, and really ... most plugins are expensive enough, so dear devs ... if you're asking money for your plugins, please see to that they work flawlessly with current technology standards (x64) before going to the trouble to port them to APIs that allow you to comment out functions that should already be in there.

I'd never port to VST 3, as I'd still have to release 2.4 versions for all my existing customers who don't own (or care to own) VST 3 hosts. 2.4 works on everything, so it's the de facto standard and probably will be for a LONG time.

And wouldn't you rather have your favorite developer working on new features and new products rather than spending a LOT of time implementing a new interface standard that does exactly what the old standard already did?

[Urs]

I'm looking forward to it. VST3 would make my life much easier if I could at the same time ditch VST2 altogether. Unfortunately latter is gonna be around for a while...

VST3 would be good because it has is a multi-plugin-in-a-single-binary thing which on VST2 is known as shell. While the shell stuff never really worked except for one company who supposedly did it wrong (cause? effect?), it does seem to work fine in VST3. So in VST3 I could ship a single binary for all my bundled plugins just like I do for AU and RTAS. This saves hassle, resources and it even eases communication between different plugs. Would be great to have.

Urs

[Josmoker]

+1 for x64 support being more important than vst3. Though I have been thinking about purchasing more plugs from FabFilter due to them being vst3.

[zvenx]

I use Nuendo and Cubase and a lot of those 'new' features that ppl have in vst 2.4 we dont get to use....so I for one find vst3 important.....not a deal breaker, as I do own several vst 2.4 plugins that haven't been ported, but it is a very good incentive for me to support a developer.
rsp

[nickb100]

x64 is more important than vst3

[Angus_FX]

I'm looking forward to it. VST3 would make my life much easier if I could at the same time ditch VST2 altogether. Unfortunately latter is gonna be around for a while...

VST3 would be good because it has is a multi-plugin-in-a-single-binary thing which on VST2 is known as shell. While the shell stuff never really worked except for one company who supposedly did it wrong (cause? effect?), it does seem to work fine in VST3. So in VST3 I could ship a single binary for all my bundled plugins just like I do for AU and RTAS. This saves hassle, resources and it even eases communication between different plugs. Would be great to have.

Hardly worth rewriting the whole API for - you can do this already:- just have the installer copy the binary to different named bundles/DLLs and have the code auto detect which path to take from there. We do that for Synth Squad, works a treat.

IMHO, there's very little technical reason for VST3 to exist - it's marketing, pure and simple - a wish by Steinberg to draw a line under a decade of ad-hoc VST2 development and create something that customers will perceive as "new" and "clean".

[Urs]

Hardly worth rewriting the whole API for - you can do this already:- just have the installer copy the binary to different named bundles/DLLs and have the code auto detect which path to take from there. We do that for Synth Squad, works a treat.

I do that too. Still not as elegant as other methods.

On MacOS X you can't just rename the bundles. You have to patch them on binary level.

IMHO, there's very little technical reason for VST3 to exist - it's marketing, pure and simple - a wish by Steinberg to draw a line under a decade of ad-hoc VST2 development and create something that customers will perceive as "new" and "clean".

Agreed.

However, VST2.4 64-bit for Cocoa looks merely like an ugly workaround to me. Looks much better in VST3.

Also, as there is no VST->RTAS wrapper that works with my VST 2.4 stuff (e.g. relies on deprecated opcodes or something), I'll just do VST3 alongside RTAS Win and their respective 64-bit implications.

[Angus_FX]

On MacOS X you can't just rename the bundles. You have to patch them on binary level.

I don't find that to be true. We supply a different info.plist, a different rsrc (needed for AU, not VST), and that's it. The mach-o binary is 100% the same.

Re deprecated opcodes - there's clear (and very easy!) dev guidelines for dealing with that, can send you a copy if you're interested.

[Urs]

I don't find that to be true. We supply a different info.plist, a different rsrc (needed for AU, not VST), and that's it. The mach-o binary is 100% the same.

For AU you don't need multiple copies. You can have as many plugins in one component as you want.

You however can't just rename anything to make it "different", as the Bundle API can't query the bundle name. You have to change something either on binary level (including info.plist) or add different files into the bundle. Both of which is not needed in VST3, AU nor RTAS.

Re deprecated opcodes - there's clear (and very easy!) dev guidelines for dealing with that, can send you a copy if you're interested.

It doesn't matter if it's easy or not. I often prefer difficult for a challenge. What guidelines do you mean?

[kelldammit]

for most users or plugins and instruments, it's probably irrelevant. and now that 3.5 is out...well...i guess it's moot anyway.

for those that frequently deal with large multitimbral ensembles, though, it could be nice...especially when coupled with x64.
doesn't vst3 allow for a single plugin instance to deal with more than 16 discrete midi channels, like RTAS or MAS do? or did this already exist in the 2.4 spec?
The reason i ask is because VE Pro allows you to use up to 32(!) discrete midi sub-interfaces per server instance. the 2.4 version of the plugin apparently does not "see" the sub-interfaces at all, while the vst3 plugin does.

k

[rasmusklump]

The other way round for me:
I would not buy a plugin that is not available in 2.4 format, as I want to sort the plugins the way I want. This is no longer possible with 3.
Although I use Nuendo I only install th 2.4 Vrsions.