rainwarrior wrote:I guess some of the "negative" shifts use the upper bits? Maybe 18 hours in or something three of the eight >>19 phases will start to sound a little different?
So, this long phase stuff is really only the top 3 bits, and they are being shifted to the low 1-3 bits of output and ORed with it, so their actual impact on the sound is quite minimal. (This implementation discards the low bit of output too, so it's only the top 2 bits.)
Using a debugger it's easy to set the top 2 bits of "t" and listen, and it only affects 2 of the 8 mid-range phases (about 1 minute each of the ~8 minute "loop"). They don't really sound that different.
The negative shifts are more like a surrogate for a 0 term than an actual useful result.
Originally I was considering that the calculation could be simplified by shifting the output early (>> 1) instead of at the end (and also remember only 7 of the bits matter). In particular the terms (t << 1) >> 1
and (t >> 7) >> 1
can just be directly read as single bytes from the 4-byte accumulator. I think this would lose precision on the lowest bit of output from (t>>1) + (t>>7)
, but would mostly sound the same. (Similarly the 8 mid-phase shift operations can each be customized with an extra >> 1.) Also if you want to ignore the long phase entirely (since it has minimal effect anyway), you can just treat the high byte of "t" as a permanent 0 and skip the extra load/add/store in its increment.
Ultimately I thought it was best to keep it as accurate as I could, but if you need extra cycles, these are options.