Hammond chorus loop out of range

[jpcima]

This loop accesses 1 item out of range in tapfilt, which is of size TAPS.
The other accesses are in tables of size TAPS+1 so these are fine.

I don't know yet what should be the proper solution for this problem, just noticed.

bristol-fixes/bristol/hammondchorus.c

Line 390 in 66b424b

for (j = 0; j <= TAPS; j++)

[nomadbyte]

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.

[nomadbyte]

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.

[jpcima]

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.

[nomadbyte]

Fixed in 871831a

Bristol-Bug: 96