Airwindows BitShiftPan: Free Mac/Windows/Linux/Pi AU/VST/Rack

[jinxtigr]

TL;DW: BitShiftPan gives you a gain and a pan control that are ONLY done using bit shifts.

BitShiftPan.zip(483k)

This is a request from YouTube comments, but I had no idea how well it'd work out! BitShiftGain is a long-standing secret weapon of mine. On almost every video, I'm losslessly dropping 6dB using BitShiftGain. But what would you get if you applied this to pan?

You'd get a pan where center was quite a bit louder than sides (there's no 3 dB pan law from bit shifts), but the first steps to left and right are QUITE a lot to the side. It's not at all LCR panning, but if something's center you know it, and if something's to the side it's WAY to the side. Then, you have a succession of further-to-the-side positions that are progressively quieter, all the way to hard L and R. If that was all it was, this would seem really pointless and arbitrary.

BUT.

If you can construct a mix this way, you can construct a mix where every single gain setting, every pan position, every location in the mix, is Bit Shift Gain: utterly and completely lossless. No requantization, just like with BitShiftGain itself, but in full stereo (within these constraints). You're picking locations, but they're not LCR locations, they're a range of potential locations.

There's more. Mixing with BitShiftGain in mono is impossibly crude. 6dB increments are seemingly impossible to mix with, absurd, insulting to even consider. But if you tick a track one step over to the side… that's now 3dB down, not 6. You've losslessly cut one side 6dB while leaving the other one unaltered.

If you had two tracks, a doubletrack, and did this with just one of them, your 'track' (that's really two tracks) can shift 1.5 dB down, to the ear. Starting to sound more interesting? If you had four tracks and shifted just one of them, that's an apparent shift of 0.75 dB.

Mixing isn't just about taking a single track and making it perfect. Mixing is how tracks sit relative to other tracks. If you have a full mix, and a track 40 dB down steps closer to the center bringing it up 3 dB in total, that makes all the other tracks seem just a tiny bit quieter in contrast. At every step, your ability to fiddle with 0.1dB adjustments is completely hobbled… but the framing of the TOTAL mix can take a whole new form.

And at every point, across every track, at every position in the stereo field, the mantissa of every audio sample is EXACTLY as captured by the converter. Once it's mixed, you'll get a composite, but everything being fed to the mix buss at every level in every position is exactly the raw sample… scaled to fit.

If you liked BitShiftGain for its utterly uncompromising transparency, beyond anything else even possible… now you have it, but with panning.

If this approach, so ruthless in the desire to hang on to raw unprocessed intensity from the original digital captures, seems interesting… next week is Console Zero, built from the ground up to work using almost entirely bit shifts even inside the saturation/antisaturation calculations and anti-alias filtering. BitShiftPan is an ultimately clean gain trim, and apart from the 'steppy' positioning and lack of pan law, it's very normal and approachable. Console Zero… is radical.

Thanks for the suggestion to try applying this to panning. Who knew so much would happen as a result?

download 64 Bit Windows VSTs.zip
download Signed M1/Intel Mac AUs.dmg
download Signed M1/Intel Mac VSTs.dmg
download LinuxVSTs.zip
download LinuxARMVSTs.zip for the Pi
download Retro 32 Bit Windows VSTs.zip
download Retro PPC/32/64 Mac AUs.zip
download Retro PPC/32/64 Mac VSTs.zip
Mediafire Backup of all downloads
All this is free and open source under the MIT license, brought to you by my Patreon.
VCV Rack module

[rafa1981]

There's more. Mixing with BitShiftGain in mono is impossibly crude. 6dB increments are seemingly impossible to mix with, absurd, insulting to even consider. But if you tick a track one step over to the side… that's now 3dB down, not 6. You've losslessly cut one side 6dB while leaving the other one unaltered.

If you had two tracks, a doubletrack, and did this with just one of them, your 'track' (that's really two tracks) can shift 1.5 dB down, to the ear. Starting to sound more interesting? If you had four tracks and shifted just one of them, that's an apparent shift of 0.75 dB.

I see no reason for such unergonomic workflows; there is nothing in return. This is counterproductive for the audio community. We don't want Pro Audio to be like the Hi-end Hi-fi, do we?

See the JSFX code below applying gains in double precision and getting the difference: The experiment: applying 3000 gains to a reference signal and then subtracting from the reference signal. The residue needs 200dB amplification to be heard. This is not free-standing noise at the absurdly low level of -200, it is a relative error against the reference signal, which means that if the signal level is 0dBFs then the error is at -200dB and if the signal is at -200dB then the error is at -400dB, etc. This with 3000 gain operations!

The proposed workflow causes more harm than good. Floating point summing is also subject to errors when the exponents are different; the signal with the least exponent drops bits (1 in the example). What is the point of all the hassle then? The proposed method is lossy too.

TL;DR. Use the DAW controls, the errors are some orders of magnitude over human capabilities.

JSFX

Code: Select all

desc:multiple gains

slider1:gain_db=0<-150,12,1> iteration gain (dB)
slider2:outgain_db=0<0,260,1>output gain (dB)
slider3:count=100<1,1500,1>count

in_pin:left input
in_pin:right input
out_pin:left output
out_pin:right output

@slider
gain=10^(gain_db/20);
outgain=10^(outgain_db/20);
invgain = 1 / gain;

@sample

l = spl0;
r = spl1;

loop(count,
  l *= gain;
  l *= invgain;
  r *= gain;
  r *= invgain;
);

spl0 -= l;
spl1 -= r;
spl0 *= outgain;
spl1 *= outgain;

[jinxtigr]

No

[LunarKitten]

Does it makes sense to use bitshiftpan for panning even if I use regular gain functions to balance the mix, or does that negate the purpose?

[jinxtigr]

Does it makes sense to use bitshiftpan for panning even if I use regular gain functions to balance the mix, or does that negate the purpose?

You can if you like. If you do, and you run it on a mono sound carried on the stereo track, any pan position retains the mantissa of the input word, unaltered, and passes it along to the next gain stage.

In ConsoleMC and ConsoleLA I do just that, use it for panning but send it to a regular gain function on the plugin's fader. I do that because I'm kind of tempted by LCR panning as a concept, but think it's overly restrictive. So BitShiftPan becomes a pseudo-LCR system, where the determining factor isn't 'pick a side' but 'only these pan positions allow you to retain the mantissa of the input word, so stick to these'.

[LunarKitten]

Does it makes sense to use bitshiftpan for panning even if I use regular gain functions to balance the mix, or does that negate the purpose?

You can if you like. If you do, and you run it on a mono sound carried on the stereo track, any pan position retains the mantissa of the input word, unaltered, and passes it along to the next gain stage.

I'm going to use it for panning then in combination with the gain function of my DAW. Thank you for your dedication and hard work.