Numeric text input widget for Nyquist plug-ins

I wasn’t sure whether to post this here or on the Nyquist board.
I would like to propose a small new feature for Nyquist plug-ins; two new numeric text widgets, one for integer values and one for floats.

These differ from the current “real” and “int” widgets only in that they do not have sliders. and the default text box size is a little larger.
In appearance they are exactly like the string input widget, but the user input is validated to allow only numbers, and in the case of the float version, the decimal separator appropriate to the locale.

The syntax is the same as for other widgets.
Ideally I would have liked to have called these “int” and “float”, but those names are already take, so I suggest “int-text” and “float-text”

This is the syntax:
;control variable-name “text-left” variable-type “text-right” initial-value minimum maximum
where “variable-type” is either “int-text” or “float-text” (without quotes).

As with other widgets, the “text-right” is optional (it may be an empty string). There is an old bug that text-right is not read by screen readers, I don’t know if that is still true in Audacity 2,1,2 alpha.


;control int "int-text" int-text "label" 10 -1 1000000000
;control float "float-text" float-text "label" 10 -1 1000000000

The user supplied number is validated to ensure that it is within the min / max range, but the default error message from Audacity is not very meaningful, so in most cases I think it better to set min and max well beyond the “sensible” range, and validate to the actual usable range within the Nyquist code. For example, if setting a frequency for a filter, the min and max for the widget could be set as above to -1 to 1000000000, and then validate within the Nyquist code for values between 0 Hz and half the sample rate.

Benefits of the new widgets,

  1. Where a very large range is required, slider controls do not work very well because the limited number of “ticks” for the slider scale makes setting precise values impossible.

  2. Sliders can be confusing for blind users because (I believe) they are always read with a scale of 0 to 100, regardless of the actual scale.

  3. For non-mouse users, sliders are just “in the way”. Typing a number is usually much easier than scrolling the slider with cursor keys, so the slider is just one more thing to tab over.

  4. Where the upper range is uncertain (for example when setting the frequency of a filter that is dependent on sample rate), a slider is misleading because users are likely to assume that the slider range is the valid range. So either the range of the control must be limited to the smallest likely maximum, or the top end of the range is invalid.

  5. Only valid numbers may be typed (so better than the string widget when numeric data is required).

This screenshot show all available widgets. The two new ones are at the bottom:
fullwindow-Nyquist Worker-000.png
This screenshot shows the Nyquist Notch filter with the new widgets:
fullwindow-Notch Filter-001.png

I fully agree.

The only thing I would change:
take a somewhat catchier name, without dashes, like

  • intbox
  • floatbox
  • realbox

I’m not sure if minimum and maximum are really necessary, they are essentially given by the number type.
I’d rather differentiate between signed and unsigned numbers.
The latter would prohibit typing a + or - sign on input.
However, this isn’t compatible with entering e.g. 0.000001 = 1e-06.

All in all, I’m happy with your proposal. It will be a real benefit for non-mouse users, for instance in “Click Track” which needs currently 24 tabulators for a full cycle.

By the way, the right hand side is still not read by screen readers - NVDA at least.
It isn’t such a big loss though.
I’m working with wxwidgets 2.8.12, so take it with a grain of salt.

Thanks Steve for the work on this.


Thanks for the suggestion. I’m not overly keen on the names either, but this was my reasoning:

If it were C++ we would almost certainly CamelCase it as one compound word, but Nyquist almost always hyphenate compound words. There are however a few exceptions in Nyquist, (highpass, lowpass, bandpass, alpass, echoenabled, any more?). The only other exceptions that come to mind is when we append a single character to the end of a word, such a appending a “p” for predicates.

