Bugzilla – Bug 516
Keyboard shortcuts may fail after running Nyquist Workbench
Last modified: 2019-05-11 11:52:36 UTC
Keyboard shortcuts intermittently stop working (Debian Linux) I have been unable to identify any specific steps to reproduce the problem, it seems quite random (though quite frequent - likely to happen once or twice during an editing session). Keyboard control is usually restored by opening and closing Preferences. The appearance of this issue seems to match with the recent work on effect shortcuts for Windows (though this could be a coincidence).
No release note provided, so not a P3.
I was in the middle of a recording job and pressed Ctrl+M to drop a marker. Nothing happened. On investigation the shortcut had changed to Ctrl+Shift+F6 The keyboard shortcuts had been reset to defaults last night due to loss of keyboard control. I rely heavily on keyboard shortcuts so it is extremely inconvenient that they keep changing. I've added a release note and raised the priority to P3. Audacity should really not be released with this problem as it is not suitable for production work.
If you had defaulted shortcuts in Prefs then cancelled as per bug 515, Add label at Playback Position would have changed to CTRL + F6 and Add Label at Selection to SHIFT + CTRL + F6. This is a close match to what you see. Is it possible that actually using a shortcut does the same as "Defaults" then Cancel? Is your reported SHIFT + CTRL + F6 for Add Label at Playback Position and all the incorrect shortcuts cited in bug 515 actually appearing in the menus? We can probably raise this to P2 if you can find steps to repro. Please note correct syntax for Release Notes. Your comment seems to suggest that the problem happened after a reset of shortcuts to Defaults, so I am not sure that resetting them is more than a very temporary workaround?
(In reply to comment #3) > If you had defaulted shortcuts in Prefs then cancelled as per bug 515 Sorry, that meant bug 517!
I can reproduce this bug if I use Nyquist Workbench and it looks like it may be related to bug 423. 1) Run a Nyquist effect (for example CrossFade In) on an audio track 2) Run a named, process (effect) plug-in in Nyquist Workbench, where the name is before the name of the effect in step 1 in alphanumeric order. For example, run the following code in the Nyquist Workbench: ;name a ;type process ;control test "test" real "" 0 1 1 s (does nothing except return the audio to the track). Keyboard control is now gone. The Effect menu lists "a" as the "Repeat" effect. This also occurs in Revision 11645 If the Nyquist Workbench effect is then run with the name changed to a letter that is after the effect in step 1, then keyboard control returns. For example, run: ;name z ;type process ;control test "test" real "" 0 1 1 s The Effect menu lists "z" as the "Repeat" effect. This may not be the only way to trigger the bug, but it is a repeatable method. Q1. Is it necessary that Audacity "registers" the name of an effect that is run in the Nyquist Workbench? Would it be better if the Audacity menu system identified Nyquist Workbench as an "effect" called "Nyquist Workbench" (so that the Effect menu Repeat option listed "Nyquist Workbench")? Would that also resolve bug 423? Q2. Will this problem also occur with other modules?
I've only been able to reproduce this bug when using Nyquist Workbench as described in previous comment, so I've changed the bug summary.
Marked platform as "All". I've only tested on Linux, but unless found to not occur on other platforms I would expect this bug to be platform independent.
(In reply to comment #6) If this only occurs after using Nyquist Workbench I think it should be demoted to P4. Done. If we later decide it is P3, I have parked a more accurate Release Note at the bottom of the Steps to Reproduce.
This appears to be fixed in 2.1.1 alpha.
Marked resolved on the basis of Steve's testing from 4 years ago
