Regular Interval labels ignores , as decimal separator

Programming and Development Nyquist
1

I tested Bug 173 in 2.0.4 alpha on Windows with German set as the Region and Language “format” (which sets the appropriate decimal separator). Bug 173 does not generally seem to occur on Windows, but Regular Interval Labels is one plug-in that displays bug 173 on Windows so I thought if it was an easy standalone fix we could discuss it here.

I’ll try bug 173 on Mac too and comment on the platform-specificity there.

What exactly is the correct way to change the system or Audacity language on Linux to reproduce bug 173 there?

By the way I noticed an oddity in Normalize that is probably a bug but could be considered a feature. For other built-in (and most Nyquist) effects, setting the Windows Format to German converts the “.” in the text boxes of slider widgets to “,” and “,” is then accepted as decimal separator and “.” ignored. But even if the format is German, Normalize still shows “.” as decimal separator. For German or English Format, both “.” and “,” are respected as separator.


Gale

2

Last time that I tested bug 173 I installed Linux with a European language. That is a pain unless you are reasonably fluent in that language because it puts everything to that language default. I don’t know what the minimum changes are, but on Linux the locale settings are quite “fine grained” (control over many different elements). For Ubuntu there is some info here: https://help.ubuntu.com/community/Locale

3

Is that a difference between a Text Input Widget and a Slider Widget?

4

It appears so. If I convert the “Time to place first label” and “Label Interval” to a slider e.g.

;control time "Set either: Label interval [seconds]" real "" 0.0 0.0 60.0

then the controls do accept “,” as decimal separator.

But it looks like there is “something” else wrong with Regular Interval Labels (or Pluck and Risset Drum). After running Regular Interval Labels (modified with sliders or as released), Pluck and Risset Drum ignore “,” as decimal separator and generate a whole length of seconds. This happens in 1.3.10 too (the first release that had the fix for Nyquist Generators giving an error in locales that used “,” ).

But running Regular Interval Labels doesn’t prevent the comma working as decimal separator in Click Track or “Delay time” in Delay.

I wonder if the “Normalize to” box would behave as expected if it was a slider?

Gale

5

“Normalize” uses a different style of widget from that used in Nyquist plug-ins, so I think we will need to look at that separately.

Normalize:

wxTextValidator vld(wxFILTER_NUMERIC);
....
....
         S.StartHorizontalLay(wxALIGN_CENTER, false);
         {
            mLevelTextCtrl = S.Id(ID_LEVEL_TEXT).AddTextBox(wxT(""), wxT(""), 10);
            mLevelTextCtrl->SetValidator(vld);
            mLevelTextCtrl->SetName(_("Maximum amplitude dB"));
            mLeveldB = S.AddVariableText(_("dB"), false,
                                         wxALIGN_CENTER_VERTICAL | wxALIGN_LEFT);
            mWarning = S.AddVariableText( wxT(""), false,
                                         wxALIGN_CENTER_VERTICAL | wxALIGN_LEFT);
         }
         S.EndHorizontalLay();

Nyquist Slider:

      wxString valStr;
      if (ctrl->type == NYQ_CTRL_REAL) {
         // If this is a user-typed value, allow unlimited precision
         if (ctrl->val != newVal)
         {
            valStr = Internat::ToDisplayString(ctrl->val);
         }
         else
         {
            if (precision == 0)
            {
               valStr.Printf(wxT("%d"), (int)floor(ctrl->val + 0.5));
            }
            else
            {
               valStr = Internat::ToDisplayString(ctrl->val, precision);
            }
         }
      }

The important difference here is that the Nyquist slider validates using Internat::ToDisplayString, which is supposed to handle the comma as a decimal separator in appropriate locales. I’d need to do a bit more digging to find if/where wxFILTER_NUMERIC (used by “Normalize”) is supposed to be localised.

