Problem if synth is only VST2?

[Markus Krause]

It's not the fault of 'lazy developers' that vst3 is still not properly established. There are valid reasons for this.

Midi 2.0 can be implemented to vst2 without any problems. The same is true for MPE.

vst3 did support not support Midi till 2018. Midi learn was not possible or just with dirty hacks.

For synthesizer-plugins vst3 had no significant advantages compared to vst2. Scaleable GUIs are possible with both formats.

Apart from this there were many technical problems with vst3 in hosts as well plugins. It took many years till this was sorted.

Vst2 support from the host's side will be available for at least a decade. The host developers would loose most customers, since vst 2.4 with 64bit is the most ised plugin format.

[chk071]

There are some synths only with VST2, no VST3 (Hybrid 3 was one I was think to get but it only is VST2). I know the VST3 is more new thing. I need to ask, is VST2 soon going to be same as 32bit and you can no use it anymore? VST2 same as 32bit and VST3 same as 64bit?

Probably not soon, but, at some point, it will be. Steinberg already only allows new developers to license VST3.

As Markus wrote, it surely will be a while until all hosts are VST3, but, to rely on it is surely a risky thing.

[Markus Krause]

This does affect only new developers and newbies usually only develop plugins. The developers of hosts and the established developers of plugins all have existing contracts with Steinberg that allow them to create vst 2.4 plugins and hosts also in the future. There is no need for panic at all

[chk071]

There is no need for panic at all

Surely not. Steinberg probably will be the first host which drops VST2 support. Considering the biggest plugin and sound company, Native Instruments, still only offers VST2, it surely will take a while until the sequencer companies really take such a drastic step. But, as mentioned, it will surely be inevitable at some point. It's just a matter of when that point exactly wil be. As a developer, I'd surely start developing VST3 versions now, if I haven't already.

[Ingonator]

As Live is my main host i actually i was quite happy when Ableton finally added VST3 support to Live 10.1.
Not because i prefer VST3 over VST2 but because of being able to use new plugins that are VST3 only like the new Zenology plugin from Roland (while older Roiand plugins are also available as VST2).

Most plugins i use in Live 10 are still using the 64-bit VST2 where it is available.

I agree that it should take a long time until major hosts/DAWs will drop VST2 support.

[jamcat]

It's not the fault of 'lazy developers' that vst3 is still not properly established. There are valid reasons for this.

Midi 2.0 can be implemented to vst2 without any problems. The same is true for MPE.

vst3 did support not support Midi till 2018. Midi learn was not possible or just with dirty hacks.

For synthesizer-plugins vst3 had no significant advantages compared to vst2. Scaleable GUIs are possible with both formats.

Apart from this there were many technical problems with vst3 in hosts as well plugins. It took many years till this was sorted.

Vst2 support from the host's side will be available for at least a decade. The host developers would loose most customers, since vst 2.4 with 64bit is the most ised plugin format.

I didn't call anyone 'lazy'.
I did say some were using changes to the VST spec with v3 that probably don't even impact them as an excuse not to develop VST3 plugins. But I think this has more to do with resource management than being lazy. I don't have to tell you that testing and support is the bulk of the iceberg that is hidden beneath the surface. It is a completely rational decision to try to limit the number of formats to support, and more developers actually should be doing just that. It would result in more frequent updates of better, more stable plugins. And more of them, too.

I just happen to think that the current, living format is the one developers ought to be investing in instead of one that is dead and buried. The longer a developer resists, the more inertia there is to overcome. I suspect that most plugins that aren't VST3 by now will never be VST3, and that concerns me greatly as an end user. I don't want to get invested in a plugin that already has an expiration date stamped on it. I want to be able to open up any mix a decade from now and have it work the same and sound the same as the day I made it. That means I need to be using only plugins that are solidly future-proof today, from developers who are reliable.

It looks like you agree that whatever issues people had with VST3 have since been resolved. There are very few holdouts that aren't also burnouts. Ableton is no longer a holdout. It seems like only Native Instruments is. Personally, I have no faith in NI. They have a long history of abandoning their software, and they are currently engaging in yet another round of that. They could probably toss their remaining plugins in the garbage for all most people care, except for Kontakt. There is an entire industry that is completely dependent on it, so I hope they can get their act together for its sake.

[zvenx]

It's not the fault of 'lazy developers' that vst3 is still not properly established. There are valid reasons for this.

Midi 2.0 can be implemented to vst2 without any problems. The same is true for MPE.

vst3 did support not support Midi till 2018. Midi learn was not possible or just with dirty hacks.

For synthesizer-plugins vst3 had no significant advantages compared to vst2. Scaleable GUIs are possible with both formats.

Apart from this there were many technical problems with vst3 in hosts as well plugins. It took many years till this was sorted.

Vst2 support from the host's side will be available for at least a decade. The host developers would loose most customers, since vst 2.4 with 64bit is the most ised plugin format.

What about Multiple Dynamic I/O for surround sound?
And Audio input for VST Instruments so one can use say the filters and effects of ElectraX on Audio within having to wait for you maybe one day to do an ElectraX effect plugin.
And if perchance your plugins where multitimbral, Multiple Inputs/Outputs would have been handy.
Although granted many of these don't affect your product line and you wouldn't probably get more sales from adding vst3 as a format. But I am not sure the I agree with the 'no significant advantages' for vstis in general.

