Revisiting VST 3


#41

Progress update. The end of last week and early this week have been fairly hectic chasing down a couple of issues. There’s still one outstanding which I’m looking into, but in the meantime I’ve been reworking the handling of VST 3 parameters:

For a little background, VST 3 hosts have a lot more responsibility with regard to parameters than with VST 2. For VST 2 plugins, the host treats the plugin as single entity and parameters are just passed to it, and that’s it.

VST 3 plugins however are separated into two parts: the processor and the editor and all communications between the two parts go through the host. Technically not all plugins do this, but definitely the host needs to support plugins that depend on the host for this communication.

This functionality in Cantabile was written quite a while ago, but wasn’t working correctly with a couple of plugins. After some discussion on the VST dev forum, debugging a sample plugin in Cubase and discussions with a couple of plugin devs I revisited all this with a fresh understanding and those plugins are now all working perfectly.

That was this morning… and then took the afternoon off.


#42

Some more progress: besides more testing I’ve now implemented the restartComponent() API that a plugin can call to indicate that information about the plugin has changed (number of inputs/outputs, parameters etc…)

I still need to find some plugins that use some of these features for testing, but from what I’ve seen so far it seems to be working, even using soft ramp down/up while suspending and resuming the plugin for some changes.

There’s also still some questions about how audio and MIDI ports map to plugins with changing number of inputs/outputs… that’s tomorrow’s job.

After that, the only real thing left to do is the ability upgrade existing VST 2 plugins to VST 3, review all the interfaces again to check for anything that might be missing and then a whole bunch of testing.

Back on the master branch all those menu bar/full screen mode changes seem to be stable now which is a relief and took some serious detective work.

(Actually on the full screen mode there is one outstanding issue when in full screen, with opengl enabled and the menu bar hidden where some display drivers go into this weird display mode. I’m in discussion with a dev at Microsoft about it, but in the meantime there’s an easy work around - just turn off OpenGL rendering).


#43

I’ve not posted about this for a while because I’ve basically been bogged down in a whole lot of tedious work. Lets just say it’s getting there…

Brad


#44

OK, VST 3 support is done!

The build is ready to go, but I’ve learned the hard way not to release things on Friday arvo. Assuming no hiccups after some more testing, stay tuned for early access release Monday sometime. :slight_smile:


#45

Cor, haven’t heard the phrase “arvo” since I was down under for two months. :wink:

Sounds great. Look forward to it, and I can see about rationalising my plugins. :slight_smile:


#46

Great news! Suddenly my number of available plug-ins will grow!


#47

Congratulations! And thanks for all your hard work on this


#48

Now that you’ve been through it I’d be interested to know how you feel about VST3 - good/bad?


#49

Available now, see here: https://blog.cantabilesoftware.com/vst-3-support/


#50

Don’t tell me my inner Aussie is shining through. :slight_smile:

Overall I think I have to say it’s better that VST 2, but I can totally understand why some devs might baulk at it. It’s very based on the COM interface model (IUknown, queryInterface, addref, release etc…) which is a big leap from a straight C interface. Personally I’m very familiar with all this as I’ve done tons of COM programming. In a previous job I was even once tasked with training new devs on COM programming and ran a two day course on it.

In any case there’s still something it that bothers me, but I can’t quite put my finger on it. It might just be a documentation thing - certainly the docs could be improved and might even just be a German/English thing.

One thing I will say though: Steinberg has got much better in answering questions and explaining things with their developer forum and that’s made a world of difference.


#51

Tx @brad !!! Much appreciated! Do you have any view on how well VST3 these days does Midi effects?


#52

Given a plugin that’s available as VST2 and VST3, assuming it’s equally stable and works properly in both configurations, are there any advantages one way or the other, as to which would be best to use?

Neil


#53

Hi, Neil

Not sure, but I thought VST3 plugins only consumed CPU horse power when they are actively doing something? I thought that was the main advantage anyway?


#54

Too early for me to say. There was a post on one of the other VST 3 threads that indicated CPU might be a little higher with VST 3 but I haven’t looked into it yet. Also there’s still a few places I can improve VST 3 performance which haven’t been done yet.

Brad


#55

Not well. Cantabile will do some outgoing event to MIDI mapping for VST 3 plugins but there’s limits to what can be generated in that way.


#56

OK, I’ll play with the VST3 versions of the plugins I developing and we’ll see how far we get …


#57

Yes, you’ve got my interest also, need to examine what benefits it will have… :slight_smile:


#58

The benefits are almost irrelevant. At some point VST2 will die and we will all have to move on. By that time there may be a VST4!


#59

Even though things in general do move on, I hope that Brad will keep VST2 support in Cantabile.

For example, I have a very good Moog Taurus 32 bit VST2 plugin that seems to be no longer in development, but sounds great. I doubt that will move on from VST2/32 bit, but it works in both Cubase and Cantabile via JBridge.


#60

Yeah i keep on being hooked to synth1 at 32bit over jbridge. It has some flaws but also that nice warm detune at release decay. Mmmmm. Although I’m looking for a modern replacement. But couldn’t find any. Ideas?