VST3 issues

Steinberg Lounge
1

Interesting read. Maybe that´s why my u-he satin vst3 glitches… Maybe thats why fxpansion BFD3 chose vst2.4. Also upcoming addictive drums 2 is VST2.4

Something fishy about VST3. It is the feature “automatic release CPU when not in use” that cause these famous “red” glitches. Also things lite note expression (like a love), not logical SDK etc. Steinberg have stopped to support vst2 and released as simplified vst3 SDK. I hope thingd workout. As a user i want developers (developers, developers, develeopers) to like VST3.

2

It seems that VST3 is extremely difficult to get to grips with and program. Which does not seem to make much sense to me if your objective is to encourage developers to adopt your standard. I have had issues with some vst3 plugins and avoid it where possible. The worrying thing is that Steinberg is withdrawing support for 2.4. It will be interesting to see where this leads.

3

Sad… :frowning:

4

Many things new and different are perceived as difficult or pointless.

I think one of the problems is the change towards the “known” way of coding plugins. E.g. in that thread above it is stated that there is a “simplified” option when programming a VST3 plugin. Why is there a simplified version at all? Because it makes it possible to take your current code base and slap in there. Voila, I now have a VST3 plugin, with no VST3 features, other than the ones possible by simply compiling it using the VST3 plugin framework.

However, it appears a VST3 plugin needs a few things that are very different from the traditional plugins architecture, e.g. a separation of church and state… pardon me, I meant of course the UI and the worker thread, modifying the audio engine to accommodate individual note expression, etc. This means a different approach to “programming plugins”. This in turn means that the traditional plugin formats needs accommodation, etc.

A developer typically wants provide the cool stuff, and so jumps into full VST3 adaption mode and can easily end up with a “fail”, simply because of the magnitude of change needed. Imagine having created this awesome synthesizer engine, and to find out that you have redo it differently. Unless you’re born to code these things, this will be a hard struggle, and some will end up saying “this sucks”, skip the whole thing and argue all the way.

Am I making a claim that the standard is without flaw? Certainly not, but keep on b*itching is not a solution. Trying to fix the actual faults is. Communicating actual faults and arrive at some decent compromise is. I mean, HALion 5 works, which means it can be done. The question is what does it take to get there?

IMHO, it is worth it, as a consumer. The functionality provided in VST3.5 is just simply fabulous, HALion 5 is the show case to which all other plugins should be measured. I am not referring to the audio engine itself (so don’t get your knickers in a twist) but to the features provided by virtue of being a (not “simplified”) VST3.5 plugin.

BTW, do you know who wrote version 3 of the VST plug-in specification? It was Matthias Juwan from the Studio One team.

5

I think what uhe were concerned about was the lack of clear instructions about how to apply vst3 at a more advanced level. They are probably one of the best developers around - so if they are having issues that say’s something surely.

6

If the automatic CPU saving function annoys you then just disable it in preferences - not hard to do.
The rest of it seems like the programmer who wrote the post made too many assumptions & got it wrong.
VST3 works much better than VST2 for me as an end user (native sidechaining alone is worth the effort) and I am not getting any issues with any VST3 here (Waves, Softube, Slate, Antares etc).