Mac users, help me make a list of best plugin version to use -- AU or VST, by developer/plugin

[billcarroll]

Here is an email exchange with Dave of DMG Audio. In my opinion Dave/DMG Audio makes some of the best plugins on the market, and I'm not surprised that his plugins would be stable in AU and VST format.

First email to/from Dave

Hi,


On 9 Jul 2012, at 19:18, Bill wrote:

I'm checking with all of the plugin devs for the plugins I own and use so I can determine the most stable versions of plugins to use.

Ok.

I'm specifically trying to find out if plugins are created as AUs, or if the AUs are just wrapped VSTs of some sort.

Mine are somewhere between the two. The plugin itself is developed roughly as a vst but has a bunch more code that the vst host will ignore (mostly parameter stuff), which the au version then provides access to. All versions share as much code as possible.

There's no real distinction between the two cases, to be honest.

Cheers,

Dave.

The second email exchange

On 9 Jul 2012, at 22:19, Bill wrote:

Dave,

Heya,

Thanks for your reply. From what you're saying it seems AU and VST should be same as far as stability, features and performance?

Is it OK for me to share this info on KVR? I'm making a list and trying to sort which plugins should be used as AU and which are best when used as VST.

I ought to be more specific before things get posted:

1. Performance
Unless something is extremely awkwardly implemented, the performance difference between AU and VST plugins ought to be entirely negligible. Certainly not something you'd be able to measure without a profiler.

2. Stability
AU provides more features, hence there needs to be more code to implement these features. Typically this isn't a great quantity of code when compared to the implementation of the plugin itself.
There certainly can be bugs in the AU code, and there's certainly less code needed to implement a VST than an AU, but bugs are more often a consequence of unusual spec interpretations on the part of the DAW.

3. Features
AU provides more features - sidechain support and humanised parameter ranges, most notably. VST2 has no standardised support for these features.

Cheers!

Dave.

[audiospillage]

AudioSpillage = AU

[billcarroll]

And a great reply from Andy of Cytomic:

Hi Bill,

Now please don't get your knickers in a twist when it comes to "wrappers". Did you know that the fastest method, in the sense of cpu usage, of implementing an AU is actually using the VST to AU "wrapper" C++ class called Symbiosis by NuEdge / SonicCharge? This is actually faster than using the "wrapper" provided by Apple. Both the Apple official base classes and the Symbiosis single class interface to the underlying AU specification, but the Apple one is very convoluted with layers of abstractions that slow things down, and the Symbiosis one is flat so it quicker.

The AU and VST 2.x formats are quite similar. I use the AU version when on Mac since it supports text to value and value to text conversions which is handy for entering values in Live's rack view, but otherwise it really doesn't matter as it is the same code underneath. I actually "wrap" AU, VST, RTAS and AAX to another interface I use internally, and then have a standard class to handle all things consistently, only the skin, parameter handling, and dsp differs for my plugins, everything else is identical, so all bug fixes to the "framework" apply to all my plugins.

That's about all I have time for, so I'll have to leave it to you to post to the thread since I don't want to disappoint people if they ask questions since I'm flat out on The Drop!

All the best,

Andy
--
cytomic - sound music software

I'm going to give the edge here to the AU since it's what he said he'd use.

Might be hard to untwist my knickers though because I'm so edited for The Drop to Drop!!! How'd he know I like to wear women's underwear?

[Angus_FX]

Hi Bill,

I notice fxpansion sells the "VST to AU Adapter v2.0" and based on this I'm guessing their AUs are wrapped VSTs. I've asked fxpansion directly but have not gotten an answer.

AFAIK our plug-ins support everything you'd expect them to from the AU spec.. there is some VST-ish code running in there but it's not "VST to AU Adapter" and it's a tiny % of a large code base. There is no impact on performance.. technically there's a sort of VST-plus layer (looks very much like VST, so runs crossplatform, but also supports the extensions needed by AU, RTAS and others), and then an internal layer within that to separate our main program code from any 3rd party format concerns.

The other thing you need to bear in mind when compiling such a list, is that most, if not all, hosts have built-in wrappers as well (again, to separate their program code from 3rd party format concerns, and to allow easy support of multiple formats), and the efficiency/stability may depend on whether the host has a better implementation of VST or AU. Indeed, the only host I've seen that *doesn't* look like that is some versions of Cubase where the whole audio engine is VST (I've no idea if this is true or not nowadays, this is going back quite a few years).

IOW, if a host's (native->VST) support is poor, it may be better to use an AU-wrapped VST and the host's (native->AU) hosting. So the optimal choice depends on the host as well as the plug-in, but the best answer is that it doesn't matter in the slightest unless you run in to a specific problem such as people have described above.. all of which are down to idiosyncracies of particular plug-ins or hosts and have little or nothing to do with wrapped code per se.

[billcarroll]

Hi Bill,

I notice fxpansion sells the "VST to AU Adapter v2.0" and based on this I'm guessing their AUs are wrapped VSTs. I've asked fxpansion directly but have not gotten an answer.

AFAIK our plug-ins support everything you'd expect them to from the AU spec.. there is some VST-ish code running in there but it's not "VST to AU Adapter" and it's a tiny % of a large code base. There is no impact on performance.. technically there's a sort of VST-plus layer (looks very much like VST, so runs crossplatform, but also supports the extensions needed by AU, RTAS and others), and then an internal layer within that to separate our main program code from any 3rd party format concerns.

The other thing you need to bear in mind when compiling such a list, is that most, if not all, hosts have built-in wrappers as well (again, to separate their program code from 3rd party format concerns, and to allow easy support of multiple formats), and the efficiency/stability may depend on whether the host has a better implementation of VST or AU. Indeed, the only host I've seen that *doesn't* look like that is some versions of Cubase where the whole audio engine is VST (I've no idea if this is true or not nowadays, this is going back quite a few years).

IOW, if a host's (native->VST) support is poor, it may be better to use an AU-wrapped VST and the host's (native->AU) hosting. So the optimal choice depends on the host as well as the plug-in, but the best answer is that it doesn't matter in the slightest unless you run in to a specific problem such as people have described above.. all of which are down to idiosyncracies of particular plug-ins or hosts and have little or nothing to do with wrapped code per se.

Angus, thanks for taking the time to drop by with some helpful direct experience and knowledge on this topic. I've never experienced a single stability issue with fxpansion plugins, and I have and use more than a few of them. I use at least one if not more fxpansion plugins on every project now.

I'm usually in Ableton Live now, but occasionally in Logic as well. I've been using AU versions of all plugins for a while now. It strange how VST plugins show up in Ableton if you select VST as a preference, but they are not organized in groups like the AUs are. I wish I knew more about how different host implement plugin support.

Based on your comments my attempt at a list really seems inadequate for most plugins. I guess it could be broken down by host. An exception would be for the Audio Damage plugins, since the developer strongly recommends using the VST over the AU.

[taoyoyo]

I know Native instruments always recommends using the VSTs of their own products, though I think this is more within their own hosts (i.e.: Maschine and Kore).

[Oxalis]

Juce is great for developing a cross-platform plug-in but the differences in the VST / AU protocols creates constraints that ultimately affects also the Juce framework.