Bugzilla – Bug 963
Control value may be out of range when using FloatingPointValidator
Last modified: 2018-08-20 11:45:41 UTC
Some slider controls may give "out of range" errors when at the maximum or minimum settings (see steps to reproduce). When using FloatingPointValidator and calculating the min / max range as floats or doubles, the validated control value has been rounded to 'n' decimal places, but the min / max range have not been rounded. It is therefore a matter of chance whether the rounded control value, when at the extreme limit of the range, is within the higher precision range or not.
Commit 1a2486b
(In reply to Steve Daulton from comment #1) > Commit 1a2486b I confirm that this fixes the two examples using windows 8.1
Testing on W10 audacity-win-ra45f3bb-2.2.0-alpha-22-jul-17 Tested on macOS Sierra 10.12.6 aae0c4c 04Aug17 I do not get the error message with the Change Tempo on both platforms and the effect worked. However on both platforms, with the Amplify use case #1, I still get the same error message when the Amplify when the amplification is set to the the extreme -50.0 - setting that to -49,9 though means that the Ammplify will work ok (effectively producing silence). So although this is a fringe, extreme, case I still have to mark this minus on Windows and Mac and Reopen the bug
(In reply to Peter Sampson from comment #3) It was fixed, but then got broken again by the fix for bug 958. Updated the fix to account for that. https://github.com/audacity/audacity/commit/973577
(In reply to Steve Daulton from comment #4) Tested on macOS 10.13.2 High Sierra with audacity-macos-nightly-2.2.2-63de7f0.dmg - 25.95 MB | version: 2.2.2--18Dec17 No error messages with either the extreme change temp or the extreme amplify - so looks to be good on Mac
(In reply to Steve Daulton from comment #4) Testing on James' 2.2.2 build of 18Dec17 on W10 On W10 the extreme Amplify is now fine. But the extreme Change Tempo has an issue. Withe the -99% 1) the Change Tempo dialog pops up but empty and whited out (see attachment) 2) It looks as though Audacity is frozen (the first couple of tests I forced quit the app) 3) with subsequent testing I monitored with Task Manager which showed that in that state Audacity was actively using 30+ % of CPU and 100-150MB memory 4) I let it run and then after 2-3 minutes the Change Tempo dialog was properly populated and the progress bar progressed 5) the effect worked But I feel that most users would bale out as step 2 (as I did the first couple of times). Extreme settings at the other other end of the effect's slider work fine. Using -98% has a similar "hanging" delay -95% has a shorter but still noticeable delay -90% has a brief delay This also seems to affect Change Speed effect similarly Marked as REOPENED
Created attachment 748 [details] Pseudo Freeze with extreme -99% Change Tempo Not a real freeze - it eventually clears if you are patient enough
(In reply to Peter Sampson from comment #6) The Change Tempo effect is expected to be very slow at the extreme -99% setting because it is effectively processing 100 times the length of the selection. This is unrelated to the validation check, thus outside the scope of bug 963. If you are satisfied that the validation error as described in the bug description no longer occurs, please close this bug. If you are not satisfied that that is the case, please clarify on the QA mailing list. If necessary, raise new bugs for other issues.
(In reply to Steve Daulton from comment #8) I indeed get no validation errors - so yes the issue as explained in the titling of this bug no longer occurs. But in using the Steps To Reproduce Use Case 2 - a residual issue emerges a) on Widows as I describe in Comment #6 and the attachment b) I retested today on Mac and similar now occurs - I get the spinning beachball of death - the Activity Monitor shows in red Audacity not responding and consuming 100% CPU - Which eventually clears and the effect shows a short progress dialog and works. But in both cases the user is presented with a confusing GUI which looks as though Audacity is frozen with no progress report - with which many usesc would force abort. We do not have a consistent Bugzilla policy for residual issues. In some cases we add them to the existing bug - in other cases we create new bugs (usually linking back to the original bug). I am happy to adopt either approach here - but since Steve has requested that we close this one as it now "does what it says on the tin" and create a new bug for this fringe case - that is what I shall do
For the residual I created Bug #1806
