This is a bugfix. I found in my Rust reimplementation of this TriSawLFO algorithm,
that if the revPoint is changed while the LFO is in rising or falling state,
the output values could easily exceed 1.0. The bug emits from the
desync of the internal _rising flag and the actual state of _step.
Given _rising = false (once LFO _step passed revPoint), if the revPoint
is changed with setRevPoint(), _fallRate could become eg. -999.
When the next LFO output is calculated with _rising = false and _fallRate=-999,
the output would be eg. 0.6 * -999.0 - -999.0 = 399.6
This patch gets rid of _rising and reduces two if statements to one.
This is a bugfix. I found in my Rust reimplementation of this TriSawLFO algorithm, that if the revPoint is changed while the LFO is in rising or falling state, the output values could easily exceed 1.0. The bug emits from the desync of the internal _rising flag and the actual state of _step.
Given _rising = false (once LFO _step passed revPoint), if the revPoint is changed with setRevPoint(), _fallRate could become eg. -999. When the next LFO output is calculated with _rising = false and _fallRate=-999, the output would be eg. 0.6 * -999.0 - -999.0 = 399.6
This patch gets rid of _rising and reduces two if statements to one.