/ Topics / VST3 Plugins

Overview

The Takeaways

Fiddle currently supports a single audio plugin format, VST3. Plugins must be compiled for the same 64 bit machine architecture as ChucK, meaning no rosetta modes are advised.

The world of audio plugins is a confusing one. There is a lot of confusing discussion online regarding the different APIs, plugins and plugin-shims. Added to this, most audio fiddlers have non-trivial investment in a collection of their favorite plugins, some of which are no longer updated or distributed by their creators. Finally, combine this with the fact that mature DAWs (Ableton, Cubase, etc) have an obligation to their customers to support legacy plugin formats and machine architectures. At the end of the day you'll not find an answer to the burning question, What is the best audio plugin format?

We have adopted VST3 for Fiddle because

• we had to pick one format
• VST2 is now firmly deprecated by Steinberg.
• VST3 is supported across the three major operating systems and the most popular machine architectures.
• there appear to be an ample supply of VST3 plugins.
• Fiddle is a plugin host and so our goal is to invite others to the party, rather than be able to be invited to everyone's party.

And we are keeping things simple by

• only supporting 64-bit plugins on the native machine architecture
  • if you are on an M1 (arm64) you can't / shouldn't use x86-64 plugins.
  • if you are on x86-64 you can't shouldn't use x86-32 plugins.
• only supporting 32-bit audio processing

VST3 in Fiddle and ChucK

VST3 plugins, when successfully loaded, will appear in the Graph Editor's node menus, typically piano (Instruments) and graphic_eq (Filters). As with all Fiddle nodes you simply instantiate the node and wire it into your graph.

But before any plugins appear you must request Fiddle to scan for them using the command found in the folder_open (File) menu.

Remember this: we don't auto-scan for new plugins unless you request this operation. Whenever you add new plugins to your system you must re-issue this request before they'll appear in your system. Even then, your plugins may only appear when a new graph-editor session is initiated.

The results of a plugin-scan is a dump of updated .yaml files in the fiddleExtensions directory of your current workspace. So we employ the same mechanism for loading VST3 plugins as we do for chuck-native plugins as described, elsewhere.

Here's a log of a typical plugin scan:

You are welcome to manually edit the resulting .yaml files. For example, you can add parameter descriptions or tweak other aspects of the UI. If you do so, please be aware that the next time you scan for plugins that work may be unceremoniously overwritten.

Loading and Running

So here's where the fun begins. Once you've figured out how to load your favorite plugins, just instantiate their nodes and wire-away. In this example, you can see that we've wired a MIDI-driven square wave instrument into the TAL Vocoder's left channel. And into its right channel we've wired a vocal recording (here, a sample from a speech by US President Obama).

Most VST3 plugins come with fancy-pants graphical user interfaces. In the context of Fiddle this is an interesting challenge as detailed below. You'll notice in the node-inspector for your plugin a new button, VST3 UI….

Pressing the button will either alert you to the fact that your plugin has no UI support or will present the plugin UI in a VST3 Inspector window like this:

Now you'll notice that parameter changes that you make in this UI will produce updated values in Fiddle's node inspector. You may also notice some discrepancies (yeah, we're working on it). To wit: only values that you change via the UI are reflected in Fiddle. If your plugin offers preset menus, then all values that are changed by the preset should wend their way into Fiddle's brains. Valhalla's Supermassive is a good example of this behavior.

Once you find a good collection of settings in a Fiddle session, saving your Fiddle Graph Editor file (.chg), will include all the non-default plugin parameter values. Thus you can re-produce your performance without requiring the plugin UI.

Behind the Curtains

Knowing what happens behind the curtains is not necessary to achieve success with your VST3 plugins. Well at least not until it is. There are more plugins that we can test, evaluate and debug (let alone pay for). The processing architecture of Fiddle + ChucK is unusual and so plugins that operate perfectly in the context of Ableton, Reaper, etc, may not work at all in Fiddle + ChucK. We've found this to be the case with Spitfire's LABS, for example (and we're working on this, fwiw).

Here's a diagram of the operating components at play in VST3 operation:

Things to focus on:

• VST plugins are loaded into ChucK and the VST3Fiddler, but not Fiddle.
• Parameter changes during a Live ChucK session wend their way from VST3Fiddler to Fiddle and then to ChucK.
• During a non-interactive ChucK session, parameter changes are triggered procedurally in your network. And VST3Fiddler is never loaded. In other words, ChucK cannot host a VST3 because it is a server-like (console) application.

Caveat Emptor

As indicated above, the fact that Fiddle is an unusual VST3 hosting architecture means that some plugins simply may not work. We'll attempt to address issues as they arise, but resources are limited.

Known Issues

• Currently our channel + bus configuration is limited to stereo-in and stereo out.
• LABS VST3 plugin doesn't produce sound, perhaps something to do with licensing?
• Synchronizing state via parameter-edits with TAL-Vocoder-2 isn't fully functional and thus confusing.
• Performance is constrained by ChucK's unique architecture.

See Also

Steinberg VST3 Online
Source for DbVST3

The Fine Print

VST® is a trademark of Steinberg Media Technologies GmbH,
registered in Europe and other countries.