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.
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).
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.
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.
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?
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?
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.
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.
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?