I don’t think they are essential, but there are a few advantages.

  1. It gives us the same syntax as all other control widgets, which I think is important if we are to add these to the version 4 plug-in definition.
  2. Although the default error message is not very meaningful for general release plug-ins, it is very convenient for general use where we are less concerned about holding the users hand. The default error message for integer controls is; “Not in range” and for floating point controls: “Value not in range” followed by the numeric range expressed with 12 decimal places. The really good thing about the default error messages are:
  • The error is shown without closing the plug-in interface.
    • On dismissing the error message, focus is returned to the control which has the invalid value.
      I would like that version 5 plug-ins give us these benefits but also allow us to provide custom error messages.
  1. When creating a plug-in for personal use, we automatically get basic range verification with very little coding effort, but can also override that very easily by providing ridiculously extreme min and max.

Again, I’m working here within the framework of version 4 plug-ins and the current validation methods (these validation methods apply to all effects, not just Nyquist effects).
The current controls allow unsigned numbers to be specified by setting the min value to zero. When you do this, a minus sign cannot be typed.
Scientific notation is not supported in Audacity 2.1.2.

I’m actually quite surprised that text box without the slider was not in the original plug-in specification. There are many cases where sliders are superfluous.

Not a big loss because we tend to avoid using text-right for that reason, though there are definitely cases where it would be useful to be able to use text-right, so please let us know if this changes in Wx3.

Thanks for the feedback, and if you have other ideas for what to call these widgets, or a good argument for why to use non-hyphenated compound words, please do say while there is time to change it.

The balance is almost equal between hyphenated and other expressions (935 of 2306 known commands with a dash).
The appended -text suggests to me that text is also allowed, hence my proposal of IntBox or rather int-box.

The scientific notation still works for me with the earlier 2.1.2, is that a 3.0.2 WXWidget thing?

I’ll make another attempt with building the newest version.

Do you think that those controls will be available in Aud 2.1.2?
This would be great.

Another control that I like very much in Audacity is that one of the resample dialog (edit combo):
It has some predefined numbers but allows typing in any value.


But of the 1371 expressions without a dash, 1367 are single words or single words with a single character added. I can only find 4 out of 2306 commands that are un-hyphenated compound words.

Well the new widgets are almost identical to the “string” widget, except that they accept only numeric characters.

When we get version 5 plug-ins, I’d like “slider widgets” to be only the slider (no text box), which is how it works in WxWidgets. What we currently call a “slider widget” (text box + slider) will be a compound widget made of a text-box widget and a slider widget. This has the benefit that we will be able to validate the slider input separately from the text input (and so regain the ability to allow a larger range for text input) and allow the slider movement to be scaled in non-linear ways (for example a log scaled slider). We will then have three types of text-box widgets: string, integer and float, (which we will probably call “string”, “int” and “float”).

At the moment I’m still leaning toward “int-text” and “float-text”, but we need to decide quickly if we are to get this into Audacity 2.1.2.

You’re right. Scientific notation is still supported.

As this is a relatively minor update, I think that I will be allowed to add it for 2.1.2 if the proposal receives some user support (let your views be known).

That would be nice, but it’s a bigger change, so we may need to wait for that.

It does not matter to users, but “int-text” and “float-text” don’t convey “numbers only” to me. Perhaps “int-numtext” and “float-numtext”?

I strongly dislike the Hz/kHz selector we have now so I am a strong +1 on the new numerical text input widget for 2.1.2. :wink:


“Most” users - agreed. (Nyquist is admittedly an “advanced” set of tools, but it is nevertheless a set of tools available to users).

I think that it will convey “numbers only” to Nyquist users. In Nyquist we have the commands char-in. int-char, integerp, read-int, write-int, float, floatp, read-float, write-float, and others, which are all about “numbers”, though none of them explicitly say “number”.

OK, thanks for your support. I’m working on it :wink:

As I wrote previously, I’d like to keep the syntax the same as for the other widgets.
How about if we allow min and/or max to be a null value?

For example:

;control var "text left" int-text "" 10 0 nil

This would create an integer text-box, default value 10, minimum value 0, maximum value not defined.
In practice the maximum value would be the maximum integer value supported by the C++ compiler.

