Currently, most audio plugins are instantiated in insert or send slots. They process audio at a given point and route that audio in a linear fashion. You plug them in and use DAW routing to achieve more sophisticated processing configurations, such as sidechaining and parallel processing.
In the last few years, a number of plugin developers have released plugins where communication between various instances of a plugin in a project is crucial to the operation of the plugin. Here are some examples:
…
Track Adjustments in Mix Context
iZotope Neutron is an excellent example of this new plugin concept. Instead of a plugin operating in isolation, each instance of the Neutron plugin in a project becomes part of a network of instances that communicate with each other. Neutron offers a Tonal Balance Control which provides visual feedback on how a track fits into the mix context, helping a user make mixing decisions.
Console Modeling
Slate Digital produces the Virtual Console Collection (VCC), which can add console flavor to each DAW channel and the overall mix. An instance of the Virtual Mix Rack (VMR) plugin set with VCC in channel mode is applied to each track in a project; and an instance of the VMR plugin set with VCC in buss mode is aplied to the the mix buss. The plugins communicate in a network, which helps with making changes to plugin parameters across the “board.”
Brainworx produces the E, G and N versions of their bx_console series. “Tolerance Modeling Technology” helps ensure each virtual console channel has slight differences (per a variety of console hardware component manufacturing tolerances) that would occur in real hardware.
Phase Correction
SoundRadix Pi is a tool which dynamically rotates the phase of individual mixer channels to achieve phase correlation within the mix. The user must apply an instance of the plugin to each mixer channel. The instances communicate in a network to calculate the necessary phase shifts.
Autogain/AutoLevel
Numerous products are available (TB Pro Audio Gain Rider and DynaRide; HoRNet AutoGain Pro; Melda MAutoVolume) which provide automated adjustment of a target track’s signal amplitude based on relative loudness (or other measurements) as compared to other tracks.
…
These are just a few applications of the basic idea that plugin instances communicating with one another can provide game-changing functionality.
However, currently there are downsides:
-
Manageability: The user must manually set up the plugin instances required in a project. If a project has 100 channels, the user must manually (or using DAW configuration automation) instantiate a console emulation plugin in 100 slots. Depending on how robust the features of the instance network are, making changes to these plugin instances once instantiated may be tedious.
-
Hardware resource use: Because numerous instances of each plugin must be instantiated, there is an inherent hardware cost to this implementation. Depending on plugin architecture and computer hardware, FLS may also be an issue.
There is a more efficient, manageable approach which could be integrated into Cubase.
Imagine a new plugin type (not an insert or send) which operates at a higher level in the DAW, able to touch various tracks from one instance. Let’s call it “interVST” for now. It’s an entirely new type of plugin - you could not apply an interVST plugin to an insert or send slot, nor would you set an interVST at the track level. (However, Steinberg could integrate interVST into Cubase such that a traditional VST plugin could be used in an interVST slot. Cubase would then need to provide basic extensibility for the traditional VST plugin to take advantage of interVST features.)
Instead of applying such plugins to each individual track, you would work with an interVST panel and instantiate interVST plugins in slots in this panel. Let’s take a virtual console concept like Slate Digital’s Virtual Console Collection, for example. Once instantiated, the Slate VCC interVST would be provided with information about all routing points (inserts, sends, inputs, outputs, busses, etc.) in the current project, plus in the DAW environment (control room, connected hardware, etc.). To apply the console effect, the user could simply instantiate it and the plugin could take care of track/bus setup automatically. Alternatively, the user could configure exactly where the effect should be applied (which channels, at which routing points). In this case, the interVST interface would allow the user to quickly select tracks 1-42 and apply the effect to insert slot 1 for each track.
With gain rider / autolevel plugins, the user could quickly choose which tracks should affect the levels of which other tracks. A user could instantiate a single multiprocessing autolevel interVST plugin to handle multiple tracks’ auto-leveling in one instance.
Effectively, a single interVST plugin instance could be set up to process any number of inputs, outputs, insert slots, send slots, etc. simultaneously. The user would be able to quickly select from all available routing points. A robust interVST specification would help plugin developers architect plugins that could take maximal advantage of this routing flexibility.
You may object, “This already exists. It’s called using sends.” But there is a key difference: Sends simply process whatever is sent to them. The new interVST plugin type would retain granular detail on what is happening at any point where it is connected. If it’s configured to process 100 channels’ first insert slot, it can then calculate the phase shift needed, or the console emulation needed, etc. based upon each individual channel’s signal at that routing point.
PreSonus Studio One has a CTC 1 Pro Console Shaper mix engine plugin which is a good step down this path. Its implementation as a “mix engine effect” - a new category of effect different from inserts and sends - means it it can be automatically applied to all channels in a Studio One project, with variances applied automatically to each channel.
But instead of a DAW-specific “mix engine” plugin type, Steinberg could extend VST3 to include this new interVST type of plugin, which any DAW could use. Plugin developers could then leverage this new functionality to refactor and enhance existing network-based plugins like the ones listed above, and to develop an assortment of new plugins based on these capabilities.