feat(midi): register QSO Record and Playback as learnable MIDI params (#2844)#2845
Conversation
…aethersdr#2844) Adds two P::Toggle entries to registerMidiParams() that mirror the exact dual-routing used by the VFO record/play buttons (MainWindow.cpp:11413-11443): RecordingMode=="Client" routes through QsoRecorder; any other mode routes through SliceModel::setRecordOn / setPlayOn (radio-side), so a MIDI button behaves identically to the on-screen ⏺ / ▶ widgets in both recording modes. global.qsoRecord — "QSO Record" (Global category) global.qsoPlay — "QSO Playback" (Global category) Getter lambdas reflect live state so bidirectional MIDI controllers (Akai APC, Behringer X-Touch, etc.) can keep LEDs in sync. Closes aethersdr#2844 Related: aethersdr#2841 / aethersdr#2842 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
d499a3d to
50d603c
Compare
There was a problem hiding this comment.
Thanks @M8WLO — nice, focused gap-fill. The two new reg(...) entries faithfully mirror the existing VFO ⏺/▶ routing at MainWindow.cpp:11413-11443, including the RecordingMode=="Client" switch between QsoRecorder and SliceModel::setRecordOn/setPlayOn. That's exactly the right shape — anything else would have created a second source of truth for record/play behaviour.
Spot checks:
- Naming
global.qsoRecord/global.qsoPlayand the"Global"category line up with the surrounding entries (global.masterMute,global.txButton, etc.) atMainWindow.cpp:14694-14702. AppSettings::instance().value("RecordingMode", "Radio")matches the convention (no strayQSettings).m_qsoRecorderis allocated in the ctor atMainWindow.cpp:1302and parented tothis, so the unguarded calls in the setters are consistent with the existing VFO handler. The getter's defensivem_qsoRecorder &&check is fine — a slight asymmetry but it just defaults the read to 0.activeSlice()returning nullptr is correctly handled byif (auto* s = activeSlice())on the radio-side branch.
One small note (not blocking): the PR body has a template-substitution glitch (${PR_DIFF}${PR_DIFF} where && should be), and the snippet shown there isn't quite the code that was actually committed. The committed diff is the correct version — the body just looks confusing if anyone reads it standalone. Worth tidying the description when convenient.
LGTM otherwise.
jensenpat
left a comment
There was a problem hiding this comment.
Thanks for new MIDI recording controls
…aethersdr#2844) Adds two P::Toggle entries to registerMidiParams() that mirror the dual routing used by the VFO record/play buttons: RecordingMode=="Client" routes through QsoRecorder; any other mode routes through SliceModel::setRecordOn / setPlayOn so MIDI buttons behave identically to the on-screen controls in both recording modes. global.qsoRecord exposes QSO Record in the Global category, and global.qsoPlay exposes QSO Playback. Getter lambdas reflect live state so bidirectional MIDI controllers can keep LEDs in sync. Closes aethersdr#2844 Related: aethersdr#2841 / aethersdr#2842 Squashed-from: aethersdr#2845 Co-authored-by: M8WLO <50511950+M8WLO@users.noreply.github.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: jensenpat <patjensen@gmail.com>
Summary
qso.recordandqso.playas MIDI-learnable parameters inMainWindow::registerMidiParams()P::Toggle— MIDI note-on (value > 0.5) starts, note-off stops; momentary pads work correctly in latch modeWhat was missing
registerMidiParams()(src/gui/MainWindow.cpp) had ~80 entries covering RX, TX, Phone/CW, EQ, Mode, Band, and Global controls, but no entries for the QSO recorder.m_qsoRecorder->startRecording()etc. were only reachable via the VFO widget buttons — invisible to the MIDI dispatch path entirely.Implementation
Test plan
Closes #2844
Related: #2841 (companion TCI gap fixed in #2842)
🤖 Generated with Claude Code