Audacity Forum

Gale Andrews wrote: There is still the question of incorrect reduction of level to the tone, if you do complete the steps. I have not seen that yet on Mac. Could (any) effect become confused by the failed Undo in some way that could lead to unexpected results?


Gale

I think the Undo bug is simply the Undo command silently doing nothing at all and not changing the state of the project in any way. So I would guess not, and that there is something else to debug here. After all you said you saw the other problem on Windows without the Undo problem.

I can confirm that there is a bug in "Undo" where Ctrl+Z fails to undo, and Edit > Undo also fails.
I first noticed this quite some time ago, well before 2.0.5, but on Linux it is quite rare and I have never found reliable steps to reproduce.

When it does occur, "Undo" can be actioned by opening "View > History" and clicking on the previous state in the history list.

Repeating Gales steps several times did trigger the issue

* I have observed this issue with commands other than Noise Removal.

* I have observed the issue in both debug and release builds.

I would describe it as "Undo gets "stuck" at some point in the history list".
Mostly I have observed this issue when working with Audacity (rather than testing), so my attention is focussed on the audio production task rather than on the precise sequence of events leading up to the issue. When attempting to purposefully recreate the issue, it has not occurred, so I have not previously had repeatable steps. The steps that Gale lists are the most repeatable that I have yet observed. Even those do not always trigger the issue, but I think we now have enough to log it in bugzilla.

Possibly (but not necessarily) related:
When using Nyquist Workbench, Audacity sometimes becomes completely unresponsive to all keyboard shortcuts. The keyboard shortcuts can be reactivated by opening and closing Preferences.

I think that "Undo" can also be "reactivated" by opening and closing Preferences, but (on my machine) it is difficult to reproduce the problem regularly enough to prove this one way or the other.

I do recollect seeing the Undo bug on Windows in 2.0.5. I have not seen anything I would call a "white flash" though.

Cut lines: I found enough evidence that they are involved in this bug. The cursor change for cut lines somehow correlates with it. And I think I saw evidence that when Undo is in the stuck state, it might get un-stuck if you can make the cursor change in the track panel, such as by clicking in the backgound where there are no tracks.

steve wrote:working with Audacity (rather than testing)

I must try that some time.

steve wrote:Possibly (but not necessarily) related:
When using Nyquist Workbench, Audacity sometimes becomes completely unresponsive to all keyboard shortcuts. The keyboard shortcuts can be reactivated by opening and closing Preferences.

OK that one is already at http://bugzilla.audacityteam.org/show_bug.cgi?id=516 .

I have only seen the "white flash" on Mac.

Gale

I've not seen the "white flash".

Paul, did you follow through with the steps on Windows and see if the tone was excessively reduced? Try half a dozen times at least if you can.

Also I've noticed that when Undo fails or sometimes when the tone is reduced, zero bytes TMP files are written to the folder I run Audacity from. This may be because I had the folder open.


Gale

Gale Andrews wrote:Paul, did you follow through with the steps on Windows and see if the tone was excessively reduced? Try half a dozen times at least if you can.

Also I've noticed that when Undo fails or sometimes when the tone is reduced, zero bytes TMP files are written to the folder I run Audacity from. This may be because I had the folder open.


Gale

Gale, I tried it today.

Do you think it is necessary to use the Noise Removal dialog and not use "Repeat Noise Removal?"

Certainly if I select the whole track, open the Noise Removal Dialog, hit Get Noise Profile, undo (which does NOT forget the noise profile statistics), open the dialog again, and then hit OK (with settings -48, 0, 150, 1.0) -- then I see the noise reduced to a peak of about 55 dB and the sine tone reduced to -48 dB.

Were you pressing buttons with the mouse to dismiss the dialog each time? Or did you hit Return or Enter?

Perhaps there is a bug in user interface code that does not place the keyboard focus always on the same button when the dialog opens.

What I see right now is that Get Noise Profile has focus, even if I had pressed OK the last time. I must tab ten times or shift-tab three times to get to OK.

You might have made a user error by hitting Return expecting the effect to apply, but instead taking the whole track as noise profile (which is NOT part of undo-able state of the project). Then when you next did hit OK, everything was reduced.

Notice that when you first call up Noise Removal after restarting Audacity, the Preview and OK buttons are disabled. You can't do the effect because there is no defined profile yet.

If we can do that, then we can also figure out how to focus the enabled OK button when there is a profile. Then you can open the dialog and hit OK without surprises. This would make this effect consistent with most other effects that take effect with the default or last-used settings if you just hit Return.

I think this little inconsistency merits a Bugzilla issue so we don't forget it.

Agreed?

I let my other projects of spectral selection and seeking & scrubbing distract me for a while.

But at last today I put up a patch at the developers' board containing many of my ideas for fixes and improvements. No attempt at spectral subtraction.

Now I need to figure out how to make Gale happy with a plan for bug tracking and testing.

Hi Paul!

Great work here and elsewhere on the Audacity project. I'm trying out your new Noise Reduction affect on Windows 7. I have even back ported it to Audacity 2.0 so that my clients have access to it.

While I realize that the experimental wxWidgets 3.0 configurations (which are currently available in SVN HEAD as 2 of the 4 available configurations for MSVS2013) are not really "supported", I do believe that it is important for them to compile successfully. NoiseReduction.cpp fails to compile in the wx3-Release configuration with 54 errors and 150 warnings; since the wx3-Debug configuration compiles this is clearly a simple header include problem:
#include <wxtextctrl.h>
added after the last wxWidgets #include resolves the issue.