Tested with Audacity 1.3.13-alpha-Sep 15 2010 PPC OS X 10.5.8

As long as "All controls" is set in System Preferences > Keyboard > Keyboard Shortcuts (allows tabbing to all controls in a dialog - other option is text boxes and lists only), the follow occurs:

1) None of the sliders respond the home and end keys, whether they are clicked on or tabbed into.
2) All of the sliders respond properly to arrow keys (and can be adjusted over their full range), whether they are clicked on or tabbed into.

It appears that sliders do not respond to the home and end keys, nor do they respond to the mouse wheel, in any effect dialog.

(In reply to comment #1)
> It appears that sliders do not respond to the home and end keys, nor do they
> respond to the mouse wheel, in any effect dialog.

Thanks, Bill. Comment appended to bug 139.

For Freq Smoothing the up/down arrow keys are reversed (up arrow moves 
the value lower though the right/left arrow keys are correct). If you 
compare this with the  NR & Sensitivity dB values the up/down arrow 
move the slider in the same direction as they do for the FS 
slider--for dB it makes some sense, for Hz it does not.

Created attachment 120 [details]
2 decimal place partial solution

Created attachment 121 [details]
3 decimal place partial solution

These patches are focusing ONLY on the issues with the attack/decay slider--either patch fixes all the reported problems--tested on Win7 & a VB Linux. (On my system the Sensitivity slider works in all modes EXCEPT that after <HOME> the right arrow responds only sluggishly--I'm guessing that the delta is so small that the keypress is not enough to change the text.)

The current effective range for attack/decay is one second in steps of one one thousandth (the slider range is 0-1000 and its value is factored by 1000). Is one second a reasonable MAX? Does it need three decimal places of accuracy? If we keep steps of 1000 we will require three decimal places; if we move to steps of 100 we can stay with 2 decimal places.

The reason why the arrow keys appear not to have an effect is because each arrow press is so tiny a value in respect to the range of the slider (0-1000); each arrow press is 1/1000 of the range or 0.001. The code which translates the arrow press into the value entered into the text box (and used as the value of the variable) is set by:
mTimeT->SetValue(wxString::Format(wxT("%.2f"), mTime));

%.2f means use the float 0.001 but only the first 2 digits after the decimal which is .00 or nothing! Just changing it to %.3f makes the arrow keys work. 

There are two possible solutions, the easiest and most functional* is to change from %.2f to %.3f. This yields three decimals of accuracy but the arrow keys move the slider slowly. The other option is to stay with two decimals and change the factor from 1000 down to 100.

I have attached patches for both options.

*On my machine, when set to two decimals holding down the arrow key eventually stops working as messages pile up to quickly to be responded to; using 3 decimals seems to overcome this.

Note that nowhere else except Effects (Nyquist??) in Audacity do the sliders respond to <HOME>, <END> & <arrow keys>. I see that in Effects wxSlider is used; in the main Audacity GUI ASlider is used.

I just check wx 2.8.12 and the behavior of sliders is the same as in 2.8.11. I think this is a wxWidgets bug.

A long while back I did a lot of work on the wxSlider code for 2.9/3.0 but I do not recall messing with the response to keypresses. Setting up to compile the 2.9 SVN HEAD and samples is a lot of work and I am too tired to do it tonight. I have a lot on my platter for the next week or so but will try soon to see if this has been changed in 2.9 and if not I will file a wx bug.

(In reply to comment #3)
> For Freq Smoothing the up/down arrow keys are reversed (up arrow moves 
> the value lower though the right/left arrow keys are correct). If you 
> compare this with the  NR & Sensitivity dB values the up/down arrow 
> move the slider in the same direction
I don't see that on Win 7 or Ubuntu. I think each slider has to move the same way irrespective of context: Up and Left move the slider left; Down and Right move  the slider right. 

Thanks for the patches.

(In reply to comment #8)
Gale said:
"each slider has to move the same way irrespective of context: Up and Left move the slider left; Down and Right move the slider right."

       MIN=0         MAX=100
[ 50 ] __________ __________ 
                 ^

Push <LEFT ARROW> it makes sense for the slider knob to move left and the value to decrease. Push the <UP ARROW> it makes more sense to me for the value to "go up" and therefore the knob to move right. I also feel that <HOME> should go to the left and <END> to the right extremes (as they do). 

MIN=0
 |
 |
 |
 |
 |
>  [ 50 ]
 |
 |
 |
 |
 |
MAX=100

The only vertical slider I know of in Audacity is on the Mixer Board; bigger is up (in wx3.0 wxMSW vertical sliders will default to the Linux standard of bigger is down even though I disagreed and though the Linux ones should be changed to bigger==up ), it currently ignores the arrow keys. But if...press <UP ARROW> value should increase (unless is is reversed to match the new default/standard); the <LEFT|RIGHT ARROW> is a bit nebulous but I would propose that a <LEFT ARROW> here should respond like for a horizontal slider--i.e. decrease the value.  I feel that <HOME> should go to the upper and <END> to the lower extremes (as they do).

I looked back at the slider code I helped with for wxWidgets 3.0 and we did not address anything to do with response to arrow keys (though someone may have touched that code again--it has been almost a year since my patch).

I asked Bill Wharrie for a report on Mac behavior, he said:
"Tested with 1.3.13-alpha March 10 2011 PPC Mac. System Preferences set so that tab can select controls in dialog boxes.

On 16-Mar-11, at 10:24 PM, Ed Musgrove wrote:

> 	http://bugzilla.audacityteam.org/show_bug.cgi?id=227
>
> Generate a bit of noise
> Open the noise removal effect dialog
> Click the knob of the top (Noise reduction) slider
>
> What is the behavior on Mac if you now
> a)	Press <LEFT ARROW> (does the knob move? if so which way; does the
> textual value change? If so which way)

Right and Up arrow move slider to the right and the value increases.  
Left and Down arrow move slider to the left and the value decreases.
> 		Or
> b)	Press <HOME> (same questions)
> 		
>
The slider does not respond to the HOME or END keys

> Now, press <TAB> six times (does the lower {attack/decay} slider knob 
> have focus?)

Yes, if the System Prefs are set properly.

> If NOT, click on that knob to give it focus and
>     a) Press <LEFT ARROW> (does the knob move? if so which way; does 
> the textual value change? If so which way)

Pressing right-arrow almost always increments the value by 0.01, but sometimes increments it by 0.02. Pressing left- arrow sometimes does not decrement the value. A second press will decrement the value. So you get a sequence like .40 .40 .39 .39 .38 . 
37 .37 .36 .36 .35 .34 .34 ... If you press right-arrow after the repetition of a value going down, the value does not change on the first press but does change on the next press, then there are no double-presses of the right-arrow needed to increment the value.  
Moving up I can get .40 .41 .42 .43 .44 .45 .46 .47 .48 .49 .50 .52
(!) .53 .55 (!) ... .69 .70 .72 etc."
_________________________________

From this I propose that my patch be implemented for all 3 platforms and tested. I still have no way to determine if we need 1000 steps per second for attack/decay; if so use the 3 decimal place patch.

Gale said:
"each slider has to move the same way irrespective of context: Up and Left move
the slider left; Down and Right move the slider right."

I (Ed) said:
"Push <LEFT ARROW> it makes sense for the slider knob to move left and the value
to decrease.

Bill said, on Mac
"Left and Down arrow move slider to the left and the value decreases."

Obviously this is a wxWidgets foible and if I have anything to say about it (and I doubt that I will have much traction, but...) all three platforms will be made to behave as they do on Mac.

(In reply to comment #11)
And another way of looking at the distinction between sliders is: if a pair of horizontal and vertical arrow keys move the slider the same way on a horizontal slider, shouldn't they do so on a vertical (or all) sliders? 

On Windows and Ubuntu, the "pair" that does the same thing on a horizontal slider in an effect is "left/up" and "down/right". But on the Mixer Board vertical slider and Mixer Toolbar sliders, "left/down" and "up/right" move in the same direction. While that preserves "right arrow increases" that we have in a horizontal effect slider, to me that is much less important than preserving the pair that does the same "thing". So thinking further, I'd now actually go along with Ed, that up goes right and down goes left on a horizontal effect slider, even though I'm not used to it. 

But, are there any OS standards on this? From looking at other audio editors on Windows, it seems possibly not, but in Win 7 Windows Media Player, up moves the slider right in a horizontal slider.

(In reply to comment #12)
Gale said (in re. sliders):
"But, are there any OS standards on this?"
Linux has "standards", Windows does not and from what we could find out Mac has no published standards. Windows developers & MS software both seem to "tend" toward a standard (about 80% was what we determined by looking at a bunch of  3rd party apps and MS Office 2010) but it is contrary in points to the Linux standard (which seems to be very well supported by the Linux development community.

We never got a report back on Mac to see if there was any well recognized "unwritten" standard and did not have a Mac person who could do the work to bring the Mac sliders into compliance with the Linux standard (which we did do for Windows). The Mac code may have been touched since I last paid any attention to the situation--about a year ago.

I would be happy to share the "standard" we settled on if anyone is interested. As far as I know, the changes in wxWidgets sliders will not get into 2.8.x but most likely are in 2.9.x.

Ed, 

I tried both patches on Win 7 x64. Will have to try Linux later. 

The 3 decimal place solution certainly allows the slider to be fully manipulated with the arrow keys. I can't imagine anyone will hear the difference between an attack of 0.110 and 0.111 or welcome the slider slowness. 

The problem with the 2 decimal place solution would seem to make it unacceptable unless it can be fixed, but the problem isn't one of holding the arrow key down. Start from 0.00, right arrow one step at a time, stop when you get to 0.27, arrow again, it goes to 0.28; arrow again and it goes to 0.29 then jumps back to 0.28 on release. Same happens farther on - you cannot right arrow beyond 0.56. But you can left arrow all the way from 1.00 to 0.00. 

We should fix the Sensitivity slider too. For me that has two "locks" at -19.95 and -10.23 when right arrowing, but no problem left arrowing. I can't believe 2000 steps is useful for the Sensitivity slider. I know you can Page Up/Down, but even so. If having the same decimal point display as Attack/Decay is an issue, should Sensitivity have 200 steps, but display those as two decimal places? 


> Note that nowhere else except Effects (Nyquist??) in Audacity do the 
> sliders respond to <HOME>, <END> & <arrow keys>. I see that in Effects 
> wxSlider is used; in the main Audacity GUI ASlider is used.

The Toolbar sliders do I believe respond to arrow keys (and Page Up/Down), but you have to right-click to give the sliders focus first, so they certainly look as if they don't respond. I have a suggestion on how we could allow left clicking on GUI sliders then use the keyboard to move the sliders in bug 249#c1. Note that you can go to either end of the GUI slider (once focused) with the keyboard on Windows, but it requires CTRL + Home or CTRL + End, not Home or End.

(In reply to comment #14)
Gale said:
"I can't imagine anyone will hear the difference between an attack of 0.110 and 0.111 or welcome the slider slowness."

Someone made a decision to have 1000 steps between zero and one for this slider. I cannot attack nor defend that choice but would be willing to provide patches (although changing the code manually is simple) so that steps of 500, 300 or 200 (or any other values) could be played with. As for the weird "locks" Bill is seeing something similar on Mac without the patch. I may have some time late tomorrow to look at this again but am really too tired to think tonight!

#define SENSIVITY_MIN 0      // Corresponds to -20 dB 
#define SENSIVITY_MAX 4000    // Corresponds to 20 dB

#define GAIN_MIN 0
#define GAIN_MAX 48    // Corresponds to -48 dB

#define FREQ_MIN 0
#define FREQ_MAX 100    // Corresponds to 1000 Hz

#define TIME_MIN 0
#define TIME_MAX 1000   // Corresponds to 1.000 seconds

Note the Sensitivity slider has steps of 4000! I do not understand why.

The "lock" is the result of rounding in Format(). To see what is going on you can play with the code a bit. in src/effects/NoiseRemoval.cpp near line 753:

#define TIME_MIN 0
#define TIME_MAX 125//1000   // Corresponds to 1.000 seconds//efm5
#define TIME_MAXf 125.0//1000   // Corresponds to 1.000 seconds//efm5   ADD THIS!

and again near line 1018:


void NoiseRemovalDialog::OnTimeSlider(wxCommandEvent & event)
{
   //mTime = mTimeS->GetValue() / 1000.0;
   mTime = mTimeS->GetValue() / TIME_MAXf;//efm5     CHANGE THIS!
   mTimeT->SetValue(wxString::Format(wxT("%.3f"), mTime));//efm5
}

Now, changing only these two #defines ( TIME_MAX & TIME_MAXf -- they must be equal) you may play around with the stepping for attack/decay (let's ignore Sensitivity for the time being--it is the same problem).

With the decimal places set to 3, there are a few values for TIME_... which do not "lock" these are 1000, 500, 250, 125 (strangely enough, 100 & 50 both lock) 25 and 10.

To change the decimal places look near line 955:

   mTimeT->SetValue(wxString::Format(wxT("%.2f"), mTime));//efm5
and near line 1021:
   mTimeT->SetValue(wxString::Format(wxT("%.2f"), mTime));//efm5

In both places the "%.Xf" needs to be the same: "%.2f" or "%.3f".

With the decimal places set to 2 it will ALWAYS fail by seeming to ignore the arrow keys or will "lock".

Moral of the story, set decimal places both to 3 and pick a MAX_... value pair which yields suitable speed of movement in response to holding the arrow key down. MAX of 1000 gives 1000 steps of .001; 500 gives 500 steps of .002; 250 gives 250 steps of .004; 125 gives steps of .008; 25 & 10 are too granular.

On my blazingly fast system 1000 moves quite fast enough to suit me but Gale seems to think it too slow..

(In reply to comment #15)

> Note the Sensitivity slider has steps of 4000! I do not understand why.
> 

Yes, it should have been documented. I suggest you use SVN Blame command to find out who made that choice, then ask him.

(In reply to comment #17)
Thanks Vaughan, I had never learned how to use svn blame so I had to look it up; always good to learn a new trick!

10512 james.k.crook #define SENSIVITY_MIN 0      // Corresponds to -20 dB
10512 james.k.crook #define SENSIVITY_MAX 4000    // Corresponds to 20 dB

then later:
 10512 james.k.crook    mSensitivityS->SetValue(TrapLong(mSensitivity*100.0 + 2000.0, SENSIVITY_MIN, SENSIVITY_MAX));

looking at the "lock" problem for Sensitivity more closely I can watch the error occur but am not sure how to fix the problem.

When we start at -20.00dB and press <RIGHT ARROW> six times the (correct) value -19.94 shows while the key is down but -19.50 shows when the key is raised.

I have stuck in some interim variables so that one may inspect each step of the calculation in the debugger:

void NoiseRemovalDialog::OnSensitivitySlider(wxCommandEvent & event)
{
   int val = mSensitivityS->GetValue();//efm5 debug
   double dec = val / 100.0;//efm5 debug
   double ms = dec - 20.0;//efm5 debug

   mSensitivity = mSensitivityS->GetValue()/100.0 - 20.0;
   mSensitivityT->SetValue(wxString::Format(wxT("%.3f"), mSensitivity));//efm5
}
mSensitivity is -19.940000000000001 -- close enough. The call to mSensitivityT->SetValue() above forces us into OnSensitivityText():


void NoiseRemovalDialog::OnSensitivityText(wxCommandEvent & event)
{
   wxString val = mSensitivityT->GetValue();//efm5 debug
   mSensitivityT->GetValue().ToDouble(&mSensitivity);
   double sen = mSensitivity*100.0 + SENSIVITY_MAXf;//efm5 debug
   int d2iSen = (int)sen;//efm5 debug
   long ld2iSen = TrapLong(d2iSen, SENSIVITY_MIN, SENSIVITY_MAX);//efm5 debug
   long lSen = TrapLong(mSensitivity*100.0 + SENSIVITY_MAXf, SENSIVITY_MIN, SENSIVITY_MAX);//efm5 debug
   //if ((sen > 5.9) && (sen < 6.0)) d2iSen = 6;//efm5 debug[*0]
   //mSensitivityS->SetValue(ld2iSen);//efm5 debug [*1]
   //mSensitivityS->SetValue(TrapLong(mSensitivity*100.0 + SENSIVITY_MAXf, SENSIVITY_MIN, SENSIVITY_MAX));//efm5 original code
   mSensitivityS->SetValue(lSen);//efm5 debug [*3]
}
here the debugger shows:
val is the string "-19.940" (which is correct)
sen is 5.9999999999997726 (again, close enough)
lSen is 5 (but it should be six!)

If you comment out [*3] and un-comment [*0&1] the lock is bypassed but we hit another one after more arrow presses. It seems that conversion from double to int sometimes truncates instead of rounding. I have no idea why nor how to fix it!

In light of this I suspect that my proposed "fix" for the Attack/Decay slider really just masks the problem and does not fix it really. In light of this I retract my patch and proposal and apologize to all for all the wasted time reading my meanderings.

I think this might explain why negative numbers are acting oddly:

http://www.cs.tut.fi/~jkorpela/round.html

Rounding conversion means that we get the integer which is nearest to the floating-point value, so that e.g. 3.9 is converted to 4. This is usually what people want when they ask the question we are dealing with. There is no direct tool (like an operator or a library function) for rounding conversion, and strictly speaking a rounding conversion is not a conversion in the same sense that those conversions which are defined in the C standard.
For positive floating-point values, the simplest way to achieve a rounding conversion is to use an expression like

                (long) (x+0.5)
but it is better to be prepared for negative values, even if you do not expect them to occur. This means that one should use the conditional expression
x >= 0 ? (long)(x+0.5) : (long)(x-0.5)
The value of this is expression is the integer which is nearest to the value of the floating-point value of x.
One can of course write a macro like

#define round(x) ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))
if one needs rounding conversions a lot or wishes to make code somewhat more readable.
Notice that this means that the rounded value of 1.5 is 2 and the rounded value of -1.5 is -2. You might wish to have some other treatment for a value which is exactly between two integers. The issue is, however, not very important practically.

Beware that a conversion of a floating-point value to an integer can cause overflow and that most implementations give no diagnostic in such cases. Using long instead of int may (or may not) give you a wider range of integers, but it is still smaller than the range of floating-point numbers. (Using long is recommendable.)

If efficiency is not crucial, it is a good idea to make your program more robust by defining (instead of the simple #define above) the function

   long round(double x) {
      assert(x >= LONG_MIN-0.5);
      assert(x <= LONG_MAX+0.5);
      if (x >= 0)
         return (long) (x+0.5);
      return (long) (x-0.5);
   }
or, if efficiency is crucial, the macro
#define round(x) ((x) < LONG_MIN-0.5 || (x) > LONG_MAX+0.5 ?\
error() : ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))
This requires that you have #include <limits.h> and that you have an error handling routine called error which is a function of type long.
Jukka Korpela
September 19th, 1996

Created attachment 129 [details]
fix both Sensitivity & Attack/Decay

I chose to
#define roundPosNeg(x) ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))

because round(x) is already #defined differently in the code; I did see:

inline int wxRound(double x)
    {
        #if defined(HAVE_ROUND)
            return int(round(x));
        #else
            return (int)(x < 0 ? x - 0.5 : x + 0.5);
        #endif
    }

but did not want to run in to problems with if defined(HAVE_ROUND)...

I learned a lot on this!

Thanks for your efforts, Ed. I tried on Win 7 and Ubuntu and all works fine. I would "prefer" the old 100th steps and 2 decimal places for Attack/Decay I must say, although the 3/1000th steps keep the slider reasonably nippy. What do you think? I don't see any interest expressed here in changing the old accuracy.

(In reply to comment #21)
Gale said:
"I would "prefer" the old 100th steps and 2 decimal places for Attack/Decay"

First, the "old" steps were 1000 not 100 but the 2 decimal place display truncated any change making the arrows ignored.

To test 100 steps use:

#define TIME_MAX 100//1000   // Corresponds to 1.000 seconds//efm5
#define TIME_MAXf 100.0//1000   // Corresponds to 1.000 seconds//efm5   ADD
THIS!

You don't need to change the %.3f for testing, it just adds an insignificant zero on the end (i.e. 0.420) but...

To change the decimal places look near line 955:

   mTimeT->SetValue(wxString::Format(wxT("%.2f"), mTime));//efm5
and near line 1021:
   mTimeT->SetValue(wxString::Format(wxT("%.2f"), mTime));//efm5

In both places the "%.Xf" needs to be the same: "%.2f" or "%.3f".

Gale said:
"I don't see any interest expressed here in changing the old accuracy"

I sent e-mail to James asking why the high values for MAX by have heard nothing--I think I am in his spam filter--I'm too wordy!

(In reply to comment #14)
Gale wrote:  
I can't imagine anyone will hear the
difference between an attack of 0.110 and 0.111

I'm fussy when using Noise Removal, but 2 decimal places for Sensitivity and Attack/Decay is quite sufficient for me. 3 decimal places seems like overkill and often small changes (for example changing Attack/Decay from 0.002 to 0.006) will produce no difference to the output.

All the sliders are now responding to the mouse wheel and cursor keys here (Ubuntu 10.10).

> I sent e-mail to James asking why the high values for MAX but have heard
> nothing--I think I am in his spam filter--I'm too wordy!

@Ed, Sorry - I don't know what happened there.


 Date: Sun Jul  4 04:34:51 2010
 Log: Noise removal updates from Marco Diego Aurélio
 http://code.google.com/p/audacity/source/detail?r=10512

 -#define TIME_MAX 100   // Corresponds to 1.00 seconds
 +#define TIME_MAX 1000   // Corresponds to 1.000 seconds

So I was passing on a change from a contributor.  I agree with Steve and Gale and Ed that 100 steps is plenty.  The only reason I can see for wanting finer steps is if at one end of the range small steps had a large proportional effect.  It sounds like that is not so.  In any case such situations are better tackled with a log scale.

I say we go for 100 steps.  Thanks everyone who has looked at this issue.  It's good we don't just ignore P4s.

James wrote: 
> I say we go for 100 steps.
Thanks. I've tried out Ed's attached patch on Windows 7 but now modified as per his suggestion:

#define TIME_MAX 100//1000   // Corresponds to 1.000 seconds//efm5
#define TIME_MAXf 100.0//1000   // Corresponds to 1.000 seconds//efm5   ADD
THIS!

and near line 955:

   mTimeT->SetValue(wxString::Format(wxT("%.2f"), mTime));//efm5

and near line 1021:

   mTimeT->SetValue(wxString::Format(wxT("%.2f"), mTime));//efm5

This works perfectly IMO. We can't QA-test on Mac without committing it, so can we do so? Ed's worked very hard on this, I think.

@James--I had some stale indigo @dress for you--my bad!

Marco Diego Aurélio has posted to -dev recently:
http://audacity.238276.n2.nabble.com/Spectral-subtraction-for-AudNR-td6182952.html; I'm not on the -dev list, would someone like to querry him?

Gale said:
"We can't QA-test on Mac without committing it, so can we do so? Ed's worked very hard on this, I think."

I really had fun learning in the discovery process! Isn't there some active Developer using Mac?

Ed,

sorry to be stickler for detail, but I'd like:

+   double dSensitivity = mSensitivity*100.0 + SENSIVITY_MAXf;
+   long lSensitivity = roundPosNeg(dSensitivity);
+   long sensitivity = TrapLong(lSensitivity, SENSIVITY_MIN, SENSIVITY_MAX);
+   mSensitivityS->SetValue(sensitivity);

and similar to be done all on one line without the extra variables.  Other than that coding style looks fine.

Sorry to people who have tested this, as it will mean a retest.

(In reply to comment #27)
James said:
"I'd like [...] all on one line without the extra variables"

I do not have commit privileges. You or some other Developer will need to review the code and commit it; if the reviewer wants to make changes they will. Putting all the stuff on one line makes the code hard to read and impossible to debug; if forced to do so, I will under protest <grin>.

Checked into SVN 
Rev 11013.

@Ed: Do have a look at how I changed your patch.

(In reply to comment #29)
Cool, thanks!

(In reply to comment #26)
> Isn't there some active Developer using Mac?
Yes, but no QA person on Mac who can compile at the moment.

It tests fine on Windows and Ubuntu. Someone should test it on Mac though before declaring it "fixed".

(In reply to comment #32)
On Mac PPC 10.5.8 and Audacity 1.3.13rc3

The sliders (mostly) respond properly to the arrow keys.
Up-arrow = right-arrow and down-arrow = left arrow.
None of the sliders respond to the home or end key, nor to the mouse wheel.
All sliders can be dragged with the mouse.
The sensitivity slider is still a little wonky. Above 0, up-arrow moves in increments of about 0.6 (0.00 > 0.60 > 1.19 > 1.79) but down-arrow moves in increments of about 0.3 (1.79 > 1.49 > 1.19 > 0.90 > 0.60 > 0.30 > 0.00). Below zero the left and right-arrow keys both move the value by about 0.30.
The Attack/decay slider still has a couple of minor glitches: it mostly moves in increments of 0.01 in response to the right-arrow key, but does 0.70 > 0.72, 0.79 > 0.81, 0.85 > 0.87, 0.90 > 0.92 0.93 > 0.95, 0.96 > 0.98. Down-arrow always decrements by 0.01.

(In reply to comment #33)
> None of the sliders respond to the home or end key, nor to the mouse wheel.
OK. But I believe that is a general statement for all effects on Mac, and it's at bug 139 at the moment, though maybe the bug title isn't very good.   

> The sensitivity slider is still a little wonky. Above 0, up-arrow moves in
> increments of about 0.6 (0.00 > 0.60 > 1.19 > 1.79) but down-arrow moves in
> increments of about 0.3 (1.79 > 1.49 > 1.19 > 0.90 > 0.60 > 0.30 > 0.00). 
> Below zero the left and right-arrow keys both move the value by about 0.30.
> The Attack/decay slider still has a couple of minor glitches: it mostly moves
> in increments of 0.01 in response to the right-arrow key, but does 0.70 > 0.72,
> 0.79 > 0.81, 0.85 > 0.87, 0.90 > 0.92 0.93 > 0.95, 0.96 > 0.98. Down-arrow
> always decrements by 0.01.
I've re-checked that on Windows and all four arrow keys for both sliders always move by 0.01 and don't misbehave at the values where they do for you. 

How about Page Up/Page Down for you, Bill? On Windows I see those increment equally by 4.0 for Sensitivity and and 0.1 for Attack/Decay.

I've re-opened as a Mac-only P5 "Noise Removal: Sensitivity, Attack/Decay sliders don't respond finely enough/evenly to arrow keys".

(In reply to comment #34)
> How about Page Up/Page Down for you, Bill? On Windows I see those increment
> equally by 4.0 for Sensitivity and 0.1 for Attack/Decay.

No response to the Page Up/Down arrows on Mac.

wxSliders are known to be buggy on Mac:
[wx-dev] Re: #4555: wxSlider cannot reach full area on OS/X

Without access to a Mac I cannot really say if any of Bill's problems are due to wx code or Audacity code.

I do note that I think Jame's patch did not quite honor my solution in re. rounding of negative values but I can't really tell as the code is so condensed.

Should this bug be closed as obsolete, given the major changes in 2.1.0 Noise Reduction?

Or is there a more general complaint about wxWidgets sliders that remains?

(In reply to Paul L from comment #37)
This has remained open as "Devel Fix Made" for over 4 years!

Time to close it as obsolete.

(In reply to Steve Daulton from comment #38)
> This has remained open as "Devel Fix Made" for over 4 years!
Not correct. See http://bugzilla.audacityteam.org/show_activity.cgi?id=227 and comment 34 where the bug was reopened. 

And I'm reopening it again, P4 but with a more general title, changed from "Noise Removal: Sensitivity,Attack/Decay sliders don't respond finely enough/evenly to arrow keys" to "Built-in effect sliders don't respond correctly to arrow keys".  

"Noise reduction (dB)" and "Sensitivity" decrement with arrow keys at greater values than they increment.

"Frequency smoothing (bands)" only responds to arrow keys in one fashion, which is to use Page Up, then LEFT or DOWN arrow to decrement.  

I see similar but not necessarily identical behaviour in sliders in Compressor and Wahwah, but not in sliders in Nyquist effects. 

Set a block on Bug 139.

Testein on macOS 10.13.6 with latest alphas 

I can't get the arrow keys to move the sliders at all - but it happily works on W10 for me,

*** STEPS UPDATED ***

To save people having to read 40 comments concerning past history back to 2010.

Testing with 2.3.2 on macOS10.14.5

When I tab to the sliders in Noise reduction
a) they light up (to show active state)
b) the respond to the left/right arrow keys
c) the movement is mirtrored in the numbe boxes

Tested with Amplify and Wahwah as well to check and their sliders respond pororly to L/R jeys when active by tabbing into.