Waves came on board in 2009, 11 years ago. I have never had an issue with Waves vst3 plugin that wasn't also there in vst2.4.. Anyone here has?
rsp

[Markus Krause]

Multiple inputs and outputs is also possible with vst 2.4 and previous versions.
Surround support is also already possible with vst 2.4 and previous versions. This is not a vst3 feature. Besides of that surround processing plays no significant role at all for music production. Sadly.
Audio Input for synthesizers is also possible with vst 2.4.
Dynamic inputs and outputs (vst3) are problematic since not all hosts can handle it or even crash.

The only really usefull additions for synths that i can see for vst3 is longer parameter-names , the ability to group automation-parameters and the ability to group outputs in the mixer. But we do receive nearly no requests for this from the customers side

[zvenx]

My recollection is all the Surround ones I have (like Absynth), it is several version of the plugin
(Abysnth Stereo, Absynth Surround), whilst vst3 it is one plugin. Is this not correct?

How come you haven't utilitzed Audio input in your synths or it is there and just Cubendo doesn't support it?

rsp

[whyterabbyt]

My recollection is all the Surround ones I have (Absynth and Kontakt come to min), it is several version of the plugin
(Abysnth Stereo, Absynth Surround), whilst vst3 it is one plugin. Is this not correct?

Yes, and Waves provide separate mono, mono-to-stereo and stereo versions of their VST2 plugins. Not because its a requirement of VST2, just because that's the way they've chosen to do it.
Meanwhile various other plugins (eg u-he stuff) have multiple input/output configurations wrapped up in a single VST2. Not because its a requirement of VST2, just because that's the way they've chosen to do it.
Same with NI.

Have a look at the .dll files for Kontakt. All of them except one will be tiny, a few kb, because basically all they are is a wrapper which launches the allegedly stereo-only version.

After all, the 'stereo' Kontakt already has tons of outputs, and full routing to those outputs, so nothing architecturally different from the requirements for a surround version.

Mostly these alternate versions existed because of (legacy) limitations in specific hosts, not intrinsic VST2 limitions.

[Markus Krause]

@zvenx: i created vst2 plugins that are available als effect and as a plugin: refx slayer (vst2. 1?)in the year 2002 and tone2 filterbank (vst 2.2) in the year 2004.
There are two easy ans simple approaches how you can do this:
1) compile a second version with a different dll. This is not much hassle. Just some preprocessor defines
2) a completely identical dll which is just renamed. When the plugin loads it notices that it has been renamed an enables audio input and answers to the host that it is an effect

But i admit that with vst2 the user still looses around 1mb of harddisc space because of one additional dll installed on his system...

[Markus Krause]

The truth about vst3 is: it was at first mainly a big marketing-bulb created by Steinberg. From the technical side it had very few advantages compared to v2.4 but came with serious shortcomings like lack of midi support, incompatibilities, no backwards compatibility and a badly designed SDK. That's why it established so slowly.
Meanwhile the VST3 SDK and also other frameworks like Juce even ship with technologies that are deprecated like OpenGL. So plugins that use this might stop working with the next MacOS update.
Hopefully Steinberg will leave VST 3 behind soon and create a simple and slim VST4 SDK with Midi 2.0 support, MPE support and without OpenGL

[metaside]

I never use vst3 anyway

Same here. I tested some VST3-only plugins but so far I always only bought plugins that still have a VST2 version. Glad every time the "VST3" disappears from my DAW after testing, since it makes the selection of plugins much faster if you don't have to click on "VST[2]" first...

Hopefully Steinberg will leave VST 3 behind soon and create a simple and slim VST4 SDK with Midi 2.0 support, MPE support and without OpenGL

Amen to that!

[chk071]

Out of interest: Why do you NOT use VST3's of the plugins where it's available? My experience is that you won't have any disadvantage with that, and, there's no difference in terms of stability either, because, it seems like nowadays developers definitely have a handle on the whole thing.

Whenever there's a VST3 of a plugin, I use it, because I see no difference in terms of usability/stability. Of course it's also fine to do it the other way around, but, I just don't see the point, because, like with 64-bit, I like to move forward, not backward. Even though I admit that it's not quite the same thing, as 64-bit is a real step fowards, while VST3 isn't quite as much a step forward, at least from what I always read. In lack of the knowledge and skill to look into it myself, I can only rely on third party opinion and statements.

[zvenx]

@zvenx: i created vst2 plugins that are available als effect and as a plugin: refx slayer (vst2. 1?)in the year 2002 and tone2 filterbank (vst 2.2) in the year 2004.
There are two easy ans simple approaches how you can do this:
1) compile a second version with a different dll. This is not much hassle. Just some preprocessor defines
2) a completely identical dll which is just renamed. When the plugin loads it notices that it has been renamed an enables audio input and answers to the host that it is an effect

But i admit that with vst2 the user still looses around 1mb of harddisc space because of one additional dll installed on his system...

That 1mb is negligible.
rsp