Is BitShiftPan (Airwindows) of any use for mixing?

[LunarKitty]

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.

Hey guys,

as far as I understand it, using the volume faders on tracks as well as the panning function, can reduce the audio quality and overall clarity (please feel free to correct me if I'm wrong) in a mix, and the BitShiftPan VST can help with that. It is, however, limited to losslessly dropping the volume in 6dB steps.

I can see myself using this for panning, just as some might go for LCR mixing. Adjusting levels in 6db steps, unforunatly, is not practical as far as I'm concerened.

https://www.airwindows.com/bitshiftpan/ (https://www.airwindows.com/bitshiftpan/)

I was wondering if there is any gain in using the panning funciton in BitShiftPan, while using the volume faders in my DAW, but doesn't this defeat the purpose?

If so, how is this plugin practical in any real mixing application?

Thanks in advance!

[DNAudio]

I'm sure Chris's intention with this plugin wasn't necessarily to make people worry over inaudible distortions in audio quality and make them feel forced to use it. I use bitshiftgain/pan for when a large increase/decrease in gain is necessary so I may as well use the plugin that's "technically correct"
All of Chris's other plugins (with a few exceptions) use some form of dither or high precision noise shaping for gain staging, which is better than what you'd get in a DAW but I really wouldn't worry about it too much. I generally use my DAW's sliders when mixing and then when it comes time to master I'll try and set my DAW's volume sliders to neutral and use PurestGain instead. (Or BitShiftGain if I'm able to.)

[rafa1981]

It's harmful by the way it harms the workflow. Both this and floating point dithering.

viewtopic.php?t=597215

[ampetrosillo]

Whether you use it or not, it's immaterial. Even with just 32 bit floating point processing (and basically all DAWs work at 64 bit? AFAIK) you have about three-four bits in the mantissa (the actual "number" part) that are basically all noise, for "recorded" signals, even before you start doing stuff to the signal (unless it's purely synthesized stuff, but then again you wouldn't be able to hear those three-four bits clearly since they will be dominated by noise contributed by the DAC). The funny thing is that most DAWs these days work at higher bit depths, so it counts even less.

Where such an approach can be useful is in integer processing, which you can find in certain (old, at this point) hardware. Instead of multiplying, you can truly bit-shift the samples (I say truly because you aren't really bitshifting the samples in floating point maths, you are adjusting the exponent) and maintain the same precision (well, until you start overflowing or truncating...). If you're doing audio stuff with an Arduino (I think... I can't remember if that microcontroller is even capable of floating point maths) this approach would actually be preferred.

[LunarKitty]

Thanks for your response.

Okay, I now understand that it is counterproductive for the workflow and the result is inaudible.

On the Sage Audio Youtube channel a comparison was shown, to demonstrate the difference, but I can't find the video anymore, unfortunatly.

Regardless of these details, I'm curious to know how this plugin is intended to be used.

If I use the DAWs volumes fader, but the panning of BitShiftPan, do I still get the benefit intended by Chris, or does using the DAWs volumes fader completely negate, what he is trying to achieve with this plugin and I would have to stick to the volume fader and panner withing BitShiftPan and not touching these functions in my DAW at all?

[No_Use]

It's harmful by the way it harms the workflow. Both this and floating point dithering.

viewtopic.php?t=597215

Thanks for the test you did there.
jinxtigr's reply though ...
Did someone say snake oil?

[rafa1981]

If I use the DAWs volumes fader, but the panning of BitShiftPan, do I still get the benefit intended by Chris, or does using the DAWs volumes fader completely negate, what he is trying to achieve with this plugin and I would have to stick to the volume fader and panner withing BitShiftPan and not touching these functions in my DAW at all?

If one kg of rice has 50000 grains and the error noise were at -200db (it's actually lower), which is 10 billion linear, you'd be worrying about a single grain of rice in a 200kg bag.

What he is trying to achieve with this plugin only he knows. What are you trying to achieve?

[rafa1981]

The funny thing is that the implementation is also suboptimal.

Multiplying any floating point number by a power of two is lossless. It's an integer addition/subtraction to the exponent (if the result is in range). No need for bitshifts or nothing exotic.

[diroxe7660]

as far as I understand it, using the volume faders on tracks as well as the panning function, can reduce the audio quality and overall clarity

Never to any meaningful degree, this is a completely theoretical and honestly very much esoteric "I want to believe" non-issue. You can pan and adjust gain with your DAW's controls 100ks of times and you'll still not hear a difference between render #1 and #100'000.

Adjusting levels in 6db steps, unforunatly, is not practical as far as I'm concerened.

Exactly - it'll make your mixes worse. Same for panning with stepped controls. Worse than possibly, not necessarily, introducing a rounding error at -340 dB.

I was wondering if there is any gain in using the panning funciton in BitShiftPan, while using the volume faders in my DAW, but doesn't this defeat the purpose?

There's no benefit in using those plugins to begin with. The label "bitshift" in itself is based on a misunderstanding or an attempt to mislead.

[LunarKitty]

I'd like to experiment with the plugin to see, if I can get it to work for me. However, if the intended purpose is negated by using the DAWs volume function, while using the VSTs panning function, I'm sceptical that it can be practical for me.

That's why I wanted to know if it is important to use the VST for panning and leveling, or if I can use the volume function while still getting the benefit Chris intended. Perhaps if chris stumbles across this thread he can share his thoughts.

[El°HYM]

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

Why not just do a quote to let him know. Anything else could be considered as mumbled to one self.

[rafa1981]

Well, I don't know how to explain it nicely. Everything has been said already. Let me try with an an appeal to authority falacy: I'm a seasoned professional developer. I have written custom floating point formats, fixed point arithmetic and VST plugins, e.g. on the Turbopaco reverb plugin to store buffers at 16-bit float or running the reverb dsp as fixed point and store as 16 bit samples, so I know the floating point format pretty well. The sources are open.

You are wasting your time and spreading information that can make others waste their time too if they follow. No one needs that. It's harmful. Snake oil. It's a relative error, not noise.

It's the equivalent of high-end hi-fi 10000$ cables, but instead of suffering once by paying and then forgetting you pay nothing but suffer continuosly by doing unneded work for no reason.

[LunarKitty]

Okay, got it!