For now I’d suggest that we concentrate on bug 173. The problem with Normalize may be worth logging separately on bugzilla.
I’m currently updating my Ubuntu VM so that I’ve got something to test on.

6

Well that was rather more effort than anticipated (thanks to a bug in VirtualBox version 4.2.12 guest additions).

I can confirm that there is a problem.
In certain circumstances Internat::ToDisplayString(ctrl->val) returns an integer value when it should be returning a floating point value. This only occurs when the decimal separator is not a dot. This may require expert attention as the conversion and rounding procedure is quite complicated.

7

So is there a problem that only Regular Interval Labels sets off ( when the decimal separator is not a dot)? Or is it that the Nyquist generators are randomly failing irrespective of what other effects are used?


Gale

8

It’s a problem (bug) that applies to Nyquist slider controls, so it could affect any current or future plug-in, but it may not affect all Nyquist plug-ins.

When the locale is set to use comma as a decimal separator, there is multiple branching to round the display numbers to an appropriate number of decimal places. There is additional branching to avoid rounding the display number if greater precision has been typed, and yet more branching to handle the use of a dot as the decimal separator when the locale is set to comma. The code also jumps between the effect interface, “NyquistDialog”, “Internat”, “locale”, “wxSlider” and “ShuttleGui”, and somewhere within that web is a path that incorrectly rounds the actual value (not just the display value) of a float to an integer.

The problem seems to be in the interaction between NyquistDialog::OnSlider and Internat::ToDisplayString but I’m finding it difficult to pin down. If the bug is in the latter then it could also affect other (non-nyquist) effects (I’ve not tested). A simple repeatable test should help to locate the source of the problem.

9

This does not look right.
Save this code to a file in your plug-ins folder and give it a .ny file extension (If you’re using Firefox, take care that spaces are not added before any of the header lines).
Apply the effect “!A Test” (default locale).
What is going on with Control 2, why is it displayed rounded?

;nyquist plug-in
;version 3
;type process
;name "!A Test"

;control c1 "Control 1" real "" 2.5 0 10
;control c2 "Control 2" real "" 20.5 0 100
;control c3 "Control 3" real "" 20.51 0 100
;control c4 "Control 4" real "" 200.5 0 1000

(format nil
  "Control 1: t~a~%Control 2: t~a~%Control 3: t~a~%Control 4: t~a"
  c1 c2 c3 c4)

Displays as:
Control 1: 2.5
Control 2: 21
Control 3: 20.51
Control 4: 200.5

Output:
Control 1: 2.5
Control 2: 20.5
Control 3: 20.51
Control 4: 200.5

10

With German locale set on Windows, I did 10 Generate > Plucks, 10 Generate > Risset Drum and 10 Generate > Click Track, setting a non-integer duration with comma separator, undoing after each except the last. All produced the correct duration.

Then I ran Regular Interval Labels using comma separator, using text box for 0.3 for “time to place” and 2.5 for the “label interval” (modified as a slider). “Time to place” output was time zero.

Then I always got an integer result from all three Nyquist generators. Even if it isn’t repeatable it looks to be nearly so.

My impression was that the dot was ignored when in German locale - the result was integer.

From my tests, that control works correctly up until a number and decimal point 499. Number and decimal point 5 or greater are rounded to the next integer. Only the second control has that problem.


Gale

11

I retested in HEAD but this time, I changed the non-integer duration each time I ran the generator. From launch of Audacity, if I change from the default value such as 1,0 to a non-integer such as 2,8 then it always generates correctly. If I undo the generate, then change the last non-integer value to another one (for example, 2,8 to 2,4) then I only get integer duration. This seems 100% repeatable at the moment.

But it’s almost repeatable with 1.3.10 too (sometimes it takes a few generations at different values before it fails), so that problem of failure “after a period of use” may be separate.

But running Regular interval labels will sometimes cause the next pluck or risset generate to be integer, even if I don’t change the last used non-integer value. That could be failure after a period of use, or not.


