#1 (bug) — mutual exclusion: setMnrEnabled now disables all other NR modes
    before enabling MNR; every other NR setter (NR2/RN2/NR4/BNR/DFNR) now
    also calls setMnrEnabled(false) in its mutual-exclusion block.

aethersdr#2 (bug) — RADE guard: setMnrEnabled early-returns when m_radeMode is active,
    matching the pattern used by all other NR setters.

aethersdr#3 — raw pointer → std::unique_ptr<MacNRFilter>: AudioEngine.h gains a
    forward declaration (#ifdef __APPLE__) and unique_ptr member; AudioEngine.cpp
    already had the full include; new/delete replaced with make_unique/reset.
    std::atomic<float> m_mnrStrength replaces plain float.

aethersdr#5 — MacNRFilter.h: processing-chain comment corrected from
    "stereo int16 → … → stereo int16" to "stereo float32 → … → stereo float32";
    also fixes the process() doc-comment.

aethersdr#6 — MacNRFilter: m_strength changed to std::atomic<float>; setStrength/
    strength() use store/load; processFrame() reads m_strength.load().
    Allows AudioEngine to write strength from the audio thread while the
    DSP dialog reads it from the UI thread without a data race.

aethersdr#8 — strength persistence: setMnrEnabled(true) restores m_mnrStrength from
    AppSettings("MnrStrength"); setMnrStrength() now saves to AppSettings
    on every change, so the value survives restarts.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…ultiFLEX on; pipeline subs) (aethersdr#3391)

## What

Two independent latency wins on the radio **connect handshake** — the
dominant stage of time-to-first-panadapter-frame on a warm launch. No
new dependencies, no protocol additions, ~33 lines net in
`RadioModel.cpp`.

### 1. Skip the 400 ms multiFLEX conflict peek when `mf_enable=1`
`peekForMultiFlexConflictThen` subscribes to radio/client topics, then
waits a fixed `QTimer::singleShot(400)` for the client-status burst
before sending `client gui`. But the conflict check is
`!m_multiFlexEnabled && hasOthers` — when multiFLEX is **enabled**, the
radio explicitly allows multiple GUI clients, so no conflict is possible
and that 400 ms is pure dead time. `mf_enable` arrives in the radio
status burst triggered by the preceding `sub radio all`, so
`m_multiFlexEnabled` is already set when the callback runs; we proceed
immediately. The mf-**disabled** path keeps the original 400 ms wait, so
conflict detection is unchanged where it actually matters.

`onConnected → first pan stream id`: **~851 ms → ~423 ms**

### 2. Pipeline the first subscription batch
`sub slice all → … → sub xvtr all` was one nested `sendCmd` per command,
each awaiting its `R` response — ~11 serial round trips (~0.7 s on a
LAN). The radio processes TCP commands in send order, and the **second**
sub batch in this same function (`sub tnf/dax/codec/…`) already fires
without waiting, so the per-command serialization was gratuitous.
Flattened to back-to-back fire-and-forget, matching the existing
pattern.

`first pan stream id → subscriptions ACKed`: **~985 ms → ~71 ms**

## Applies to LAN, remote IP, and SmartLink — and helps remote *more*

The subscription pipelining (aethersdr#2) lives in `registerAsGuiClient`, which
is shared by **every** connection type. `onConnected` reaches it from
both branches — LAN via `peekForMultiFlexConflictThen(…)`, and remote IP
/ SmartLink (WAN) via `sendCmd("client ip", … registerAsGuiClient)` —
and `sendCmd` routes to `m_wanConn->sendCommand()` over the SmartLink
TLS tunnel when WAN is active, or the LAN socket otherwise. Same
flattened subs on all paths.

The win is "11 serial round-trips → one burst," so it scales with
per-RTT latency: on LAN that's ~60 ms/RTT (~0.7 s saved), but over a
routed/SmartLink link at 50–200 ms+/RTT the serial chain can cost 1.5–3
s, making the absolute saving **larger on remote flows**.
Order-preserving pipelining is already proven for the WAN tunnel — the
existing second sub batch fires-and-forget through this exact path.

The peek skip (aethersdr#1) is **LAN-only** by construction: the WAN/SmartLink
branch never runs the peek (it does a `client ip` round-trip instead,
and multiFLEX conflicts on WAN are caught pre-connection via
`licensedClients`). So aethersdr#1 is a no-op there — no benefit, no regression.

## Impact

Combined handshake (**TCP connected → subscriptions ACKed**): **~1810 ms
→ ~494 ms** on LAN.

Measured warm launch → first panadapter frame: **~3.2 s → ~2.3 s** on a
FLEX-8400M over LAN. (A "warm" launch = consent already granted; a cold
first launch is dominated by the macOS local-network/mic consent
dialogs, which are one-time human interaction and not representative.)

**Remote IP / SmartLink numbers are not yet measured** (tested on a LAN
FLEX-8400M only); pipelining aethersdr#2 covers those paths and is expected to
help at least as much, but the figures above are LAN-measured.

## How it was found

Profiled the launch→connect→first-frame path with a temporary timeline
instrument (kept out of this PR per request). The connect handshake was
~55% of warm startup; this PR addresses it. The remaining stages — UI
init (~0.76 s) and the discovery broadcast wait (~0.85 s, bounded by the
radio's ~1 Hz beacon) — are untouched here and are candidate follow-ups.

## Verification (on hardware)

- Connects cleanly to a FLEX-8400M over LAN.
- Pipelined subs are sent in a single burst (`C32…C42` same
millisecond).
- No `peek window closed with no client status received` warning.
- Spectrum streams (`streamAck=yes`), panadapter renders, clean
disconnect.
- No subscription/protocol errors introduced.

## Risk

Low. Both changes preserve command **send order** (which the radio
honors) and the existing conflict-detection semantics. The mf-disabled
connect path is byte-for-byte unchanged.

💻 Generated with Claude Code (Opus 4.8) with architecture by @jensenpat

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Jeremy [KK7GWY] <kk7gwy@aethersdr.com>

…eanups

Review fixes for NvidiaAfxFilter:

- Add reset() (flush the jitter accumulators, rebuild the resamplers) and call
  it from AudioEngine::resetRxChainStateForSourceSwitch alongside the other NR
  modules. The old NIM BNR cleared its buffers on stream restart / source switch
  / mute; that invariant was lost when BNR became AFX, so stale pre-gap audio
  and a resampler discontinuity bled into the next stream. (review #1)
- Audio hot-path: read m_outAccum via a cursor (compact only when the consumed
  prefix exceeds the tail) instead of an O(n) front-erase every block, and reuse
  a scratch buffer for NvAFX_Run output instead of allocating per block. (review #2)
- Use a categorized logging channel (qCWarning/qCDebug, lcNvAfx) instead of the
  bare qWarning/qDebug so AFX load failures show up in the support logs. (review #9)
- Brace single-line control flow per the C++ style guide. (review #10)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

When a manual filter edit makes the engine hand control back via
setAdaptiveFilterEnabled(false), the widget synced the checkbox under a
QSignalBlocker but never persisted, leaving enabled=true on disk so the
feature silently re-enabled next session. Persist on any real enabled
change (operator or engine-driven) in the adaptiveFilterEnabledChanged
sync path. Addresses review finding aethersdr#2 on PR aethersdr#3945.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

) (#3972)

## What & why

On an NVIDIA GPU new enough for AFX but with **no published denoiser
pack for its exact arch** — notably **sm_120 (consumer Blackwell / RTX
50-series)** — the BNR button and its Download were offered and then
**silently failed**: the per-arch `afx-bits` pack 404s (only `sm_89` is
published today). BNR looked supported but could never install, with no
message steering the user to DFNR (#3933).

Root cause: `hasSupportedGpu()` gated only on compute capability (`cc >=
89`), so `sm_120` (cc 120) passed the gate even though no pack exists
for it.

## The fix

Split the GPU check into two questions:

- **`isAfxCapableGpu()`** — is the GPU new enough for AFX at all (Ada /
RTX 40-series, `cc >= 89`)? Says nothing about pack availability.
- **`hasSupportedGpu()`** — is a pack *actually published* for the
detected arch? Now `isAfxCapableGpu() &&
kPublishedComputeCaps.contains(cc)`, where `kPublishedComputeCaps = { 89
}` (kept in sync with the `afx-bits` release assets + the
`build-afx-bits` ValidateSet).

The BNR UI enables the feature on `hasSupportedGpu()` (unchanged), but
now uses `isAfxCapableGpu()` to tell apart *"GPU too old"* from
*"AFX-capable but no pack yet"*:

- **DSP panel BNR selector** — disabled with *"No BNR pack for your GPU
(sm_120) yet — DFNR remains available."* (vs. the old "requires RTX
40-series" message, which would wrongly imply the card is too old).
- **BNR Download button** — disabled, relabelled *"No pack for this
GPU"*, tooltip points at DFNR — instead of a Download that 404s.

Scope: this is suggestion #1 from the issue (the part fully in
AetherSDR's control). Publishing an actual `sm_120` pack (#3933
suggestion #2) is gated on NVIDIA shipping a consumer-Blackwell Maxine
model to NGC and is out of scope here — when it lands, add `120` to
`kPublishedComputeCaps` and upload the assets.

## Testing

**Build:** clean (Linux, `-DENABLE_NVIDIA_AFX=ON`, Qt 6.8.3). Only
`hasSupportedGpu()`'s two callers exist, both in the DSP widget and both
updated — no collateral behavior change (a machine with a published
pack, e.g. `sm_89`, still reports `hasSupportedGpu()==true` and behaves
exactly as before; an RTX 20/30 still gets the "too old" message).

**Live on the exact issue hardware — RTX 5060 Laptop GPU, compute_cap
12.0 (`sm_120`)** — via the Automation Bridge `dumpTree` (`detectArch()`
reports `sm_120`):

| Widget (`objectName`) | `enabled` | Text / tooltip |
|---|---|---|
| BNR selector (`dspMethodBtnBNR`) | **false** | *"No BNR pack for your
GPU (sm_120) yet — DFNR remains available."* |
| Download BNR runtime | **false** | text *"No pack for this GPU"*; tip
*"…yet — use DFNR."* |

Both dead-end surfaces are now gated off with a clear message on the
real GPU, instead of offering a 404 Download.

Fixes #3933.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Jeff Skerker <7691216+skerker@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

…3597) (#3987)

## Summary

`AETHER_NO_GPU=1` is documented as the runtime escape hatch to force
software rendering, but **on Windows it is a silent no-op**. `main.cpp`
only sets `QT_OPENGL=software`, which is an OpenGL-context hint — but
the spectrum is a `QRhiWidget` that has no `setApi()` call on Windows,
so it defaults to the **D3D11** backend and ignores `QT_OPENGL`
entirely. There is no runtime path to move the spectrum off the GPU.

This surfaced in #3597: on a weak GPU (reporter's GeForce GT 220, a 2009
DX10.1 part) the D3D11 QRhi spectrum + waterfall + overlay pipeline
saturates the GPU (~89%), and setting `AETHER_NO_GPU=1` changed nothing
— confirmed by the reporter.

## Change

In the `SpectrumWidget` constructor's non-macOS branch, when software
OpenGL is requested (`qtSoftwareOpenGlRequested()`), explicitly
`setApi(QRhiWidget::Api::OpenGL)`. Combined with the
`QT_OPENGL=software` set in `main.cpp`, this drives the spectrum through
the software OpenGL rasterizer instead of D3D11.

- The bundled `.qsb` shaders already contain GLSL variants (GLSL
100es/120/150 alongside SPIR-V/HLSL/MSL), so pipeline creation succeeds
on the OpenGL backend.
- **No behavior change on Linux**, whose `QRhiWidget` default backend is
already OpenGL — this just makes the two platforms share one explicit
code path.

`src/gui/SpectrumWidget.cpp` — 1 file, ~10 lines (comment + guarded
`setApi`).

## Scope / what this does NOT claim

- This makes the `AETHER_NO_GPU=1` flag **functional on Windows**
(review suggestion #1 from #3597). It does **not** by itself resolve the
performance complaint on weak GPU **and** CPU hardware —
software-rendering a 60 fps per-pixel GPU FFT pipeline on a 2009 CPU
will likely just move saturation from GPU to CPU. The proper lever for
that (an FFT-FPS cap / present throttle, suggestion #2) remains tracked
separately.

## Testing

- ⚠️ **Windows-specific and unverifiable in CI / on Linux** — the
failure only occurs on Windows (D3D11 default); on Linux the flag
already works because the backend defaults to OpenGL.
- Needs the #3597 reporter (@EA7JQA, GeForce GT 220) to launch with
`AETHER_NO_GPU=1` and confirm the panadapter renders and the renderer
reports the OpenGL/software backend (visible in panstats `renderer`),
and to report the resulting CPU/GPU load.

Refs #3597

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ok-guarded numeric parses

Resolves ten9876's #4068 findings.

- TYPED PAYLOAD (#2, strategic): the slice-status payload becomes a compiler-
  checked SliceDelta struct (std::optional per field) instead of the stringly-
  keyed QVariantMap. A field-name typo between FlexBackend::decodeSliceStatus and
  SliceModel::applyChanges is now a compile error, not a silently-dropped field.
  IRadioBackend::sliceChanged(int, const SliceDelta&); SliceDelta lives in
  src/core/backends/ so the interface stays free of model deps. The vendor-neutral
  rename win is unchanged — applyChanges still reads only canonical fields.
  Verified: 69 delta fields set in the decode, 69 read in the model, set-diff
  empty both ways (now also enforced by the compiler).
- PARSE GUARDS (#1): the decode's numeric parses are ok-guarded — a malformed
  present field is dropped, not applied as 0/0.0. Higher-stakes here than
  pan/meter: a garbled RF_frequency would otherwise retune the slice to 0 Hz.
  Matches FlexLib's TryParse+continue and the standard set on #4065/#4066.
- DOC FIXES: the sliceChanged connect comment now accurately describes the
  AutoConnection + same-thread assumption (not a hard "DirectConnection", which
  would be wrong if a backend ever moves to a worker thread) (#4); the stale
  "applyStatus already called below" comment reworded to reference
  decodeSliceStatus (#5).
- Tests: aetherd_slice_decode_test now asserts on the typed delta (incl. a
  malformed-RF_frequency-dropped case); slice_model_letter_test / antenna_alias_test
  build SliceDelta directly.

67/67 tests green; boundary --strict green; full app builds clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>