Airwindows Consolidated: Free Mac/Windows/Linux CLAP/VST3/AU/LV2!

[ampetrosillo]

Does it use PurestGain?

Nope. It just multiplies if the control is set to attenuate or amplify. If you want other gain staging algorithms you can chain them in your daw of course!

I just pushed a small change which fixes a condition to make sure it does nothing at all when set at 0.00db, and i was careful to do the appropriate float or double math. But other than that it's straight amplitude multiply.

That's fine. PurestGain after all is essentially a simple multiply plus 64-bit dithering? Or something like that.

There is an argument for using the gain controls in Consolidated just like you would use PurestGain, in a sense.

[jinxtigr]

oops

[jinxtigr]

Does it use PurestGain?

Remember all PurestGain is, is a multiply with dithering to floating point. I continue to do that in 32-bit buss hosts, but don't even do it when running on a double precision buss (not even in PurestGain: if the buss is double precision that's enough). There's also some smoothing, especially in PurestFade. If Paul says he's not doing the multiply when it's not necessary that's good enough for me, and I assume if you're doing the pre/post trimming and are also on a 32-bit float buss, it is for a reason important enough that you can accept doing what is no more damaging than making an alteration on the fader or whatever else, outside the plugin.

IF you are on a double precision buss, and I'm assuming it's implemented with doubles on the double precision version of the trimmers which is easily seen in a bitscope, then yes it's effectively the same as having extra PurestGains tacked onto either side of the plugin.

I don't micromanage Consolidated, just keep up to speed with it (and give it pride of place as the first thing mentioned when a new plugin comes out). If you really want to go full tilt gonzo with my plugins you can always run the individual ones

[baconpaul]

I'm assuming it's implemented with doubles on the double precision version of the trimmers which is easily seen in a bitscope

It is.

The parameter itself (the db level) is a float but we convert it to a double before any processing and use all doubles when attenuating the double path (and all floats when attenuating the float path)

[jinxtigr]

I'm assuming it's implemented with doubles on the double precision version of the trimmers which is easily seen in a bitscope

It is.

The parameter itself (the db level) is a float but we convert it to a double before any processing and use all doubles when attenuating the double path (and all floats when attenuating the float path)

In that case I'm comfortable saying 'that is functionally equivalent to having PurestGains if you're on a double precision buss, and equivalent to using nothing more alarming than the simplest form of DAW trim or fader when on a float buss'. If ya want literal PurestGain in CoreAudio or whatever, then instantiate one instead even if Consolidated tried to implement the code that's in PurestGain for that, it would be applying it twice as that code is already on the output of any plugin that's running double precision internally (i.e. everything). And applying dithers twice isn't optimal, even if you'd call it correct.

I'm going to ask devoted airwindophiles to let it be that. This is for reaching out to the many additional users who want to use the stuff and not be hung up on all the deep lore. If the additional gain trim worries you, don't use it when you don't have to: Paul said it's 'out of circuit' unless actively working (it runs outside the buffer the plugin sees, to trim all the samples at once) and that's good enough for me. If you NEED to use it, then you can

[baconpaul]

Favorites

[audiojunkie]

Yay!!!

[audiojunkie]

This is the ULTIMATE "Swiss Army Knife" of effects!! So awesome!!!

[MTorn]

Perfect! Thanks!

One possible bug - when running it as a Mono -> Stereo AU in Logic, clicking the bypass button only forwards the dry signal in the left channel.

[baconpaul]

One possible bug - when running it as a Mono -> Stereo AU in Logic, clicking the bypass button only forwards the dry signal in the left channel.

oh i see why. i'll add an issue and try and fix before the wkend. thanks.

[baconpaul]

Perfect! Thanks!

One possible bug - when running it as a Mono -> Stereo AU in Logic, clicking the bypass button only forwards the dry signal in the left channel.

Just pushed a fix to this, new build in 30-45 mins

[MTorn]

Perfect! Thanks!

One possible bug - when running it as a Mono -> Stereo AU in Logic, clicking the bypass button only forwards the dry signal in the left channel.

Just pushed a fix to this, new build in 30-45 mins

Yep, that took care of it - thanks!

[woylie]

I was curious if there is a sonic difference in automation between Airwindows Consolidated (VST3/CLAP) and the stand-alone VST plugins, because I had read VST does not have “sample accurate automation”.

So I ran a test doing exactly the same 12db of volume automation across a song, using three different versions of Everytrim: Consolidated VST3, Consolidated CLAP and stand-alone VST. Then in Reaper I did a null test between each pair of the three, looking at the differences using Voxengo SPAN.

These were the differences:
VST vs CLAP – nulled deeply to noise below -150db (implying they are practically identical)
VST3 vs CLAP – nulled down to musical sounds below -100db
VST vs VST3 – nulled down to musical sounds below -100db

Which of these conclusions do you think I should draw:
a) VST3 is clearly different and possibly better because of “sample accurate automation”?
b) My methodology has flaws?
c) I’m in the weeds and these tiny differences don’t matter?
d) Other?

[jinxtigr]

Which of these conclusions do you think I should draw:
a) VST3 is clearly different and possibly better because of “sample accurate automation”?
b) My methodology has flaws?
c) I’m in the weeds and these tiny differences don’t matter?
d) Other?

I think 'other'. I don't have any plugins where they're coded to make use of automation points being set mid-processing-buffer. Every one either applies a parameter across the buffer globally, or interpolates (often linearly) between the beginning and the end of the buffer. For some of them (like XYZ filters) I have separate versions for each behavior, because the smoothing helps filter sweeping but neuro-DnB producers wanted zipper noise back…

It's the same plugin processing from the same code, each time. If you're going to fuss over these details I would be less concerned with sample accurate automation, and more interested in running a DAW with a double precision buss, because I think that's more important to the sound. There's no shame in being in the weeds so long as you can shake it off and do the regular part of the music work too

[baconpaul]

Surge implements sample accurate automation in the clap

Airwindows consolidated does the same in the clap inasmuch as it splits blocks for intermediate automation points (or it should! I thought I turned that on). By and large the underlying airwindows code assumes Param at start indeed but the clap block splitting would mimic sample accurate

You didn’t mention which daw you are using though. Bitwig sends automation every 64 samples so if you have a 64 sample (or 128 sample) buffer you won’t hear the difference. A good test is to automate a parameter then set your buffer size very large (like 2048). And ideally automate something pitch like like the synth in pitch nasty. At that point the clap should sound different than the vst3 of consolidated and the direct from Chris in bitwig and reaper.

Of course it’s entirely possible I forgot to turn on the clap block splitting! In that case the null result is what you will get. And then I’ll fix that when I’m back from vaca