Problem if synth is only VST2?

[zvenx]

It would be nice if Arne and/or Yvan from SB would join this thread to give it from their technical side, which I clearly can't do properly (since I am not a developer).
I clearly can't/won't repeat anything I know/have heard from NDAs information, I would though imagine that VST3 was a chance to rebuild the house from the ground up rather than using old codebase (vst2.4) and adding features on it.

rsp

[Markus Krause]

This is the reason why we (Tone2) did still not move to VST3 - other developers might have different reasons:

- Unlike many other companies we do not use a wrapper-technology like JUCE. We develop native VST 2.4 plugins. A wrapper is an additional abstraction layer. This is comfortable when you want to support a large number of plugin-formats with low effort. But it always comes at the cost of performace and you loose some features
- VST 2.4 works relieable in all known host and will be supported by them for a very long time. It's an established plugin-format. It's the industry-standard
- Our products in the current form will continue to work for a very long time - most likely a lot longer than most VST3 plugins that are currently on the market, since they use commonly used technologies like GDI+ and Cocoa
- VST3 had serious compatibility-problems with various hosts in the past
- The majority of the customers do use VST 2.4 with 64 bit
- Only very few customers request VST3. They do not care about what plugin-format is used. But they care about stability and relieability
- We need to develop, test and host another plugin-format. This means additional costs or lost development-time that can not be invested into new features and enhancements
- Old song-projects created with vst 2.4 can not longer be loaded with the VST3 plugin
- Moving VST 2.4 plugins to VST3 does break the downward-compatibility
- VST3 does not longer allow us to provide updates for the existing, old plugins
- The development effort for migrating a VST 2 product to VST3 is extremely high. It is more economic to create a completely new product instead
- OpenGL, which is used by VST3 SDK (VSTGUI and JUCE) is deprecated by Apple. Plugins that use it might stop working with the next MacOS update. Apple most likely will kick OpenGL with the ARM-CPU laptops that might arrive soon
- No significant advantages for synthesizer-plugins compared to VST 2.4
- No proper MIDI support and no Midi-learn till 2018. No Midi 2.0 support. No MPE support till (?)
- VST4 might come soon?

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

[zvenx]

Thanks for the detailed info.... just one difference.

"- Old song-projects created with vst 2.4 can not longer be loaded with the VST3 plugin"

There seems to be two ways of implement vst3, at least in cubase.

1) Some plugins that are in vst3 and vst2.4 format, cubendo only sees the vst3 unless you remove the vst 2.4.
And
2) some Cubendo sees both vst2.4 and vst3.

The former ones (Method 1) actually open older projects created with vst2.4 fine using their vst3 format.
Best example I can give you is Exponential Audio Reverbs, until Relab Sigwhateveritis called it was the only reverb I used once they came out.
They only came out as vst2 so they were in all my projects as such for years.
Once the vst3 came out and it was safe to use, I started to use that instead.
Opening my old projects (which I often have to do) was no problem, it just substituted the reverbs for the vst3 versions fine.
rsp

[jamcat]

This is the reason why we (Tone2) did still not move to VST3 - other developers might have different reasons:

- We need to develop, test and host another plugin-format. This means additional costs or lost development-time that can not be invested into new features and enhancements

This is my argument for dropping VST2 plugin support
And ESPECIALLY 32-bit plugin support.