I was curious if I could figure out the exact values of bit reduction you’d need to get things like 12-bit or 8-bit. Using the LFO Designer to get “in between” values here is what I worked out:
| Target bits | BRR | FINE |
|---|---|---|
| 24 | 0 | 0 |
| 23 | 3 | 76 |
| 22 | 7 | 36 |
| 21 | 11 | 7 |
| 20 | 14 | 118 |
| 19 | 18 | 114 |
| 18 | 22 | 125 |
| 17 | 27 | 23 |
| 16 | 31 | 67 |
| 15 | 36 | 1 |
| 14 | 40 | 84 |
| 13 | 45 | 63 |
| 12 | 50 | 68 |
| 11 | 55 | 102 |
| 10 | 61 | 44 |
| 9 | 67 | 26 |
| 8 | 73 | 57 |
| 7 | 80 | 19 |
| 6 | 87 | 57 |
| 5 | 95 | 65 |
| 4 | 104 | 84 |
| 3 | 115 | 66 |
| 2 | 127 | 127 (closest achievable: 2.0996, not exact) |
Have fun!
cool! i’m curious how you determined these values to be correct
Octobam has a github repo with an emulator for the processors in the Octatrack and some really helpful documentation. I have the current firmware from Elektron, so I disassemble that and start tracing the knobs through the DSP. I’m basically virtually sweeping the parameter on the Octatrack and seeing what happens in the math at the appropriate memory location. I’ve written my own bit reducer plugin before, so I had a pretty good idea of what to look for in terms of the algorithm.
Before I knew the emulators for the Octatrack were a thing I was testing all of this stuff with test signals in my DAW. That worked for a lot of the effects but that wasn’t going to be workable here without some programming.
The value that I hope I’m providing are the “in-between” settings. Most folks probably don’t do that on their Octatrack, but I find it incredibly useful for getting what I want out of it. Tuned ring mod, exact delay times, 8-bit reduction for Nintendo sounds, etc.
i like when everybody else seems insane and i get to feel regular
thank you for your maths and homework!
Whenever I use bit reduction on other devices I do often think why can’t I just select 12 bit instead of some random values or play through a space invader pixel animation or something else obscure .
Want 12 bit - move encoder to value of 12 ?
Your values are useful but it really shouldn’t be so obscure on newer devices
The other approach ….’ I just want it to sound crunchy’ probably doesn’t matter so much … I just turn a dial until it sounds crunchy enough .
A few simple clips showing 12, 10, 8, 6, 5, 4, 3, 2 bit depths. The second time through I lower the volume going into the BRR and then increase it after. A fun characteristic is that bit rate reduction responds so much differently based on the volume of the signal going into it.
Sine:
Saw:
Question : why does it matter to know ?
A1: It doesn’t. Just set it by ear.
A2: Maybe you want to mimic a 12 bit sampler or delay and this is part of that puzzle.
A3: There might be some “tuned BRR” musical idea that needs this resolution.
I’m somewhere between A1 and A2. I was genuinely curious where 8-bit was on the knob. Getting close to the right value is probably good enough for what I do with it.
Thanks !
My behind question was if some techy FXs or algos needed to set precise values to work properly.
If it’s just a matter of how it sounds, then I’m definitely A1 !
There’s a lot of lore about 80s samplers and digital delays sounding unique due to their 12-bit architecture and the compression/expansion circuits used to optimize them. If you’re really trying to get that character out of your Octatrack, you might go the extra step with the fine tuning.
On the noisier side, there are some quite non-linear behaviors at the lower bit rates. For me, having a road map of values helps me find those interesting regions quicker, even if I’m not dialing in 6 17/128 bits exactly.
You should collect all of these charts/lists you’ve been working out and make a PDF set that also includes other already known charts/lists, like the LFO speed/mult one. Having all of them in a single PDF open on my iPad while I work with the thing would be hella useful.
I’m definitely planning one for the tables I’ve put together. I got a bit derailed because I was initially doing them all with audio tests (this was fun, a lot of work, but not precisely right). But now that I can do it from the decompiled code I can be more precise. But that’s a bit more work.
I’ve been pleased when the values I mapped with audio testing matched the actual algorithms.