As I understand it the problem is that with VST 3, the host doesn’t pass MIDI data directly to plugins. Rather they’re converted to “VST 3 Events” and so the plugin can’t “learn” MIDI event bindings. I believe the VST 3 spec has (or will be) updated to provide a solution for this but I haven’t looked into it yet, and I don’t know Steinberg, nor u-he, nor anyone else for that matter has updated their software to make use of it.
This won’t impact Cantabile quite so much because you can already create MIDI bindings directly to a plugin parameters so at least there’s that as a work around.
The more I look at it, the more I realize that the preset management in VST 3 is a totally mixed bag. Different approaches by different plugins, different things supported by hosts, different models declared as possible by the SDK and associated docs.
For most DAWs this isn’t too big a deal… the plugin is configured by the user and that’s it. In Cantabile however where the user might want to switch presets on a state by state basis the behaviour of presets needs to be more deterministic.
One idea I had was to simply make all VST 3 plugins use pseudo presets (ie: a custom bank of presets where each is preset is a snap shot of the entire plugin state). This however could cause problems with slow loading plugins and plugins where the preset model actually works as expected.
This also crosses paths another an idea I had for lightweight presets where just the automation parameters are captured in each preset.
So I’m going to set VST 3 work aside for bit, take a look at adding support for different preset models and then return here once Cantabile is better equipped to handle VST 3’s preset handling.
Thanks for the attention to this. I realize this is quite a hurdle for C3, and the extra time to get it right is understood. As I said in another thread, Blue Cat works perfectly in C3, and loading a VST3 thru BC is quick and with very little rise in CPU load. So, for now, VST3s are working well in C3 for me.
From my experience, there is no downside. It has been perfectly stable, and the CPU load is basically unnoticeable before adding any plugs. C3 handles it very well, no glitches at all. Yes, there is the expense, but I’ve used Patchwork for several years now, and I don’t regret the purchase. Just the mixing abilities alone was worth what I paid. When I finally incorporated it into C3, I was pleasantly surprised at the stability.
Since the arrival of VST3 plugs, I used it to load them into C3, and it is flawless.
I started using the BC free amp sims, and they are as good as any on the market. I am now using BC Axiom and Destructor for some live guitar work. I am in awe of the newest TH-U sims (compared to TH3), so I decided to use BC Re-Guitar in front of my chain to use modeled pickups, into TH-U. My Strat has now become a Les Paul. The BC12-string sim, when tweaked, is amazing, and I use it live in a couple of Byrds tunes.
There are many other possibilities with this plug I will not rant about. I am still discovering.
I believe all their products can be demo’d, so try it before you drop a dime, and see what you think.
Now that preset models are pretty much done today I’m returning to work on VST 3.
Since the first thing I had to do was reconfigure my VST path, I decided it was time the plugin options page got a couple of tweaks.
The plugin path is now a list instead of semicolon separated text field
You can clear the check mark next to a path to disable it without actually removing it (eg: in the screen shot I’ve disabled all the VST 2 paths so I can focus on VST 3 work)
Associated add, remove, move up/down buttons
Two new checkboxes to include standard plugin locations - so you won’t need to add these locations to the list.
Great! I personally do not need the two checkboxes for “standard” folders. That make things more difficult I think. Not sure what “standard” means. I guess you mean the Steinberg folder…
Well, there is a registry setting for the VST2 plugin path (HKEY_LOCAL_MACHINE\SOFTWARE\VST - “VSTPluginsPath”, a String value). Some installers actually respect it, which makes life easier at times, others completely ignore it…
@brad: is this the “standard location” you mean with this check box?
And here we already have the confusion I was talking about. I’d prefer to add my locations into the list manually even if there might be a standard folder for those plugins.
Not many of the VST 3s that I’ve installed give me an option on where to put them. For a long time I didn’t know where they were. I like the checkbox for default locations so I don’t have to hunt it down.
Yes, but with a fallback to some common known locations.
Thinking about this some more I might remove those two “standard” checkboxes and replace them with default entries in the list that the user can then remove if they’re not interested in them. That way you can at least see what they are.
I spent today mostly debugging through the semantics of how Cubase calls VST 3 plugins with the rationale being that if I mirror it as closely as possible that should provide the best compatibility with the plugins that are out there.
The main changes this resulted it is that I’ve pretty much rewritten the way parameters are handled in the VST 3 hosting - specifically how they’re passed between the controller and the processor parts of the plugin.
The side effect of all that is that a bunch of plugins that were crashing before, no longer do
Tomorrow:
more testing of basic VST 3 hosting, saving and loading plugins
testing VST 3 hosting in combination with the new preset model work
writing the code to pass timing information to VST 3 plugins.
More progress! The three points from the previous post are basically done and things seem to be working well.
The next big hurdle is going to be handling various restart requests from the plugins. VST 3 plugins support dynamically changing various things that are fixed in VST 2. eg: a VST 3 plugin change change it’s number of I/Os, the number of parameters, change the names of parameters etc.
The I/O changes and parameter names changes should be reasonably easy to handle. Changes to the number and types of parameters is a little more tricky. There are various places in Cantabile where parameter information is stored by index (eg: the morph parameter settings, parameter set preset models). If the number of parameters and/or the meaning of parameters at each position is changing then things are going to break.
I think the approach I need to take is to switch from using parameter indices to parameter Ids - and that will need to reflect through to everywhere parameters are used.
So next up to do is:
Change the API between Cantabile and CantabileCore to better encapsulate parameter details into a more formal structure and do so in a way such that any existing code that uses parameters will fail to build.
Include a notification in that API to indicate that the parameter set has changed (and invoke it when a plugin says things have changed).
Review and fix all the deliberately induced build errors so I can be sure that every piece of code that deals with parameters has been updated.
Make sure everything that needs to respond to changing parameter sets does.
Find at least one plugin that makes use of all the above and test it.
Step 5 is actually the biggest unknown with all of this: finding plugins that use the various features of VST 3 so I can test things. I’ve posted a question to the VST 3 developer forum hoping to find some good plugins for testing this and other aspects of VST 3.
@brad (and others) - do you know of any VST3 plugins that take midi in and that generate midi out? VST3 (at least the original spec) did not allow that, and development tools like Juce (currently) do not support it. So I’m wondering to what extent Cantabile will support it. I have such plugins but since Juce does not support mini/in out for VST3 there’s little point I guess in trying these? But FWIW @brad, if interested I can shove you a VST3 version of my plugins to test if you want; I’m going to guess Cantabile will not see midi in on 'em (and possibly not even midi out)… but if you wanna give them a shot we can do that.
