How important is VST3 support for you as a customer

[Francisco Cepero]

I've just gone with the majority opinion. Since I discovered VST plug-ins (version 2 of the standard, that is), my music has vastly improved.

But I don't think my music could get any better unless I start paying attention to the mastering tips by the so-called experts in the magazines, LOL.

On the other hand, if I'm satisfied with my sound, then that's what matters, and not other people's opinion. And yes, I have too many plug-ins.

[osiris]

What's VST3?

And fish, I guess...

[zvenx]

I repeat vst 2.4 is not suppose to hve multiple outs and sidechaining.... some developers found an unsupported way round it. It is like buying a ford car, that isn't designed to drag loads, finding way to put more horsepower in the engine and being suprised when ford no longer wants to honor the warranty.
rsp

the developers of vst, steinberg do not support sidechaining in vst 2.4.....
they do in vst 3.....
some have found unintended workarounds to enable sidechining in vst 2.4... waves supports it in vst3 as intended and that makes them lazy?>
rsp

the fact that Steinberg doesn't enable easy sidechaining in its host doesn't mean the possibility isn't there. In REAPER for example, sidechaining is a breeze (and only a couple of clicks away). But instead of updating their host Steinberg decided to invent a new plugin standard. "Newest standard" makes a good point in marketing materials. Innovation is so innovative.

And yes, it makes Waves lazy not to add multiple inputs to their 2.4 plugin and make it support sidechaining.

Also, i believe score writing has nothing to do with VST3. New VST expressions could be implemented in 2.4 (old ones were there), so there was no reason to make it VST3-only.

Guys, the problem with VST3 is not that it sucks. The problem is that it doesn't solve anything and doesn't introduce anything fundamentally new. Sidechaining was there. VST Expressions were there. Score editors were there. Why so much hype about something that was already possible since ages ago (and had good, convenient implementations in non-Steinberg hosts)?

[LXNDR1]

And my money will go to the one who gives me that, I don't care if it's Steinberg or Satan.

it's so appealing i might add this to my signature

[aciddose]

I repeat vst 2.4 is not suppose to hve multiple outs and sidechaining.... some developers found an unsupported way round it. It is like buying a ford car, that isn't designed to drag loads, finding way to put more horsepower in the engine and being suprised when ford no longer wants to honor the warranty.
rsp

you're simply wrong, period.

vst is supposed to have as many inputs/outputs as you like. you can link them as stereo, or they can be mono. it supports speaker configurations for more complex configurations as well (like 5.1)

there is absolutely no reason they couldn't have made a tiny modification by adding a couple defines to get the "sidechain" configuration they have now. the only limitation of vst2 (as per the 'official' spec) is that there is no specific way to define that a group of channels are a sidechain, so the user needs to select which channels manually. that's generally easy - if you've got four channels marked as two pairs, the second pair is the sidechain. guess what, it's one click.

are you a programmer? do you have any idea what you're talking about? i'll go ahead and assert that no, you are not and do not.

like i said, it isn't possible "officially" to define the channels, but that doesn't mean you can't. it doesn't require a "work-around". all it requires is defining a couple values as meaning "sidechain".

in fact there is no reason you should do so, though. why mark something specifically as "sidechain" ? you can already name the channels/busses whatever you like. why is there any need to specifically define what a channel is used for? it might be used to input modulation, or it might be used to transmit text between plugins. there are no specific limitations for what you can do so why impose them?

that is what makes vst3 stupid - it's an extremely large, bloated set of extra limitations rather than a few minor improvements to vst2.

in fact forget about "sidechain". you can do whole mixer plugins with 20 stereo inputs and five output busses including eq, limiting, meters and all that stuff without any "workarounds" what-so-ever. the only problems are in cubase's limitations for routing signals. most other hosts can do it.

[whyterabbyt]

I repeat vst 2.4 is not suppose to hve multiple outs and sidechaining....

otoh, its not supposed to not have multiple outs and sidechaining. in fact there's no 'supposed to' to it at all. You get access to some code. You can change it how you like. You can't pretend it didn't come from the place you got it from, and its useless if the end result doesn't talk to other code the way the other code expects it to, but that's it. If some company decides to add a billion and one proprietary extensions to their plugins and host, then there is nothing which can or does prevent them from doing so.

