When the value of depth 0 the plugin produces unexpected behaviour where the plugin continually sweeps the phase downward to the minimum value. This fix eliminates this edge case making minimal changes to the plugin and no aesthetic changes.
When depth is set to 0 or very close to 0 (probably CPU dependant) the assignment of swpFactor to be the value of sweepFactor at PhaserPlugin::applyToBuffer():24 causes swpFactor to always be 1. Consequently when swp is multiply assigned by swpFactor with a value of 1, the value of swp is always greater than the value of maxSweep for this depth, and so swpFactor is always assigned the value of sweepDown. The impact is to have the phaser bottom out and get stuck at -2.77556e-16 for me on my x86 CPU.
At a depth of 0, the value of range is 1. Given a range of 1 the value of maxSweep value is identical to minSweep. Given these details as the value of depth approaches 0, and depending on the accuracy of the CPU's implementation of denormal numbers, the Phaser rapidly approaches a point where it no longer works as expected.
My solution is to remove PhaserPlugin::appyToBuffer():24 swpFactor = sweepFactor;. I'm not sure why the value of swpFactor is filled again before it's read, but removing this makes the ternary operator at PhaserPlugin::appyToBuffer():15 successful at switching the direction of the factor as it crosses between upwards and downwards phase sweeping. This change should not change any of the aesthetic qualities of the Phaser.
drowaudio
commented
1 month ago
Overview
When the value of depth 0 the plugin produces unexpected behaviour where the plugin continually sweeps the phase downward to the minimum value. This fix eliminates this edge case making minimal changes to the plugin and no aesthetic changes.
Bug Behaviour
Originally produced on an M2 Mac. https://github.com/Tracktion/tracktion_engine/assets/133661475/33866f73-b1a6-4bd3-826b-cdb9c8773bc4
Bug Description
When
depthis set to 0 or very close to 0 (probably CPU dependant) the assignment of swpFactor to be the value of sweepFactor at PhaserPlugin::applyToBuffer():24 causes swpFactor to always be 1. Consequently whenswpis multiply assigned byswpFactorwith a value of 1, the value ofswpis always greater than the value ofmaxSweepfor thisdepth, and soswpFactoris always assigned the value ofsweepDown. The impact is to have the phaser bottom out and get stuck at -2.77556e-16 for me on my x86 CPU.At a
depthof 0, the value ofrangeis 1. Given a range of 1 the value ofmaxSweepvalue is identical tominSweep. Given these details as the value ofdepthapproaches 0, and depending on the accuracy of the CPU's implementation of denormal numbers, the Phaser rapidly approaches a point where it no longer works as expected.My solution is to remove PhaserPlugin::appyToBuffer():24
swpFactor = sweepFactor;. I'm not sure why the value ofswpFactoris filled again before it's read, but removing this makes the ternary operator at PhaserPlugin::appyToBuffer():15 successful at switching the direction of the factor as it crosses between upwards and downwards phase sweeping. This change should not change any of the aesthetic qualities of the Phaser.Fix Demonstration
https://github.com/Tracktion/tracktion_engine/assets/133661475/d0044877-3a7c-4417-bb19-d5816ce0a0f3 Sorry for the video quality, I had to get it under 10 MB.