Context
PR #2905 added LOCKED visual feedback to the VFO and RX applet frequency displays when tuning is blocked by the slice lock. That's the right primary cue for most paths — wheel, direct entry, band shortcut — because the user's attention is already near the VFO when they take that action.
But for keyboard step, MIDI knob, and HID knob, the user's attention may be on the spectrum, the controller, or elsewhere. They may not notice "LOCKED" flashing in a frequency display they aren't looking at.
The memory-recall path already shows a status-bar toast:
`statusBar()->showMessage("Unlock the target slice before recalling a memory.", 3000);`
Keyboard/MIDI/HID should get the same belt-and-suspenders treatment.
Proposal
Add status-bar messages to the three paths in `MainWindow.cpp`:
- `nudgeFreq` (keyboard step) in `registerShortcutActions()` —
`"Slice is locked — unlock to tune."`
- `rx.tuneKnob` MIDI handler —
`"Slice is locked — unlock to tune via MIDI."`
- MIDI absolute fallback in `registerMidiParams` — same message
- HID coalesce timer — `"Slice is locked — unlock to tune."`
Show each only once per "session of blocked attempts" rather than every keypress, so a stuck knob doesn't spam the status bar. Two ways to implement that:
- Per-path latch — each path keeps a small `m_lastBlockedMs` and only shows the message if >2s have elapsed since the last show
- Drive it off the new `lockedFeedbackActive` signal if issue #2983 lands first — show the message on the false→true transition only
If #2983 lands first, option 2 is cleaner. If this issue is picked up first, option 1 is fine and the dedup can be folded into the #2983 refactor later.
Why this matters
A user with a paddle or MIDI controller can spin a knob for several seconds without realizing the slice is locked, then wonder why nothing is happening. A status-bar toast on first attempt teaches the cause; the visual LOCKED in VFO catches them once they look back at the GUI.
Effort
~1 hour: identify the 3-4 dedup sites, add per-path latches (option 1), test by triggering each path with the slice locked.
References
Context
PR #2905 added LOCKED visual feedback to the VFO and RX applet frequency displays when tuning is blocked by the slice lock. That's the right primary cue for most paths — wheel, direct entry, band shortcut — because the user's attention is already near the VFO when they take that action.
But for keyboard step, MIDI knob, and HID knob, the user's attention may be on the spectrum, the controller, or elsewhere. They may not notice "LOCKED" flashing in a frequency display they aren't looking at.
The memory-recall path already shows a status-bar toast:
`statusBar()->showMessage("Unlock the target slice before recalling a memory.", 3000);`
Keyboard/MIDI/HID should get the same belt-and-suspenders treatment.
Proposal
Add status-bar messages to the three paths in `MainWindow.cpp`:
`"Slice is locked — unlock to tune."`
`"Slice is locked — unlock to tune via MIDI."`
Show each only once per "session of blocked attempts" rather than every keypress, so a stuck knob doesn't spam the status bar. Two ways to implement that:
If #2983 lands first, option 2 is cleaner. If this issue is picked up first, option 1 is fine and the dedup can be folded into the #2983 refactor later.
Why this matters
A user with a paddle or MIDI controller can spin a knob for several seconds without realizing the slice is locked, then wonder why nothing is happening. A status-bar toast on first attempt teaches the cause; the visual LOCKED in VFO catches them once they look back at the GUI.
Effort
~1 hour: identify the 3-4 dedup sites, add per-path latches (option 1), test by triggering each path with the slice locked.
References