Hammond chorus loop out of range about bristol-fixes HOT 4 OPEN

Nice catch, thanks!

From the usage in the hammondchorus context, it looks like the phase is never being referenced beyond phase[TAPS-1] (by definition of [a-f,z]tap indexes, which are limited to 8 = TAPS-1). Not sure if the intended behavior was fully implemented.

Meanwhile and given the scope, it would make sense to limit this loop to < TAPS for proper bounds. Maybe some other usage for the phase[TAPS] memory would pop in the debugger.

Did you notice any audible distortions in the current chorus rendering for Hammond? So we could rely on some test case for this.

from bristol-fixes.

Tested the output with < TAPS applied: There's a noticeable difference in fullness of the vibrato-chorus -- sound is "thinner". So, indeed, the phase[TAPS] is being incorporated into the resulting sound somehow. This fix does not do it right.

Tried to apply the alternative fix -- expanded the tapfilt and tapgain arrays to TAPS+1. Seems to produce the same output sound as from the original vibrato-chorus. I guess, will settle on this fix. This should clear the compiler warning too.

from bristol-fixes.

Sorry that I haven't answered earlier, simply I didn't get opportunity to test bristol on its own and had other tasks.
I did only some source-level work but not tested anything at all.
I was still stuck at a vast number of bristol linking issues, but I could provide a PR of these later.

from bristol-fixes.

Fixed in 871831a

Bristol-Bug: 96

from bristol-fixes.