some developers found an unsupported way round it. It is like buying a ford car, that isn't designed to drag loads, finding way to put more horsepower in the engine and being suprised when ford no longer wants to honor the warranty.

car analogy fail. its actually more like buying a van which only has seats in the front cabin, and discovering that there's room to put seats in the rear. it makes no difference to the van if there are seats in the back, nor does it affect anything the van is capable of. and since a van is designed to carry stuff from place to place, then nothing in the warranty could possibly preclude the stuff its carrying from including more people than fit up in the seats up front.

[zvenx]

@aciddose, you are right, I not a programmer and definitely don't know first hand what I am speaking about, I am simply regurgitating stuff from an SB source....re: multiple outputs I meant, on the fly... that is in one plugin you can change dynamically the number of outputs you want to use, instead of separate version of the plugin.

@whyterabbyt, yes your analogy is better
rsp

[Big Tick]

I am simply regurgitating stuff from an SB source....re: multiple outputs I meant, on the fly... that is in one plugin you can change dynamically the number of outputs you want to use, instead of separate version of the plugin.

See opcode audioMasterIOChanged in VST2.4: plugin notifies host the numInputs and/or numOutputs of plugin has changed.

Saying that it wasn't possible in VST2.x is complete BS.

[aciddose]

vst2's only limitation "dynamically" (if i understand what you mean) is that you always need to have at least the greatest number of outputs set up for compatibility.

so if you want to adjust from 1 to 8 outputs, you need to always provide for 8, and just not output to them.

if you wanted, a very minor change to the spec would fix this; simply saying that when you call host->audioMasterIOChanged (already part of vst2.0) that the host must actually respect it. for safety reasons, the spec should also say it can only be called from within the process function after completing the last block desired before the change.

so essentially it's already in there, cubase just never implemented it's own spec in a working way, and they never created a vst spec for _other hosts_ because those are competitors.

in fact there are a lot of things in the vst spec which cubase never used, or which were partially defined and then ignored later on because the people working on things changed, they worked on different things, or they were simply forgotten about.

you have to remember the purpose of vst: to sell copies of cubase/nuendo.

[aMUSEd]

I was just reading the N-Track studio advert - apparently N-Track supports VST3. So that makes 4 hosts I know of (Cubase, Nuendo, Studio One and N-Track) - is that it or are there more now? Seems like it's most likely to take off when more hosts adopt it.

[Arglebargle]

I honestly couldn't give a f**k.

[mojogigolo]

with all the audiophiles here (myself included), if the VST3 specs dont interest us, its a failure of sorts.

[kelldammit]

Despite some developers shouting otherwise, vst3 is here to stay.
Eventually the world will move on with or without them on board.
rsp

vst3 has been here for quite some time, and most devs will likely continue to ignore it, as they have until now. the fact that this conversation has only come about so recently should be telling in and of itself. the only people getting left in the lurch as "the world moves on" are the steinberg users, because for the rest of the vst world, this new standard represents little to no real motion at all.
when the 'borg offers up a new version of vst that actually introduces meaningful features to users across the board, i'd expect that most devs (host and plugin) would adopt it pretty readily.

k

[Lotuzia]

I prefer VST3 but I have a lot of VST 2.x either. Actually far more vst 2.x to be honnest.

I'd prefer NI to have VST3 versions, if only just to avoid the different xx outputs versions. this implies that you make choices at an early stage of the project ( How many outputs will this need in the end ? ) and could be avoided.

But I can live with that

VST3 is not mandatory, its cool when it is available. Like Urs stated it many times I think that if it was possible to generate easily Vst 2 version derived from the Vst3 versions code, a lot of devs would jump into the wagon.

until this .....

Btw my Daw is Vst3 compliant too, which is probably the cause of the above.

LtZ

[Freaqpeak]

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

I find the side chain in VST3 awesome and simple. Atleast in Cubase.
Only reason why I like VST3 though.