Similarly the minimum value could be “not defined” by writing “nil” (without quotes) and the minimum would be the minimum integer value supported by the C++ compiler.
For float-text widgets, “nil” would be the most positive or negative float value supported by the compiler.

OK, send it on the way and I’m happy with it.

What do you think, should the extrema be displayed in the GUI, if they are not nil?
I don’t like the idea of letting the user fully in the dark - until the validation error pops up. It might be less a problem for well-known units like Hertz and dB. For others, the author has to be cautious, I think, and to give a hint in the text about a useful range.

To take my VRaI effect as example:
It makes sense to replace the frequency sliders with a simple numeric text box (if the Nyquist frequency can’t be displayed in the control) but not the strength slider.
The latter “cries” for a combo box, as I’ve mentioned before,
with e.g. predefined values of 0.02, 0.1, 0.5, 1.0 2.0 10.0, 50.0.

I just want to say that I will have to restrain myself in using the new controls inappropriately.


Currently we have no automatic way to do that, but the range could be added to the left text.

;control var "Enter a number (0 to 100)" int-text "" 50 nil nil

(if (< var 0) -> error, number too small
(if (> var 100) -> error, number too large

:smiley: For personal use, abuse them all you like.

Hello sirs,
let me add my rebuttal for why you should not put limitations on the hz or furthermore any aspects of the current audacity, and why I think the older system of inputting any value from zero to infinity was far more innovative then limiting the effects via the “value not in range” error.

First off, let me say I’ve been using audacity for a number of years and have found it to be the best audio software over any contender for it’s user friendly layout, and I must say I’ve been pleased with it’s capabilities thus far especially when combined with other freeware such as vst-host from hermann, musescore, lmms, and hydrogen which combined provide an experience far greater then fl studio or adobe audition or what have you. see, audacities ability to input over the range of the slider has proven to be an advantage I use in my music on the DAILY, and heading into the radio end of audio as I’m a student at Colorado media school,

I have perfected my craft in music with audacity for the reason of its ability to do that function among other functions that tend to be easier to do in audacity, and I feel that putting limitations on the effects is limiting audacities ability to experiment with high hz frequencies/ on effects that others cannot do. have you tried using a phaser or the wah wah effect at say… 80 hz? 200? 900? all have an effect on music that cannot be MATCHED and I think that it’s a plus for users.

Hi DominicJosephRico,
I partly agree with you, but part of the problem here is that the current method of input validation is “new”, whereas many of the plug-ins to which it applies are much older. This has led to the unfortunate situation where the plug-in author was expecting that values beyond the slider range would be available, but now they are not.

Let me give what may seem like a silly example.
Many plug-ins have multiple choice controls (provide a dropdown menu from which one choice may be selected). This has not changed. If the plug-in author intended it to have 4 options, then it still has 4 options. We don’t receive complaints about this because it is clear that 4 options are what are available.
Similarly, owners of hardware effects are aware that the controls have a minimum setting and a maximum setting. That is normal and no-one complains.
In old Nyquist effects, the situation was “not normal” in that for many effects the “minimum” was not really a minimum and the “maximum” was not really a maximum. It is because of this legacy that we now have complaints.

The purpose of “input validation” is to prevent “bad things” from happening, In some cases, excessively large or small input values may cause the effect to freeze or crash, which will probably take Audacity down with it. Allowing that is clearly not in the best interests of the majority of users.

What needs to be done in those cases where the plug-in designer was expecting values beyond the normal range to be available, is for the plug-ins to be updated so that the full, safe operating range is available to users.

And presumably that may mean not using a slider control, because it would be awkward to control that with keyboard arrow keys if the scale had many more steps?


One possibility that I’ve been thinking about is the possibility of having separate validation for the slider and the text box. Essentially it work work within Nyquist as two loosely linked controls. The slider could then be validated as now, and the numeric text validated for numeric input with a separately defined (could be greater) range. This could also give us the ability to have logarithmic scaled sliders, which would be a great benefit for some effects.

Yes, the "separate validation seems like a good idea in principle. Thanks.



Moved to the Nyquist board