Specific technical questions about VST3, and info for users

[Guillaume Piolat]

How do you all feel about VST3 these days?

(we have no VST3 support)
Zero interest in it unless Steinberg moves first and removes VST2 from Cubase. No single customer has asked for it, you get more request for LV2 or Linux or Protools 10, than VST3. It's a pure money loss from this side.

[lorcan]

How do you all feel about VST3 these days?

Works great here.
A really nice feature is the fact that parameter are referenced by a unique id, and not a zero-based index as in VST2. Makes it very simple to add/remove parameters without breaking compatibility and automation especially.
You can also group parameters in logical modules, good for structuring things.
And the host context menu access is very handy too (map parameters and automate with 2 clicks).

While not strictly necessary, the UI/DSP separation forces you to do clean data communication / threading.
Steinberg could do something like Waves Soundgrid, using a headless Linux box to do the processing.
VST3 gained Linux support recently, so one might wonder.

It's strange VST3 gets bashed so much, whereas no one seems to complain about AUv3 which forces you to use Swift/Objective-C and is quite poorly documented too IMHO.

[hibrasil]

Steinberg could do something like Waves Soundgrid, using a headless Linux box to do the processing.
VST3 gained Linux support recently, so one might wonder

hmmm i think you might have sussed something out there. i was wondering why vst3 did linux now

[Blue Cat Audio]

Regardless of implementation and design considerations, our feeling, both as a host and plug-in manufacturer, is that VST3 is still not as mature as VST2 today . Many (if not most) hosts and plug-ins (including Steinberg's...) are still more stable and predictable in VST2 format. So we still strongly advise customers to use VST2 versions when possible. There are far less surprises and strange bugs with VST2 so far.

Also, the lack of proper MIDI support in VST3 causes many problems. For example, it looks like every developer is using the same hack to receive MIDI CC events (and we do too), but it causes thousands of extra parameters to be exposed when they have not been properly disabled for automation. And if you want to output MIDI CC messages from a plug-in, there is still no solution.

So we implemented VST3 support because customers were asking for it (mainly for Cubase side chain and because of Cubase's window resize bug on Windows for plug-ins - and on the host side because some plug-ins only exists as VST3). But honestly, if there is no strong incentive of doing it, just skip it for now.

[hibrasil]

Thanks for the thoughts. I'm currently writing a paper talking about different apis, I have summarised my thoughts on VST3, if anyone would like to comment (work in progress)

https://docs.google.com/document/d/1Hlg ... sp=sharing

[Jeff McClintock]

Good summary.
One other advantage of a COM-like approach is the improved efficiency of calling the plugin's methods. In VST, the DAW passes in an "opcode" which is then decoded and dispatched via a huge "switch" statement containing a series of secondary function calls. Whereas in VST3 the DAW directly calls the target plugin method via a virtual function pointer. This is faster and most efficient than the VST2 method.

As to the absence of MIDI 1.0, my opinion is this will gradually become an advantage now that MPE and even more advanced forms of MIDI are on the horizon because VST3 is "MIDI agnostic", plugins will require few changes to accomodate note-expressiion and high-definition versions of MIDI.

Lastly, you mention JUCE but not the problem that JUCE does not support sample-accurate parameter updates yet. When that happens, JUCE plugin developers will be in for the same same type of disruption as developers currently enduring the pain of modernising their code for VST3.

I think VST2 ingrained a lot of bad design ideas on the plugin developer community, which have now become considered "the norm", and this has caused a lot of resistance to VST3.

[matt42]

Well, it only took 10 years and counting for the lack of midi support to have any real payoff. I can't understand why more devs aren't falling over themselves to jump on vst3. (apologies for the sarcasm)

Also the implementation of the GUI DSP separation didn't work out so well in practice. Reliable and timely communication between GUI and DSP components in all hosts was often achieved by hacking the single component effect (or whatever it was called) even the Steinberg hosts were messing up the communication in certain situations. I don't know how long before they fixed it, because I had given up caring about it.

I suspect a lot of devs felt the same way as adoption was quite low.

[Jeff McClintock]

yeah, I think although the underlying architecture of VST3 is very good, Steinberg's *implementation* of it in the SDK was quite poor. For example try making something as simple as a gain plugin in VST3, what should be a few lines of code takes *pages* to implement. As far as making "make easy things easy and hard things possible" it's a disaster. This is solely down to Steinberg's SDK not providing default implementations of standard functionality.

*this* is a gain plugin that (hopefully) a newby can understand (also using COM-based stuff under the hood btw). The VST3 SDK could have easily been implemented with the same design goal of hiding the complexity underneath it all.

#include "./AGain.h"

REGISTER_PLUGIN2( AGain, L"Gain" );

AGain::AGain() : MpBase2( )
{
// Register pins.
initializePin( 0, input1_ );
initializePin( 1, input2_ );
initializePin( 2, output1_ );
initializePin( 3, output2_ );
initializePin( 4, gain_ );
}

void AGain::onSetPins(void)
{
// Choose which function is used to process audio.
SET_PROCESS2( &AGain::subProcess );
}

void AGain::subProcess( int sampleFrames )
{
// get parameter value.
float gain = gain_;

// get pointers to in/output buffers.
float* input1 = getBuffer(input1_);
float* input2 = getBuffer(input2_);
float* output1 = getBuffer(output1_);
float* output2 = getBuffer(output2_);

// Apply audio processing.
while( --sampleFrames >= 0 )
{
*output1++ = (*input1++) * gain;
*output2++ = (*input2++) * gain;
}
}

[hibrasil]

https://www.kvraudio.com/news/steinberg ... -end-41324

[MadBrain]

https://www.kvraudio.com/news/steinberg ... -end-41324

As long as Ableton doesn't implement VST3, Steinberg trying to end VST2 is wishful thinking.

[quikquak]

The only way to end it VST2 is to cut it from Cubase, and forget about their customers completely. Their marketing department must be having conniptions right now...

[Blue Cat Audio]

Had VST3 been truly successful, they would not have to struggle like this to get rid of VST2. It would have disappeared by itself.

[hibrasil]

NKS is also VST2 based

[quikquak]

Had VST3 been truly successful, they would not have to struggle like this to get rid of VST2. It would have disappeared by itself.

What we really needed was incremental upgrades over time, that were introduced through Cubase et al, so we could see the advantages of the changes.

But no, an over-engineered nightmare is what arrived.

[Ivan_C]

Quick question for the developers who are not using JUCE : are you still the using the "old good one" VST 2.4 SDK for developing VST2 plug-ins ? Or the VST3 SDK wrapper for VST2 ?

I saw a few old topics there with claims about broken things on the VST3 to VST2 wrapper, with automation not working properly, and I'm wondering if these issues are still there or not...