Gale

12

I don’t think that it is a “after a period of use” issue because it appears to be all logic, but there are some subtle factors that have an influence that may not be visible through the UI. There is definitely a difference between typing values and using slider values, and moving a slider after typing a value in a different control can make a difference. There may also be differences that depend on specific values because of whether they align with slider tick values. There is a difference between typing a value that changes the previous value enough to move the slider by one or more ticks, and typing a value that is only slightly different to the previous value.

13

And there may also be rounding issues that are separate, if it’s the second slider (or second control) we change?

I rarely use sliders. But try this running in a comma separated locale.

  1. Launch Audacity
  2. Generate > Pluck
  3. Click in “Duration” after the “0” of “1,0”.
  4. Press “Home”, press the delete key to empty the box then type “1,4” (without quotes)
  5. OK, duration is correct, click [X] to remove the track.
  6. Generate > Pluck.
  7. Click in “Duration” after the “4” of “1,4”.
  8. Press “Home”, press the delete key to empty the box then type “1,8” (without quotes)
  9. OK, duration is correct, click [X] to remove the track.
  10. Generate > Pluck.
  11. Click in “Duration” after the “8” of “1,8”.
  12. Press “Home”, press the delete key to empty the box then type “2,8” (without quotes)
  13. OK, duration is 2.0 seconds.

This repeats reliably in HEAD and 1.3.10 for me. But if I change once to 1,8 and then again to 2,8 (without first changing to 1,4), the problem does not happen.

And it does not display the rounding issues that you see in your test plug-in or mentioned in https://forum.audacityteam.org/t/popmute-mute-level-looses-fractional-part/29529/1 (loss of digits after the comma when using keyboard to move the slider).


Gale

14

I think we are getting a bit closer.

With a comma separated locale, a dot should still be allowed as the decimal separator.

After it has “gone wrong”:
For “Duration” in Pluck, slowly type “0.9” (without quoted).
You will notice that when you type the “9”, the slider moves a little to the right. This is what should happen.
Now try “0,9” and notice that when you type the “9” the slider does not move.

Before it has "gone wrong, the reverse is true - comma works and dot does not.

To make it “go wrong”, use a fractional part that is .5 or greater.

15

I did not think it worked like that on Windows. With German input language, typing “13.4” (without quotes) in Excel writes “13 April”.

Unfortunately per my steps above, it is not as “simple” as that on Windows. I need to perform all 13 steps to break it.


Gale

16

Steve, can you try Leland’s patch in http://bugzilla.audacityteam.org/show_bug.cgi?id=642 ? On Windows that also seems to fix the issues in this topic.

Using that patch, I can’t reproduce this:

  1. Launch Audacity
  2. Generate > Pluck
  3. Click in “Duration” after the “0” of “1,0”.
  4. Press “Home”, press the delete key to empty the box then type “1,4” (without quotes)
  5. OK, duration is correct, click [X] to remove the track.
  6. Generate > Pluck.
  7. Click in “Duration” after the “4” of “1,4”.
  8. Press “Home”, press the delete key to empty the box then type “1,8” (without quotes)
  9. OK, duration is correct, click [X] to remove the track.
  10. Generate > Pluck.
  11. Click in “Duration” after the “8” of “1,8”.
  12. Press “Home”, press the delete key to empty the box then type “2,8” (without quotes)
  13. OK, duration is 2.0 seconds.

And I don’t see the rounding issues mentioned in https://forum.audacityteam.org/t/popmute-mute-level-looses-fractional-part/29529/1 (loss of digits after the comma when using keyboard to move the slider).


Gale

17

Tested on Mint and it looks good.
I’ve only tested briefly but it appears to fix both 642 and 173.
I’ll test more thoroughly tomorrow and assuming all goes well I’ll confirm on bugzilla. It’d be good to clear a couple more P3s in 2.0.5 and this looks like a safe fix.