In our community forum and on our Facebook group we often see people asking which plugin format is better to use, VST, VST3 or AU.
Gig Performer is an audio plugin host for live performance that hosts VST, VST3 and (Mac only) AudioUnit plugins.
.
So which plugin format is better?
.
TL;DR, the ultimate answer is: it depends. It’s best to try different plugin formats yourself and check the documentation of that plugin to check it has all the functionality you need.
.
Theory vs Practice
.
Most developers use cross-platform libraries such as JUCE and so the code created by the developer for each format plugin is the same. So, in theory, it doesn’t matter if you compiled it to be VST, VST3 or AU, right?
In practice, it depends on how they are implemented. One format might work better than another.
We’re often reminded of the great quote by Yogi Berra: “In theory, there’s no difference between theory and practice. In practice, there is!”
So, in this article, we’ll highlight some of the differences and considerations that we noted from our own experience and from the experiences shared by our community members in the forums.
.
Cross-platform usage
.
First, we must mention the cross-platform consideration. Gig Performer can run on Windows and on macOS.
If you want your gig files to work on both macOS and Windows, you must use the VST or VST3 versions of your audio plugins, as you can’t use AudioUnits on Windows. Make sure you’re using the same version numbers as well.
Provided that you have the same version of the plugins installed on both platforms, Gig Performer project files (gig files) should open normally on both platforms. This is very convenient for users who plan to migrate from Windows computers to macOS computers or vice versa. You can also have a backup computer in another platform. In this case, you should use either VST or VST3 plugin formats. Also, do not use different versions of the same plugin.
Read this in-depth blog article to learn about cross-platform usage in Gig Performer.
.
Stability
.
Our personal experience is that VSTs are generally less buggy, probably because they’re tested against many more hosts than are AUs.
As for VST3 vs VST(2), our experience is (albeit anecdotal) that the older VST format still tends to be more reliable, perhaps because it has been available for a very long time. VST3 plugins are also more complicated to implement properly.
Individual examples of some issues that our users have reported in the past (though some of these may have been fixed by the time of this writing):
– IK Multimedia’s TR5 Opto Compressor VST3 plugin is “leaking” MIDI. (source)
– Certain iZotope VST3 plugins crash, while the VST version works properly. (source)
– Arturia FX2 works well as VST, but had problems with VST3 (the latest update fixed the issue in the VST3 version of the plugin)
A counter-example where a VST may be buggier:
– ADA Flanger VST doesn’t notify the host about parameter changes (source)
We always encourage our users to report bugs to the plugin developer. Needless to say, plugin developers are mostly interested in fixing the reported bugs ASAP. We keep track of some of those fixes in this thread.
.
Features
.
It can happen that using one plugin format brings more functionality or different behavior compared to another. For example, from the page 59 of the Helix Native Pilot’s Guide, you can find this (source):
Next example is the well-known and rather wonderful MIDI Guitar plugin. As mentioned in this blog article, the AU version of this plugin does not produce MIDI on the MIDI out channel. Instead, it creates a new virtual MIDI Output port and you will then need to create a corresponding MIDI In Block to receive MIDI from the plugin. Doable but rather extra unnecessary work. In short, for the MIDI Guitar plugin, prefer the VST version over the AU version.
Another example, unlike the AU version of H-Reverb, the VST3 version of H-Reverb does expose the reverb time to the host. (source)
.
Other considerations
.
Generally, if you install or update an Audio Unit plugin, you have to log out or possibly even reboot your computer before the updated AU becomes visible (source).
Don’t mix plugin formats from the same developer. Read this blog article to learn why.
If you don’t use a particular plugin format, using Gig Performer’s Plugin Manager you can hide all plugins in that format. Read this blog article to learn more.
In terms of architecture, the format doesn’t matter as long as the plugin is available for the platform natively. However, when the M1 was first released, Apple did something that we felt was a little bit unfair to third-party developers. Clearly, they knew that many third-party plugins would not be immediately available in Apple Silicon version so that if you ran the new Apple Silicon versions of Logic or MainStage, many of your plugins would be missing. So they arranged for Rosetta to run automatically if an Intel version of a plugin was loaded.
A very clever solution but they only did it for AU versions. If you were using the VST versions with your host (whether it was Gig Performer, Cubase, Ableton Live or any other non-Apple host), you would not have access to your Intel VST format plugins. This made it seem like other hosts, though compiled to run natively, were broken. Check out this blog article to learn more.
.
FAQ
.
Q: I’m a Mac user; Should I be using AU plugins, given it is Apple’s own format and maybe most capable?
A: Actually, that’s generally not the case. For a start, most plugins are developed using cross-platform libraries. JUCE is probably the best known example. It allows developers to build plugins on many platforms with little or no change. So, the underlying code-base is generally the same regardless of the format (VST, VST3, AU, AAX, etc). Just because AU was developed by Apple does not mean that it’s any better for Mac than other formats.
Q: I read that the VST3 format helps to improve overall performance by applying processing to plugins only when audio signals are present on their respective inputs. Is their performance really better compared to the older VST format?
A: A decently implemented VST2 plugin, when not generating any sound, should reduce its CPU usage almost completely. The thing one sees sometimes with poorly developed plugins is that they spawn off a bunch of threads that they just leave running and since those threads are not directly involved in audio, they suck up CPU cycles even when they’re not doing anything. In that situation, even if you put them on different rackspaces, they’ll still suck some cycles.
Most of the ones we use reduce their audio processing CPU to almost 0% when they’re not generating any audio. Examples are Kontakt, FM8, Pianoteq, Lounge Lizard, many of the Arturia plugins and so on.
We have also observed that effects plugins tend to continue using CPU cycles even when there is no more audio coming in or being generated. In the plugins we tried, that was true even for VST3 plugins.
Tip: you can always bypass a plugin, which completely disables its audio processing. For this purpose, you can try the Auto Bypass scriptlet or the Plugin Persist 2.0 scriptlet, which automatically bypass a plugin when it doesn’t generate any audio.
.
Conclusion
.
As we stated at the beginning of this article: It’s best to try plugin formats yourself and check the documentation of that plugin.
If you have any questions or want to share your feedback, please visit this Community thread.
Own the Stage® with Gig Performer®.
Nemanja Pudar
.
Related topics:
– Plugin fixes and updates
– Clever ways to optimize your plugin usage