While testing the Bus Volume Fade functions I noticed one slight issue, and I don't know if it's intentional or a bug as when going back to compare to Input Volume Fade that also works similarly.

The issue is that when fading the volume, any attempting to adjust the volume (either through the UI or set volume functions) to a volume above the target if fading volume down, or below the target if fading the volume up, will cause the fade to continue until the target volume is reached. If the volume is changed to beyond the target, it will immediately jump to the target volume.

For example, if Bus A is at 100, and I fade to 50 over 2000ms, but I then use SetBusAVolume to 100 (or move the bar in the UI) at 1999ms, the volume will instantly go to 100 but then start fading at the same rate towards 50. This can be repeated indefinitely so that initial 2000ms fade could be fading forever if I keep setting the volume above 50.

In that previous example, once the fade is in progress if I instead set the volume to 0 before the fade reaches 50, it'll instantly jump from 0 where I just set it to 50. Same as if I click below 50 in the volume meter UI.

My issue with this, is that if a fade is started it becomes impossible to stop other than to use another fade which will overwrite it. I even tried using a 0ms fade to set the volume to a specific value and overwrite the in-progress fade, but unfortunately even though the HTTP API returns "Function completed successfully.", or TCP "FUNCTION OK Completed", a 0ms fade doesn't actually work so the in-progress fade continues.

My expectation is that when using any form of setting a volume, be it through the UI or API, the most recent change should take precedent and stop any fade that may be in-progress.