Articles | Full Index | RSS Feed
A few posts ago I hinted that I might be working on a VST version of Cantabile. This is probably the most asked for feature since the very first version of Cantabile - and yes I'm actually working on it. It's a big job, but I'm making steady progress.
In order to keep the final size of Cantabile down, I decided to move all the code from the Cantabile executable into a DLL and write a small EXE stub launch it.
When running as a plugin, this same DLL exports the required entry points to be loadable by a VST host.
This work has all been done and Cantabile as a host now works as before - except it's in a new DLL home.
The plugin and host versions of Cantabile need to be able to save their own separate sets of settings.
Importantly this needs to work when Cantabile is self hosting itself, so all the previously global functions to save and load settings needed to be updated to work with the settings for the appropriate running environment. In other words every piece of code that saves or loads settings (and there's many) needed to be updated.
By this I mean the structures that surround the Cantabile engine in order to provide the VST interface to other hosts.
This was all fairly straight-forward and simply fires up an instance of the Cantabile audio engine for each instance of the plugin. I'd already done alot of preparation work for this during the development of Cantabile 2.0 - making sure that multiple instances of the engine could run in parallel.
One of the nuances of the VST spec is that although there is a concept of a audio block size, a plugin may be asked to render audio for a smaller buffer. For example, it's perfectly valid for a VST host to specify a buffer size of 512 , but then ask the plugin to render only 128 samples.
Many hosts never do this, but there are some that do so Cantabile VST needs to be able to support this. As such I've updated the entire audio processing pipeline to handle these partial buffers.
I think this area is complete, but as yet untested.
Cantabile's has a concept of an audio driver that drives the real-time aspect of the audio engine.
For the host version of Cantabile this is typically code that wraps either an ASIO or DirectSound driver. When running as a plugin, there isn't a real audio driver and instead the engine is driven by incoming calls from the host.
The VST framework that I mentioned above implements the same API as Cantabile's other audio driver wrappers, making its integration with the engine fairly clean.
So far this supports a simple stereo in/out pair running in 32-bit audio. 64-bit audio support will be added later, once I get the basics up and running.
The plugin scan procedure now automatically includes the folder containing the Cantabile DLL. This is so the VST version of Cantabile is always automatically available as a plugin.
A nice side effect of this is that you can now drop any plugin into the Cantabile program folder and it too will be automatically discovered.
Nothing - yet.
Well, Cantabile VST appears in the list of available plugins, but explodes if I actually load it. This is because there's not yet a session loaded or created... and that's what I'll be attacking next.
Posted on May 13, 2010
Karl says:
Great news!
Good luck with this ambitious project. As far as I'm concerned this really is the most wanted feature. Awaiting results ^_^
James Gross says:
Brad,
I have searched all kinds of vsts for a piano roll for Cantabile Solo; but nothing seemed to match Orion's Piano roll :) so this direction will be a "no-brainer" re-purchase for me :)
Regards, James
Tom says:
Dear Sirs: It appears that many more sounds can be set up and played simultaneously than in Sonar for instance. No cracking at all although I have gone overboard and purposely tried to overload it. That's why people want to carry it right into their software workstations. How do you do it? Why can Cantabile process so much? Sincerely, Thomas Wuorio