fix(hl2): make the ALC reduction-only and widen the mic slider (#5463 change 3)

[on8st]

⚠️ This PR must not merge on its own

On its own it is a known regression on every unattended transmission — a
WSPR beacon at the shipped default goes out 18.59 dB down, a factor of 72 in
power, on a transmission that keys for 111.6 s with nobody watching. It is
the first of a stack — #5647 is the second — and see
Do not merge this alone for exactly which
branch closes which half.

What this changes

This changes the transmit level of every Hermes-Lite 2 installation at Mic Level 50 or above.

The stage Hl2TxDsp calls an ALC is not one. It applied up to 40 dB of upward
makeup gain (Hl2TxDsp::Config::alcMaxGainDb) with an absolute hold threshold
(alcHoldBelowDbfs, −45 dBFS) that sits below a real shack's noise floor. So
between words the loop went on raising gain until the fan and the mic hiss
reached the same target peak as the speech.

After this PR the ALC only ever reduces. The Mic Level slider becomes the
operator's transmit level, and its upper leg is widened so that it can be.

authored speech, Mic Level at its default of 50	before	after
speech leaving the modulator	−1.18 dBFS (at the ceiling)	−21.08 dBFS
speech-to-room contrast in the pauses between words	0.21 dB	18.10 dB

About 20 dB quieter at the default slider position, and the room noise that
used to be lifted level with the operator's voice between words is gone. The
20 dB is not a fixed offset — it is the gap between how loud a given operator
actually speaks and full modulation, and it moves with the microphone, the input
gain and the voice.

Both of those figures are simulator measurements. See
What is measured on what.

Part of #5463 — this is change 3 of four. Not Closes: #5505 (change 1) and
#5506 (change 2) are already merged against the same umbrella, and change 4 —
the leveller, which a thread correction relocated into AetherVoice — is
unfiled. Auto-closing the umbrella on this merge would orphan that.

WDSP draws the same line: create_txa() in third_party/wdsp/upstream/TXA.c
builds the stage it names alc with run=1 and max_gain=1.0 — always on,
structurally incapable of adding gain — and puts the gain that can be added in
a separate leveler, built run=0 with max_gain=1.778 (+5 dB). Two stages,
two jobs.

Who is affected, and who is not

Hermes-Lite 2 only. Flex and Icom are untouched, and receive is untouched on
every family. All of this is host-side HL2 transmit DSP: Hl2TxDsp is
constructed only inside Hl2Backend (new Hl2TxDsp occurs nowhere else in the
tree), the Flex backend has no submitTxAudio override at all, and
IcomCivBackend::submitTxAudio ships PCM to a radio that runs its own transmit
processing.

WSJT-X, fldigi and anything over TCI or DAX: no change. That path already had
a unity ceiling — it was fixed separately in #4796 — and its regression case in
hl2_txdsp_test ("the reduction half must RELEASE") passes untouched at
−0.15 dB, identical before and after. That case is the evidence this is a no-op
on client-leveled audio. Level is still set in the client.

Operators who have never moved the Mic Level slider lose up to 40 dB of
automatic makeup and must set a level for the first time. That is the point of
the change and also its migration hazard — it wants a release note, not a silent
ship.

Operators who had already moved the slider above 50 keep the level they
chose. The number moves instead: a stored 75 was +10 dB on the old curve and
restores as 63, which is +10.4 dB on the new one. See
A stored slider position is migrated, not reinterpreted.

The slider mapping

The widening is asymmetric on purpose: 0.4 dB per step below 50 (unchanged,
down to −20 dB), 0.8 dB per step above, reaching +40 dB at 100 instead of the
old +20 dB. 50 stays exactly unity, because TransmitModel constructs
m_micLevel at 50 and that is where every operator who has never touched the
control transmits from — a symmetric widening would move unity off 50 and
silently change the transmit level of every existing install. (#5505 has since
landed, so a slider position now survives a launch as well; that widened the
population this pin protects rather than retiring it.) hl2_tx_level_policy_test pins the join: micSliderToGainDb(50) == 0.0,
(49) == −0.4, (51) == +0.8.

For the bench's speech recording, roughly slider 74 would have put the peak on
the ALC's target. That number is an inference from the mapping, not a
measurement — legs were run at 50 and at 100 and nothing in between.

One instrument the quiet operator gets

TX:ALC now reads the actual transmit peak and tracks its input
one-for-one until it reaches the target, then limits at −1.41 dBFS. Sitting far
below −1.41 dBFS while speaking means you are quiet. At unity, speech leaves the
modulator 19.56–19.67 dB below alcTargetPeak — d81b-speech-pauses-alc's
result.json gives speech_output_dbfs of −21.08 dBFS (fault leg) and
−20.97 dBFS (control leg), both at mic level 50, against
20*log10(0.85) = −1.4116 dBFS.

An unkey log line naming the slider position would be the natural companion, and
it is not in this branch: it must not fire on audio the operator's microphone
did not produce, and WSPR, AX.25 and RADE reach submitTxAudio with
clientLeveled false exactly like a microphone. Distinguishing them needs the
three-state TxAudioSource, which is #5647's substance. #5647 carries the advice
with its gate.

Keeping the widening inside the modulator's headroom

reset() starts the ALC at unity on every unkey, and the stage's hard clamp sits
right behind it, so at the slider's new 100x any large step arrives with the loop
still far above where it needs to be. The modulator flat-tops, and no meter
reports it — TX:ALC is measured after the clamp.

Reduction is instantaneous. The block that needs less gain simply takes the
target; only the release is smoothed. That is the shape a splatter guard has to
have, and the attack constant was never buying smoothing here: at a 512-sample
block on 24 kHz — 21.3 ms — 1 - exp(-21.3/5) already closed 98.6% of the error
in one block. It was leaving 1.4% of the step above the clamp, and 1.4% of 40 dB
is not small. alcAttackSec is deleted with the mechanism, like alcMaxGainDb
and alcHoldBelowDbfs before it.

A one-shot key-on seed was tried first and covers only the first reduction of
an over. @on8st tested it against a crescendo and it held; the shape that breaks
it is a source that crosses the target gently — an ordinary quiet word — which
spends the seed on a fraction of a dB and leaves the next syllable unprotected.
Measured at slider 100:

stimulus (whole-run |IQ|, slider 100)	seeded attack	instantaneous
full scale from sample 0	0.8594, 0 clipped	0.8594, 0
100 ms of −60 dBFS room, then full scale	0.8593, 0	0.8593, 0
−41 dBFS plateau, then a step to full scale	1.5297, 448 at the clamp	0.8592, 0
−38 dBFS word, then a −12 dBFS syllable	1.0768, 223	0.8586, 0
quiet, one loud burst, quiet again	1.5045, 727 (15.2 ms)	0.8594, 0

All eighteen probe shapes settle at ~0.859 with nothing at the clamp. The
release is untouched — #4796's case still measures −0.15 dB and the over-level
client's crest is still 1.0001.

hl2_txdsp_test pins four stimuli, and they are four different openings: full
scale from sample 0, a 100 ms −60 dBFS room lead-in, a 50 → 100 slider move
mid-over, and a quiet word followed by a loud one. The last fails on a 5 ms
attack and none of the other three can see it. It pins the observable property
rather than the mechanism — a 0.5 ms attack passes it too — and that is the
argument for instantaneous: whether a constant is short enough is a function of
dspBlockSize and inputSampleRateHz, so it is a guarantee that expires
silently the day either moves.

A stored slider position is migrated, not reinterpreted

#5505 persists the mic level, and this PR changes what a stored number means, so
a position stored against the old curve is re-expressed against the new one. An
operator who parked at 80 asked for +12 dB; 80 means +24 dB now, so the document
restores as 65 — the same gain, a different position.

The document says which curve it was written on with micLevelCurve, and
absent means curve 1: the key did not exist while curve 1 was the only curve,
so its absence is a positive statement about the writer. Writing the level back
stamps the curve beside it, which is what makes the migration one-shot — the
arithmetic deliberately is not, and hl2_state_restore_test asserts the stamp so
an unstamped round-trip cannot start a ratchet.

Only the upper leg needs it; at and below 50 both curves agree and the migration
is the identity, including the mute at 0. A curve number this build does not know
restores as written rather than being re-derived on a guess.

It rewrites two certification rows and a meter face

docs/radio-certification.md's TX:ALC row has said since 76a52403: "sweep
the input 20 dB → reading does not move, ±1 dB across the sweep", with
recorded evidence of −1.41 dBFS at −10, −20 and −30 dBFS injected tone.

That no-movement is not a property of a post-ALC peak meter. It is the observable
signature of alcMaxGainDb — 40 dB of makeup dragging any input from about
−41 dBFS upward onto alcTargetPeak — and −1.41 dBFS is exactly
20*log10(0.85). After this PR lands, that row fails a correctly behaving
radio, by 28.6 dB. Correcting it is this PR's job rather than the next reader's.

The replacement is measured rather than reasoned, because a guessed pass
criterion in a certification table is worse than a stale one — it looks measured.
The 2026-08-10 block is kept, not deleted: it is correct for the build it was
run on, it is the control for the new one, and its verdict cell now says which
build that was.

The new tolerance is ±0.25 dB against a worst measured deviation of 0.0065 dB
— two orders of magnitude looser than the data supports, deliberately, because
one radio on one host on one night does not earn a tolerance that only passes on
the machine it was taken on.

TX:ALCGAIN, three rows further down, had the same defect and is corrected
here too. It swept "between alcHoldBelowDbfs and the makeup ceiling" —
neither of which exists after this change — so it would fail a correct radio for
exactly the reason the TX:ALC row would. With the ceiling at unity the gain
that meter reports can only be zero or negative, so the criterion is now a sign
and a knee rather than a window.

And the meter's own face moved with it. TX:ALCGAIN was defined -20..+40 dB
and its comment justified the top as Hl2TxDsp::Config::alcMaxGainDb. Deleting
that field without moving the face would have left #5636 inheriting a meter whose
needle can never leave the bottom third of its own scale; it is -20..0 now.

Do not merge this alone

On its own this PR changes the level of unattended transmissions — WSPR,
AX.25 packet and RADE — because they reach submitTxAudio on the same path as a
microphone and were relying on the same 40 dB of makeup to normalise them.

Measured with the application's own WSPR beacon against hpsdrsim
(wspr-real-beacon-source-ab, beacon at the shipped −20 dBFS default):

build	beacon TX:ALC peak
today's main	−1.412 dBFS
this PR alone	−20.002 dBFS

18.59 dB down, a factor of 72 in power, on a transmission that keys for 111.6 s
with nobody watching. And on this PR alone the Mic Level slider moves the
beacon: the same run measured a 50 → 100 slider move shifting it by 18.59 dB.
A microphone control has no business moving an unattended beacon.

The repair takes two further branches, and it is worth being exact about
which one does what, because it is natural to assume the next PR closes both
halves and it does not:

	mic slider moves the beacon?	beacon level at the shipped default
this PR alone	yes — up to +40 dB	−20 dBFS (18.59 dB down)
+ #5647, hl2/engine-generated-tx-source	no — measured 0.0 dB across a 50 → 100 move	still −20 dBFS
+ the WSPR default branch, hl2/wspr-host-modulated-level (not yet filed)	no	−3.0 dBFS

#5647 removes the slider coupling and makes engine-generated audio carry the level
its generator chose; it deliberately sets no defaults. The level shortfall
itself is closed by the third branch, which moves the WSPR Level spinbox default
from −20 to −3 dBFS on host-modulating backends. wspr-unattended-ab measures
this separation directly: for a −20 dBFS engine-generated signal, the second
branch's own repair_db is 0.0.

AX.25 and RADE get the slider bypass in #5647 and no default correction
anywhere — AX.25 computes a level per frame and RADE carries its own
PcMicGain, so neither has a single default to set. Neither was exercised on the
bench; only the WSPR source was.

So: merge this with #5647, and land the WSPR default branch immediately after.
Between this PR and that one there is a window in which every unattended
transmission is ~18.6 dB down.

#5198 — offered as a candidate, not as a claim

#5198 (priority: high, open since 2026-08-23) carries two faults in one
report, and only one of them is this one.

• "the ALC meter swings nearly full-scale in response to normal transmitted
  speech" — same defect class as HL2 TX: the "ALC" applies up to 40 dB of upward makeup with an absolute hold threshold, so room noise is transmitted level with speech #5463, and the mechanism this PR deletes. It
  would be worth @darkclassical re-testing on this branch.
• "opposite-sideband spillover at approximately −30 dB" — this PR does not
  touch it and must not be credited with it. The host modulator was measured
  separately on the EP2 wire and agrees with Hl2TxDsp::designFilters, evaluated
  independently in double precision, to 0.02 dB (87.15 dB on a steady 1 kHz
  tone). The reporter's own drive sweep shows a fixed modulator/IQ image tracking
  the wanted signal 1:1. That half of his report is open.

Nobody has tested his configuration. What connects the two is the defect
class and his own title: a stage riding his gain by tens of dB when he has
deliberately set his levels is what this PR removes, and 40 dB of makeup driven
into a clamp is a plausible source of the distortion and the amplifier IMD he
describes. That is a reasonable thing to check, not a diagnosis. It is offered as
something for him to try.

What is measured on what

Read this before believing any number above.

On the real radio — one run

d90-alc-input-sweep, on ON8ST's Hermes-Lite 2, MAC 00:1C:C0:A2:13:DD read
from the radio's own response packet, gateware 74, into a dummy load, under
the operator's own time-bounded transmit approval. 16 keyed windows, 165.3 s of
keying, drive register 0 — nothing was radiated.

It establishes, on both builds: that TX:ALC tracks its input one-for-one under
the new behaviour (max deviation 0.0065 dB over 53.5 dB, fitted slope 0.99997),
that it limits at −1.413 dBFS where the knee sits, that approach direction changes
the reading by 0.0 dB, and — the part that makes the rest trustworthy — that the
old documented triple reproduces on the old build to within 0.023 dB.

On the simulator — everything else

d78/d78b (silent ratchet), d81/d81b (speech pauses) and both WSPR A/Bs ran
against hpsdrsim, serial AA:BB:CC:DD:88:FF, under a loopback approval.

The two headline figures at the top of this PR — the −1.18 → −21.08 dBFS speech
level and the 0.21 → 18.10 dB pause contrast — are simulator measurements. The
argument that they transfer is real and is recorded in each run: Hl2TxDsp is
host-side DSP and executes on m_keyed regardless of peer, so the stage under
test runs identically. But it is an argument, not a measurement.

Nothing in this series has ever been radiated. No on-air contact, no WSPRnet
spot, no receiving station has heard either build. Every claim about what a
correspondent would hear is inference. The commit messages on this branch were
corrected before filing, because an earlier version of them said "measured on the
air" and "measured on the radio" of runs that were neither.

Reasoned from code only

• The slider position that lands on target (~74) — the mapping, not a leg.
• The hop from TransmitModel to Hl2Backend::setMicGain. Every bench leg drove
  AETHER_HL2_MIC_LEVEL into setMicGain directly. (The widget's half was
  since settled through the automation bridge: invoke "Microphone gain" setValue 100 moves transmit.micLevel to 100, and 76 to 76.)
• The limiter change and the migration have no bench leg. Both were measured
  against the real Hl2TxDsp and the real Hl2Backend in a harness rather than
  on hardware or hpsdrsim, and both are pinned by the tests above. Every |IQ|
  figure quoted on this page comes from that harness.

Localization check

a lab-side checker of mine — not in this repo — that makes executable the rule in
docs/HERMES.md ("For coding agents — keep bring-up inside the family
backend"), reports 1 hit, 0 violations on this branch. Exit 2 is advisory:
hits are to be explained, not failures.

src/gui/MainWindow_Session.cpp — comment only. Three lines inside
MainWindow::wireRadioModel(), correcting a comment that said the ALC "needs the
mic pushed UP past its hold threshold" — a claim this PR makes false. No
executable line changes.

What this does NOT fix, and might be mistaken for it

• Drive and power out. Nothing here touches the drive control or the PA.
  Forward power is still set by drive.
• The TX:ALCGAIN meter. Separate work, feat(meters): publish TX:ALCGAIN, the gain the HL2 ALC is applying (meter only — gauge in #5636) #5506 and feat(gui): show the ALC Gain the HL2 reports, gated on the meter existing #5636. It exists on neither
  build measured here.
• Nothing about drive or the speech processor. Mic Level is the modulator's
  input level; it is not a substitute for either.
• Splatter protection is unchanged. The ALC still reduces on a transient, with
  the same attack and release, on every path. It simply never lifts.
• clientLeveled has no remaining use in processAudioBlock; it is kept and
  marked unused here rather than deleted, and feat(tx): keep engine-generated audio at the level its generator chose (stacked on #5646) #5647 gives it a real job as
  TxAudioSource.

Test results

Full ctest (RelWithDebInfo, macOS): 416 tests, 416 passed, 0 failed,
5 skipped (crdv_quarantined_test,
app_settings_safety_explicit-profile-path-isolation,
weather_radar_texture_gl_test, range_slider_a11y_test,
relay_bar_a11y_test).

On this head (RelWithDebInfo, Linux): the whole hl2_* family plus
radio_state_memory_test, 35/35 pass, and so do meter_model_test and
meter_surfaces_test. Note that CI's green does not include any of them —
.github/ci-test-gate.txt is frozen and carries none of the HL2 tests, so they
first run on full-suite.yml after merge.

Each guard on this branch was inverted to check it is a guard rather than a
restatement. Reverting the seed's reducing gate fails the lead-in case and
nothing else; reverting setMicGain's re-arm fails the mid-over case and nothing
else; deleting the micLevelCurve stamp fails the new hl2_state_restore_test
assertion and nothing else; replacing micLevelFromCurve1 with the identity
fails both hl2_tx_level_policy_test and hl2_dsp_readback_test. The one change
here with no test guarding it is the TX:ALCGAIN face range, which is a
display bound checked against alcGainDb()'s ceiling by inspection.

One claim from the original report did not survive its own falsifier and is
withdrawn on this branch rather than quietly dropped: "within one over the ALC
gain can only rise" is refuted by 148 downward steps across d78's ten stock
legs. What survives is narrower and sufficient — reduction is never held, so the
fault is the level during a pause, not a level that runs away across the over.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_014TtnKQu6QGrSeBirGeAsAs

[aethersdr-agent]

1. Issue fit

Partially — the mechanism is fixed; the sequencing the issue itself insists on is not satisfied.

#5463's reported symptom is real and this diff removes its cause: the held/holdThreshold expression and the alcMaxGainDb ceiling are gone from Hl2TxDsp::processAudioBlock, the ceiling is a hard std::min(wanted, 1.0), and the room-vs-speech contrast the report measured at 0.33 dB now survives the stage. I traced the "a hold under a unity ceiling strands the gain" argument through the rewritten loop (Hl2TxDsp.cpp:260-273) and it holds: with the hold deleted, a quiet block wants target = 1.0 and releases toward it on alcReleaseSec, with nothing suppressing the upward move.

But #5463 specifies four changes in a stated dependency order, and its own text and the maintainer triage both say the order is load-bearing: "3 without 1 loses the operator's setting every launch", and "the mic-range widening and the persistence work have to ship in the same release, and the release notes have to say so. That is a product call, not a code one." Change 1 is not in the tree (see Blocker 1), and the maintainer never answered the sequencing question you asked on 2026-09-08 — the thread's last word on change 3 is your own "still not opening them unbidden." That is why the headline recommendation below is a maintainer decision rather than a code objection.

2. Scope

File(s)	What it changes	Claimed?	Verdict
Hl2TxDsp.{h,cpp}	unity ceiling; delete alcMaxGainDb, alcHoldBelowDbfs, the held branch and the clientLeveled ceiling ternary	yes (#5463 change 3)	in scope
Hl2TxLevelPolicy.h	mic slider −20/+40 dB, asymmetric slopes, unity pinned at 50	yes — the issue's arithmetic requires it in the same commit	in scope
Hl2Backend.{h,cpp}	m_alcHoldBelowDbfs → m_alcTargetPeak mirror, static_assert re-point, health row swap, unkey diagnostic re-point	yes	in scope
Hl2Backend.cpp gatherDspChains	drops two fields from the dspchains bridge response	not in the body	in scope but undocumented — see Blocker 3
MainWindow_Session.cpp	comment only, verified no code change	yes	in scope
docs/radio-certification.md	replaces the TX:ALC row, keeps the 2026-08-10 block as control	yes	in scope, and correctly reasoned
tests/hl2_{txdsp,dsp_readback,tx_level_policy}_test.cpp	rewrite the cases that asserted the removed behaviour	yes	in scope

Nothing in the diff is unexplained by the issue. No new settings key, no CHANGELOG.md entry, no UI/visual change, no protocol verb added. The one public-surface removal is the dspchains pair below.

3. Blockers

1. Change 1 (persist phone.micLevel) is not in the tree, so the 20 dB the operator must now supply themselves is lost on every launch, not once. — inline on Hl2TxLevelPolicy.h:50

TransmitModel.h:513 is still int m_micLevel{50}, and RadioModel.cpp:1469-1470 states in its own comment that "micLevel is not persisted". #5505 is open, not merged — and its own body says of this very branch: "deliberately held back: both change the transmit level of every existing HL2 install, which the triage on #5463 called a product decision rather than a code one."

The consequence is sharper than "set a level for the first time", which is how the commit message frames it. Hl2TxLevelPolicy.h:26-28 keeps unity at 50 precisely because nothing restores the slider, so every launch an HL2 operator starts at unity — which on this build is your own measured 19.56–19.67 dB below alcTargetPeak. They must re-set the slider every session, and the only instrument telling them so is a qCInfo line in aether.hl2, which is below the default QtWarningMsg threshold in a support bundle. That is a per-session regression for every existing install, not a one-time migration. Either land #5505 first (or stack this on it), or get an explicit maintainer ruling that shipping in this order is acceptable with a release note.

2. closes #5463 will auto-close a four-change umbrella issue while two of its changes are still open PRs. — inline on docs/radio-certification.md:42

#5505 and #5506 both describe themselves as "part of #5463", and change 4 (the optional leveller, relocated to AetherVoice per your own correction in the thread) is unfiled. Auto-closing the issue on merge strands them. Suggest Fixes the mechanism reported in #5463 or a plain reference, and let the maintainer close the umbrella when the series lands.

3. docs/automation-bridge.md:1395-1396 still documents two dspchains fields this PR deletes. — inline on Hl2Backend.cpp:4225

The sample hl2-tx chain object in the bridge docs lists "alcMaxGainDb":20 and "alcHoldBelowDbfs":-45. gatherDspChains() no longer emits either. This is a documented response shape third parties read; the doc is now wrong in the same direction the certification row was, which is exactly the class of staleness the docs/radio-certification.md half of this PR exists to prevent. Small fix, same PR.

4. Nits (non-blocking)

• kQuietMarginBelowTargetDb = 12.0 (Hl2Backend.cpp:3403) puts the trigger at a whole-over mic peak below −13.41 dBFS. Your derivation bounds it from one side only — you say so — but 12 dB below target is a normal, perfectly audible SSB level, so this will log on many healthy overs. It is qCInfo in a category, so the cost is log noise rather than a false alarm; worth revisiting once the slider-74 leg you name exists.
• clientLeveled kept as [[maybe_unused]] is disclosed and justified (queued Q_INVOKABLE signature), and I agree it does not belong in this diff. Worth a follow-up issue so it does not linger as a parameter nobody dares remove.
• Ordering hazard you already flagged in the thread and which is not present here, recorded so it is not lost: if #5506 merges after this, its TX:ALCGAIN meter is declared −20…+40 dB over a stage that can never exceed 0 dB. I confirmed no ALCGAIN definition exists on this branch, so the conflict is cross-PR, not in this diff.

5. What I tried to break

• Latching / path-dependent gain on the mic path. The strongest claim in the diff is that the hold had to be deleted rather than narrowed. I walked Hl2TxDsp.cpp:255-273 with a loud block followed by quiet ones: target clamps to 1.0, reducing is false, tau = alcReleaseSec, and the one-pole moves the gain back to unity with no branch able to suppress it. The failure the deleted held term would have caused is real and the deletion avoids it. Survived.
• Regression on the TCI/DAX path (#4796). For clientLeveled = true the old ceiling was already 1.0 and held was already false, so the arithmetic is byte-identical. The two #4796 cases in hl2_txdsp_test.cpp are unchanged and still discriminating (the quiet leg still lands at −50 dBFS at the measurement point, and the comment at line 626 explicitly tells the next reader not to raise it). Survived.
• Are the rewritten tests vacuous? Attacked both new assertions. "at unity mic gain the ALC passes speech-level audio through unchanged" (<1 dB) fails ~30 dB wide against restored makeup. The separation case is the one that matters: on the unfixed code the room leg settles at 0 dB because the hold froze it, so the |room.gainDb| < 1.0 assertion alone would pass for the wrong reason — the outSeparationDb ∈ (19,21) assertion is what catches it, and the comment says so. Not self-asserting. Survived.
• Leftover consumers of the deleted Config fields. Grepped src/, tests/, docs/, tools/ for alcMaxGainDb / alcHoldBelowDbfs: every remaining hit is a comment except docs/automation-bridge.md (Blocker 3). No compile-time consumer left behind; the re-pointed static_assert at Hl2Backend.cpp:40 still does its anti-drift job against alcTargetPeak.
• Meter scale. TX:ALC is defined -100.0, 0.0 dBFS in defineMeters(), so a reading that now tracks down to −55 dBFS stays on scale instead of pinning at −1.41. No gauge rescale needed in this PR.
• Silence. blockPeak > 1e-6f leaves the gain frozen through digital silence rather than releasing; Hl2TxDsp::reset() sets m_alcGain = 1.0 per transmission, so an over cannot open mid-reduction. Pre-existing and unchanged.
• Could not check: anything at runtime. I have no build and no radio — every finding above is reasoned from the code in /tmp/aetherclaude/pr-5646, not reproduced. I also cannot verify your bench figures (d78/d81/d81b/d90); I checked only that the numbers quoted in comments and docs are internally consistent with each other and with alcTargetPeak = 0.85, which they are. CI is green on eaa9ac20 (build, check-macos, check-windows, Static checks, Sanitizer configure), which by AGENTS.md gates a filtered subset only.

Socket tests: none added, modified, or removed. The three touched test files are socket-free and construct Hl2TxDsp directly.

6. Recommendation

Needs maintainer decision. The code is correct, the deletion is better argued than most features are, the tests were rewritten rather than relaxed, and the certification row was measured on both builds before being changed — I could not break the DSP change. What is outstanding is not code: this is change 3 of a four-change series whose author and whose triage both say it must not ship before change 1, change 1 is an open PR, and the sequencing question you asked in the issue on 2026-09-08 was never answered. @jensenpat, the call is whether to merge #5505 first (or stack this on it) or to accept a build where every HL2 operator re-sets their mic gain each launch, with a release note saying so.

Concrete next steps regardless of that ruling: fix docs/automation-bridge.md:1395-1396, and change closes #5463 to a reference so #5505/#5506 are not orphaned.

---

_{🤖 aethersdr-agent · cost: $8.7701 · model: claude-opus-5}

[K5PTB]

Issue fit

The DSP change is correct, and I could not break it. #5463's mechanism is gone. The ceiling is a hard std::min(wanted, 1.0), the hold and alcMaxGainDb are deleted, and the rewritten tests pin the reported fault directly. The PR's own body says it must not merge alone, though, and nothing on the PR enforces that. That is Blocker 1; the other three are the earlier aethersdr-agent blockers, which I re-checked and which still stand at eaa9ac2.

Scope

File(s)	What it changes	Claimed?	Verdict
Hl2TxDsp.{h,cpp}	Unity ceiling; delete alcMaxGainDb, alcHoldBelowDbfs and the hold	Yes	In scope (#5463 change 3)
Hl2TxLevelPolicy.h	Mic slider −20/+40 dB, unity pinned at 50	Yes	In scope
Hl2Backend.{h,cpp}	m_alcTargetPeak mirror, health row, re-pointed unkey diagnostic, two dspchains fields removed	Yes, except the dspchains removal	In scope; see Blocker 3
MainWindow_Session.cpp	Comment only	Yes	In scope
docs/radio-certification.md	TX:ALC row replaced, 2026-08-10 block kept as control	Yes	In scope
tests/hl2_{txdsp,tx_level_policy,dsp_readback}_test.cpp	Cases rewritten for the new behaviour	Yes	In scope

Everything in the diff is explained by #5463 change 3. No socket tests. No CHANGELOG.md entry.

Blockers

1. This PR is mergeable on its own, and its body says that is a regression. The body measures a WSPR beacon at the shipped default going out 18.59 dB down on this branch alone, and says to merge it together with #5647. Nothing enforces that. The PR is not a draft and has no label. #5647 targets main and carries these three commits, so merging #5647 is safe, but a plain merge of this PR ships the regression.

There is also a second coupling the body does not list. On this branch alone, the unkey diagnostic fires on unattended engine audio (inline on Hl2Backend.cpp:3413). WSPR, AX.25 and RADE arrive with clientLeveled = false, and they feed the same TX:MICPEAK maximum. A beacon at −20 dBFS sits about 18.6 dB under the −1.41 dBFS target, which trips the 12 dB margin. So at unkey the log tells the operator to "Raise mic gain (currently 50 of 100)". On this branch that control also moves the beacon. #5647 is what fixes it: its diff adds !m_txAudioEngineGenerated to exactly this condition. Either mark this PR draft or do-not-merge until it lands with #5647, or close it in favour of #5647 as the merge vehicle.

2. The prerequisite is still unmerged and still unruled. #5505, which persists phone.micLevel, is OPEN. #5463's triage called the order a product decision. Its last three comments are all from the author, and there is no maintainer comment on #5463 or on this PR. So every launch still resets the slider to unity, 19.56–19.67 dB under the target by the body's own figures. This needs @jensenpat's ruling or #5505 first.

3. docs/automation-bridge.md:1395-1396 still documents alcMaxGainDb and alcHoldBelowDbfs in the sample hl2-tx dspchains object. gatherDspChains() no longer emits either field. It is a two-line doc fix in this PR.

4. closes #5463 would close an issue with open children. #5505 and #5506 are both OPEN and both describe themselves as part of #5463. A reference rather than a closing keyword leaves the issue for the maintainer to close when the series lands.

What I tried to break

• Ran the rewritten tests against five mutations of the transmit DSP and slider mapping. All five were caught:

Mutation	Caught by
restore makeup (ceiling 100x)	hl2_txdsp_test: "at unity mic gain the ALC passes speech-level audio through unchanged", "the ALC adds no gain to room-level audio"
re-add a hold below −45 dBFS under the unity ceiling	hl2_txdsp_test: "the limiter releases to unity after an over-level excursion (reduction does not latch)"
gain only moves when reducing	hl2_txdsp_test: the same release case
symmetric 0.8 dB/step slider (unity still at 50)	hl2_tx_level_policy_test
slider top back to +20 dB	hl2_tx_level_policy_test and hl2_txdsp_test: "the mic slider at 100 brings quiet audio near full modulation"

• Reproduced the body's headline DSP figures at eaa9ac2. At unity, quiet input passes through at +0.0 dB and slider 100 lifts it to 0.8501, the target. 20.0 dB of room/speech separation in comes out as 20.00 dB. The #4796 client-path release case is unchanged at −0.15 dB. All three tests pass.
• Grepped for consumers of the deleted Config fields. Outside comments, the only remaining references are the bridge doc (Blocker 3) and the historical certification paragraph, which is meant to cite them.

Not driven: the automation bridge. Every behaviour here is on the HL2 transmit path, and it only runs while keyed. A review session never keys, and the demo simulator is not an HL2.

[on8st]

You are right, and I checked it on this branch rather than taking it: the gate is if (!m_txAudioClientLeveled && ...), engine audio arrives with clientLeveled = false and passes it, and m_txAudioEngineGenerated — the symbol that would tell the two apart — occurs zero times on this head. It arrives with #5647.

So this is not something I can fix inside this PR, and that is the useful part of your finding: it is a third independent reason these two cannot merge separately, and the first one that shows up as noise rather than as a level.

The two we already knew: on this branch alone an unattended beacon at the −20 dBFS default goes out 18.58 dB down (wspr-unattended-ab: repair_db: 0.0, residual_vs_stock_db: −18.577), and the mic slider moves the beacon (18.59 dB on this branch, 0.0 dB with #5647). Yours adds that every beacon unkey also logs "Raise mic gain" — 18.6 dB of shortfall against a 12 dB margin — so an operator running WSPR overnight would wake up to a log full of advice about a microphone they were not using.

Worth saying plainly since you are the second reviewer to reach it from a different direction: #5646 alone is worse than main for anyone transmitting unattended. The body says the two must not merge separately; I would rather it were structurally impossible than stated, and it is not.

Not measured: every figure above is against hpsdrsim on loopback. Nothing in this series has ever been radiated, and there is no WSPRnet spot for any of it.

[on8st]

Rebased onto 87b80c65 at 12a338e9, plus three of the four findings.

Blocker 1 — the prerequisite is in the tree now. #5505 merged at 01:11Z as 0f2aa148. It does not persist through TransmitModel (which is why TransmitModel.h's int m_micLevel{50} still reads as it did) — it persists micLevel in the HL2 backend's own operating-state document: Hl2Backend::m_restoredMicLevel, written and read back in hl2_state_restore_test.cpp. That is the localized shape docs/HERMES.md asks for, and it is the prerequisite this mapping assumes. So a slider position now survives a launch on this radio, and 50 is unity for a returning operator, not only a fresh one.

Blocker 2 — retitled. The PR is now "#5463 change 3", and the body says Part of rather than Closes, with the reason on the record: changes 1 and 2 are merged against the same umbrella and change 4 is unfiled, so auto-closing would orphan it.

Blocker 3 — fixed. gatherDspChains() emits neither alcMaxGainDb nor alcHoldBelowDbfs any more; both belonged to the makeup half this PR removes. docs/automation-bridge.md's hl2-tx example no longer lists them.

The nit, and K5PTB's second half of Blocker 1 — not taken, deliberately. You are both right that targetDbfs − 12.0 will log on ordinary healthy overs, and K5PTB is right that on this branch alone a −20 dBFS beacon is 18.6 dB under target and so logs on every unkey. The fix is && !m_txAudioEngineGenerated, and that predicate arrives in #5647, which is stacked on this branch. Adding it here would mean writing the flag twice and resolving it against itself at merge. That makes the two PRs merge-ordered, not independent — worth stating plainly rather than papering over, and it is the maintainer's call whether to take them as a pair or have me hoist the predicate down into this one.

Full ctest 423/423, no failures.

[on8st]

@K5PTB — this still carries your CHANGES_REQUESTED from 12 September. Everything you raised was answered and pushed the following morning, and the head has moved since; no thread is waiting on us. Nothing of ours can clear a review decision, so it sits blocked until you look again.

No rush from my side, and no reply needed if you would rather come back to it later — I would just rather you knew it was waiting on that one thing rather than on work.

🤖 Generated with Claude Code

https://claude.ai/code/session_014TtnKQu6QGrSeBirGeAsAs

[ten9876]

Issue fit

#5463 says the "ALC" collapses speech-to-room contrast because 40 dB of makeup with an absolute hold cannot tell a breath from a syllable. This PR deletes the makeup half and the hold, ceilings the stage at unity on every path, and widens the mic slider to carry the gain the stage used to supply. That is the right shape, it matches the WDSP split the issue cites, and I reproduced both halves against the real Hl2TxDsp from the merge base and from this head — the fix works, on the issue's own numbers. The merge-order framing in the body is honest and I have nothing to add to it.

What I did find is a second consequence of the widening that the body does not cover and the tests cannot see: the new upper half of the slider travel is outside the modulator's own overload guard, on every path including the TCI/DAX one the body says is unchanged. Blocker 1.

Scope

Everything in the diff is explained by the issue or by a review thread on this PR. No unrelated files, no new public surface, no vendored churn, no commit predating the branch, and CHANGELOG.md is correctly untouched.

File / group	Claimed in title or body?	Verdict
Hl2TxDsp.{h,cpp} — delete alcMaxGainDb + alcHoldBelowDbfs, unity ceiling	yes, the headline	in scope
Hl2TxLevelPolicy.h — asymmetric widening to +40 dB	yes, "The slider mapping"	in scope — see Blocker 1
Hl2Backend.{h,cpp} — static_assert re-point, m_alcTargetPeak mirror, health row rename, gatherDspChains key removal	yes / thread	in scope — stale comments, nits 1–3
Hl2Backend.cpp — removal of the unkey quiet-mic advice	yes, and answers K5PTB's thread	in scope; correctly routed to #5647
docs/radio-certification.md — TX:ALC row + 2026-09-09 block	yes, "It rewrites a certification row"	in scope — incomplete, nit 4
docs/automation-bridge.md — drop two ALC keys	thread (agent blocker 3), not the body	in scope — incomplete, nit 5
MainWindow_Session.cpp — 3 comment lines	yes, "Localization check"	in scope, comment only, verified no executable change
tests/hl2_txdsp_test.cpp, hl2_tx_level_policy_test.cpp, hl2_dsp_readback_test.cpp	yes	in scope — see Blocker 1 and nit 6

The body's own claims held up where I could test them: new Hl2TxDsp occurs only in Hl2Backend, IcomCivBackend is the only other submitTxAudio override and there is no Flex one, so "Hermes-Lite 2 only" is right; the -0.15 dB release figure reproduces exactly (limiter release: swept 0.003106 vs fresh-key 0.003160 (delta -0.15 dB)); and the 18.59 dB WSPR shortfall reproduces at 18.57 dB on my own A/B. One paragraph has gone stale — nit 7.

---

Blockers

1. Slider 76–100 is outside the modulator's overload guard — measured, and on the TCI/DAX path too

Anchored inline on Hl2TxLevelPolicy.h:54. Short version: the mic multiplier is applied before the ALC on every path, Hl2TxDsp::reset() puts m_alcGain back to 1.0 on every unkey, and the ALC has to attack down from unity at the start of each over. Doubling the slider's top doubles how far it has to attack, and past the old +20 dB ceiling the hard clamp is reached before it gets there.

I built the real Hl2TxDsp from 87b80c65 (merge base) and from 1d9d063d (this head) into a standalone A/B harness — same stimulus, same 240-sample chunking the test helper uses, clientLeveled=true, full-scale 700 Hz source, 1.5 s:

=== merge base 87b80c65 ===  (clientLeveled=true, i.e. the TCI/DAX path)
  slider  50 =    1.000x : peak |IQ| 0.8615  clipped 0 (0.0 ms)
  slider  75 =    3.162x : peak |IQ| 0.8922  clipped 0 (0.0 ms)
  slider 100 =   10.000x : peak |IQ| 0.9891  clipped 0 (0.0 ms)

=== PR head 1d9d063d ===
  slider  74 =    9.120x : peak |IQ| 0.9767  clipped   0 ( 0.0 ms)
  slider  75 =   10.000x : peak |IQ| 0.9891  clipped   0 ( 0.0 ms)   <- old maximum
  slider  76 =   10.965x : peak |IQ| 1.0028  clipped  16 ( 0.3 ms)   <- guard breaks here
  slider  77 =   12.023x : peak |IQ| 1.0168  clipped 661 (13.8 ms)
  slider  80 =   15.849x : peak |IQ| 1.0630  clipped 991 (20.6 ms)
  slider 100 =  100.000x : peak |IQ| 1.5391  clipped 800 (16.7 ms)

ep2WriteTxIq (src/core/backends/hl2/MetisProtocol.cpp:205-213) clamps I and Q to ±1.0 before the int16 conversion, so that overshoot is hard-clipped on the wire — the flat-topped SSB modulator input this PR's own comments call "the one failure mode here that harms other operators rather than the operator who caused it". reset() fires on every unkey (Hl2Backend.cpp:3611), so it is every over, not just the first.

Three things make this reachable rather than theoretical:

• #5505 landed, so m_restoredMicLevel re-applies a saved slider position at connect (Hl2Backend.cpp:5410-5420) through the new curve with no migration. An operator who parked at 80 under the old build — where the body itself says it "made little practical difference, because the makeup normalised everything to the same on-air level anyway" — comes back to 15.85x.
• It is not the mic path only. The multiplier runs ahead of the ALC for client-leveled audio too; Hl2TxLevelPolicy.h says so in its own SCOPE paragraph. So "WSJT-X, fldigi and anything over TCI or DAX: no change" holds at slider ≤ 75 and stops holding at 76. The -0.15 dB release case that the body offers as evidence for that claim runs at a fixed 10x and cannot see it.
• Nothing reports it. TX:ALC is fed from alcPeak, measured after the ±1.0 clamp, so it reads ≤ 0 dBFS no matter how far past full scale the envelope went.

I am not asking for the widening to be abandoned — the ~30 dB has to come from somewhere and the slider is the right place. What I think needs a decision before this merges is which of these closes it:

• seed m_alcGain from the first block's peak at key-on instead of 1.0, so the attack does not have to traverse the new range;
• or bound the effective gain into the ALC so the worst case stays inside the clamp;
• or a one-shot migration that re-maps a persisted micLevel > 50 through the old curve (which the +40 dB widening arguably needs anyway);
• and, whichever it is, pin it — see the inline note on hl2_txdsp_test.cpp:545.

---

Nits — all non-blocking

1. Hl2Backend.h:887 — m_txAudioClientLeveled is write-only since 1d9d063d: set at Hl2Backend.cpp:3490 and :3837, read nowhere. Its comment still says it gates a diagnostic that commit deleted. Inline, with a suggestion.
2. Hl2Backend.h:1041 — same commit; m_alcTargetPeak now has one reader, not two. Inline, with a suggestion.
3. Hl2Backend.cpp:4088 — setMicGain's comment still says "the one path-dependent thing left is setKeying()'s raise mic gain diagnostic". There is nothing path-dependent left. Inline, with a suggestion.
4. docs/radio-certification.md:44 — the TX:ALCGAIN row, three lines under the one this PR rewrites, still reads "sweep the MIC input 20 dB, between alcHoldBelowDbfs and the makeup ceiling" with "the gain is frozen below the hold threshold … and capped at unity for clientLeveled audio". Both constants are deleted by this PR and the cap is now unity everywhere, so the row fails a correct radio exactly as the TX:ALC row did. By the body's own standard ("Correcting it is this PR's job rather than the next reader's") it belongs here. Related: Hl2Backend.cpp:5532-5546 sets the meter's range to -20.0, 40.0 and justifies the top as Hl2TxDsp::Config::alcMaxGainDb — after this PR the meter can only ever read ≤ 0 dB, so #5636 would inherit a face whose needle never leaves the bottom third.
5. docs/automation-bridge.md:3390-3392 — the health example still shows micLevel 80 paired with micGainAppliedLinear 3.98. 3.98 = 10^(12/20) = the old (80−50)×0.4; the new mapping gives 15.849. Inline, with a suggestion.
6. tests/hl2_txdsp_test.cpp:324 (the separation case) — the new separation case is a genuine regression test (I confirmed it fails on the merge base), but it uses −54/−34 dBFS, where the old code held the quiet leg, so it fails by asserting 52.55 dB of separation rather than by reproducing the report. At #5463's own −37.05/−12.4 dBFS the merge base gives 0.01 dB out from 24.65 dB in — the reported fault, verbatim. Worth being the leg, or an extra one.
7. PR body — "Mic Level still does not persist across launches — #5505. Until that lands an operator is back at 50 every session" is stale; #5505 merged at 0f2aa148, as your own reply on the Hl2TxLevelPolicy.h thread says. Same for the mapping section's justification "nothing restores it at startup". The conclusion (50 stays unity) is still right; the reason no longer is, and the affected population is larger than the body implies.

---

What I tried to break and could not

• "Hermes-Lite 2 only." Held. new Hl2TxDsp occurs only in Hl2Backend; IcomCivBackend::submitTxAudio is the only other override and there is no Flex one.
• The hold's deletion stranding the gain. The header argues the hold could not merely lose its !clientLeveled term. I walked it: under a unity ceiling a quiet block wants target = 1.0, reducing is false after any reduction, and a hold would suppress the move back — the argument is correct, and hl2_txdsp_test's release case measures −0.15 dB, matching the body.
• Silence and mute. blockPeak > 1e-6 freezes the gain on a digitally silent block, so a silent tail cannot release — pre-existing, and bounded by reset() on unkey. Slider 0 gives blockPeak == 0 and a 0.0x multiply; nothing transmits either way.
• alcEnabled == false with 100x. alcEnabled is written nowhere in src/ — default true, read in processAudioBlock, echoed in gatherDspChains. Unreachable for an operator, so the "ALC off, clamp is the only backstop" path is not a live worst case.
• Mutation-tested the new assertions. Rewriting micSliderToGainDb as a single symmetric × 0.8 — the exact "tidy" the new comments say the join prevents — fails hl2_tx_level_policy_test on "one step below unity is -0.4 dB" and two more. The join is pinned. The separation case likewise fails against the real merge-base DSP (52.55 dB out, asserted 19–21).
• Ran the three targets on this head, Linux/RelWithDebInfo, ninja -j8: hl2_txdsp_test, hl2_tx_level_policy_test, hl2_dsp_readback_test — 3/3 pass. Note CI's green does not include them: .github/ci-test-gate.txt is frozen and carries none of the three, so they first run on full-suite.yml after merge.
• Drove the app, offscreen, isolated AETHER_SETTINGS_DIR, AETHER_AUTOMATION_NO_TX=1, connected explicitly to DEMO-0001 ("model": "AetherSDR Demo", family sim) — never the FLEX. Hl2TxDsp is unreachable from a sim backend (health returns rows: []), so the HL2 surfaces of this PR cannot be exercised through the bridge; the A/B harness above is what stands in for that, and it drives the real class. What the bridge did settle is one of the two things the body lists as reasoned-from-code-only: the Mic Level widget does reach TransmitModel — invoke setValue 80 on the "Microphone gain" QSlider, then assert_state transmit.micLevel == 80 → pass: true. The remaining hop (TransmitModel → Hl2Backend::setMicGain) is still code-only.
• Not tested: anything on the air, the AX.25 and RADE paths (no bench leg exists and none is reachable here), and the certification rows, which need the radio.

🤖 Generated with Claude Code

[on8st]

@ten9876 — the slider blocker is answered at the branch head. Both halves you
named are in: the ALC seeds at its target on the first block carrying signal
instead of ramping down from unity, and a persisted micLevel written against
the old curve is migrated so the position moves and the level does not.

Your figures reproduce exactly in our own suite. With the seed reverted, the new
whole-run case prints whole-run |IQ| peak 1.5391, 800 samples at the clamp (16.7 ms) and fails; with it, 0.8594, 0 samples. No other check in
hl2_txdsp_test, hl2_tx_level_policy_test or hl2_dsp_readback_test moves,
which is what makes it a guard rather than a restatement.

You were also right that the test could not see it: settledTail() drops the
first half — the whole key-on window — and kHotMicGain stopped at the old
ceiling. The new leg asserts over the whole run at micSliderToLinear(100).

Not measured: anything on the air. This is the unit-level modulator only.

🤖 Generated with Claude Code

[ten9876]

Issue fit

#5463's mechanism is gone and I could not bring it back: the ceiling is a hard std::min(wanted, 1.0), alcMaxGainDb and alcHoldBelowDbfs are deleted rather than turned down, and the rewritten separation case pins the reported fault (20 dB in → 20 dB out) instead of the property the old case asserted. The WDSP split the body cites is the right authority for the shape. I rebuilt the real Hl2TxDsp from the merge base (87b80c65) and from this head (6d3d12f8) into a standalone A/B harness and the fix works — at the old +20 dB gain on the mic path, the same room-then-speech stimulus goes from peak |IQ| 1.6786 with 728 clipped samples on the base to 0.9884 with 0 on this head.

What I did not get past is @ten9876's Blocker 1. The two commits pushed since that review (356dacf3 seed, 6d3d12f8 migration) are the right two ideas, and the migration is correct, but the key-on seed does not close the case it was added for — it is spent by the first block that is not bit-exactly zero, which on every real path is the lead-in rather than the loud block. Measured below. Blocker 1.

Scope

Everything in the diff is explained by the issue or by a review thread here. No unrelated files, no commit predating the branch (all seven are 2026-09-07…09-15 by authoredDate), no vendored churn, and CHANGELOG.md is correctly untouched. The one scope problem is in the body, not the diff: the two newest commits are substantive and the body describes neither, while two of its sections still describe a mechanism 1d9d063d removed.

File / group	What it changes	Claimed in title or body?	Verdict
Hl2TxDsp.{h,cpp}	unity ceiling; delete alcMaxGainDb + alcHoldBelowDbfs + the hold; clientLeveled → [[maybe_unused]]	yes, the headline	in scope
Hl2TxDsp.{h,cpp}	key-on seed m_alcSeedPending (356dacf3)	no — absent from the body	in scope (answers a review blocker); see Blocker 1 and nit 1
Hl2TxLevelPolicy.h	asymmetric −20/+40 dB mapping, unity pinned at 50	yes, "The slider mapping"	in scope
Hl2TxLevelPolicy.h	kMicLevelCurve + micLevelFromCurve1 (6d3d12f8)	no — absent from the body	in scope (answers a review blocker); see nit 1
Hl2Backend.{h,cpp}	static_assert re-point, m_alcTargetPeak mirror, health row rename, gatherDspChains key removal, unkey advice removed	yes / thread	in scope; stale comments, nits 4–5
Hl2Backend.{h,cpp}	migrateRestoredMicLevel + the micLevelCurve stamp	no — absent from the body	in scope; nits 2–3
MainWindow_Session.cpp	3 comment lines	yes, "Localization check"	in scope — verified comment-only, no executable change
docs/radio-certification.md	TX:ALC row replaced, 2026-09-09 block added, 2026-08-10 kept as control	yes	in scope — incomplete, nit 6
docs/automation-bridge.md	drop two dspchains ALC keys	thread, not the body	in scope — incomplete, nit 7
tests/hl2_{txdsp,tx_level_policy,dsp_readback}_test.cpp	cases rewritten; slider-top, join and migration legs added	yes / thread	in scope — see Blocker 1 and nit 2

New persisted surface — checked and I think it is fine. micLevelCurve is a new key in the per-radio operating-state document. It rides inside the capability-gated txSetpoints object (Domain::TxSetpoints), so it is Principle V/III-shaped, and I checked whether it should have bumped extensionSchemaVersion instead: RadioStateMemory::load does not version-gate the HL2 read path at all (the strict != 1 check at RadioStateMemory.cpp:292 is the RTL RF-gain helper), so a bump would have bought no downgrade protection. A separate curve number is the right call and the header's reasoning for it is sound.

---

Blockers

1. The key-on seed is spent by the first non-silent block, so the widening still flat-tops the modulator — on the TCI/DAX path too

Anchored inline on Hl2TxDsp.cpp:291, with a tested suggestion.

The seed sits inside if (blockPeak > 1e-6f) and assigns target, which is already std::min(wanted, 1.0). So when the first signal-bearing block is quieter than alcTargetPeak — which is every over that does not begin at full modulation — target is 1.0, the seed writes the unity reset() had already set, and clears the flag. The ramp the seed exists to avoid then happens on the next loud block, unprotected.

blockPeak is measured after m_micGain, so at slider 100 the 1e-6 gate corresponds to an input of 1e-8 (−160 dBFS). In practice the test is "not bit-exactly zero", not "carries signal".

Real Hl2TxDsp at 6d3d12f8, same 240-sample chunking and same whole-run |IQ| instrument hl2_txdsp_test uses, 1.5 s runs:

F. What lead-in actually spends the seed? (slider 100, full-scale source)
  digital silence (exact 0.0)   peak |IQ| 0.8594  clipped   0 ( 0.0 ms)
  -120 dBFS dither              peak |IQ| 1.5391  clipped 239 ( 5.0 ms)
  -100 dBFS dither              peak |IQ| 1.5391  clipped 239 ( 5.0 ms)
   -80 dBFS floor               peak |IQ| 1.5391  clipped 239 ( 5.0 ms)
   -60 dBFS floor               peak |IQ| 1.5391  clipped 239 ( 5.0 ms)

1.5391 is the same number @ten9876 measured on the un-seeded head. Only a digitally silent lead-in preserves the seed.

It is not confined to full scale or to the top of the travel:

G. source level (slider 100, 100 ms -60 dBFS lead-in)
   0 dBFS 1.5391 | -6 1.3679 | -10 1.2356 | -14 1.1137 | -18 1.0228   (all clipped)

H. slider position (full-scale source, 100 ms lead-in)
   slider 90 (39.8x) 1.3030 | 85 (25.1x) 1.1731 | 80 (15.8x) 1.0632   (all clipped)

And it is a regression on the TCI/DAX path specifically. clientLeveled is inert now, so the numbers are identical with the flag set; at the same slider position the base was clean there and this head is not:

300 ms of −60 dBFS room, then a full-scale source	merge base, slider 100	this head, slider 100
TCI/DAX (clientLeveled=true)	10x → peak 0.9884, 0 clipped	100x → peak 1.5393, 750 clipped (15.7 ms)
mic (clientLeveled=false)	10x → peak 1.6786, 728 clipped	100x → peak 1.5393, 750 clipped

The mic row is the wind-up this PR removes, so the head is no worse there — but the client row is clean on main and clipped here, which is what makes "WSJT-X, fldigi and anything over TCI or DAX: no change" stop holding above slider 75. reset() fires on every unkey (Hl2Backend.cpp:3611), so on FT8 that is every 15-second over. And TX:ALC is fed from postAlcPeak, measured after the std::clamp(…, -1.0f, 1.0f) at Hl2TxDsp.cpp:337, so nothing reports it.

hl2_txdsp_test's new slider-top case cannot see this, because its stimulus is a full-scale tone from sample 0 — the seed's one block is the loud block. I confirmed the case is otherwise a real guard: reverting the seed fails exactly its two assertions and nothing else in the file.

The fix I suggested inline is two lines — keep the seed armed while target is still at the ceiling. I applied it, and it closes every row of B, C, F (all back to 0.8594, 0 clipped at 100x) with hl2_txdsp_test, hl2_tx_level_policy_test and hl2_dsp_readback_test all still green. Whatever shape you pick, the case wants a leg whose stimulus has a lead-in — the current one passes against the un-seeded build too once you put 100 ms of room in front of it.

2. Standing, from @K5PTB and not yet addressed: nothing enforces the merge order

Not a new finding and I have nothing to add to the analysis, but it is still true at this head, so it should not quietly lapse: the PR is not a draft, carries no label, and its own body opens by saying that merging it alone is a known regression on every unattended transmission. mergeStateStatus is BLOCKED only because of the two outstanding review decisions. Draft, a label, or landing #5647 as the merge vehicle — a maintainer call, but one of them should be in place before the reviews clear.

---

Nits — all non-blocking

1. The body is out of date in three ways, and it is the coordination document for a three-PR stack. (a) "## Two instruments the quiet operator gets" and the whole kQuietMarginBelowTargetDb = 12.0 derivation describe an unkey log line and a constant that 1d9d063d removed — grep -r kQuietMarginBelowTargetDb src/ is empty at this head, so the body advertises a diagnostic the PR does not ship. (b) "75 used to be +10 dB and is now +20 dB" is now falsified by your own 6d3d12f8: a persisted 75 restores as 63, the same gain. (c) The seed and the migration — the two newest commits, one of them a change to transmit DSP behaviour — appear nowhere in the body, and neither has a bench measurement in "What is measured on what". @ten9876's nit 7 (the stale #5505 paragraph) is also still open.

2. The micLevelCurve stamp is written but never tested. Anchored inline on Hl2Backend.cpp:5182. I deleted the txSetpoints.insert(micLevelCurve) line and hl2_dsp_readback_test, hl2_state_restore_test and the rest of the HL2 suite all stayed green. The migration arithmetic is mutation-covered (breaking micLevelFromCurve1 fails both tests), and the readback case correctly reasons that the stamp is what makes the migration one-shot — it just builds the stamp by hand in its input document and never checks the backend emits one. Failure mode if it ever regresses: the level ratchets toward unity across sessions, 80 → 65 → 58 → 54 → 52 → 51, +12 dB down to +0.8 dB in five launches. hl2_state_restore_test.cpp:851's micLevelIn(backend.currentOperatingState()) harness is one assertion away from closing it. I checked whether it could happen today: store() is the only HL2 writer and it always goes through currentOperatingState(), so the shipped code is correct — this is purely the missing guard.

3. A non-positive micLevelCurve silently suppresses the migration with no log. Inline on Hl2Backend.cpp:4200, with a suggestion. curve.toInt() != 1 sends 0 and negatives down the "curve from the future, read as written" branch, while the sibling micLevel is range-validated and dropped when unreadable (Principle VII). Treating a non-positive curve as malformed matches the function's own reasoning and costs one comparison.

4. The seed does not cover a mid-over mic gain change, which the widening also doubles. Slider 50 → 100 during an over on a full-scale source: peak |IQ| 1.4952, 816 samples (17.1 ms) at the clamp; the same move to the old +20 dB maximum is clean (0.9527, 0). At realistic mic levels (−22 dBFS speech) it is clean too, so this is narrower than Blocker 1 — a groove-click, an End keypress or a bridge/CAT micgain 100 rather than a drag. Worth a sentence in setMicGain's comment even if you leave the behaviour.

5. @ten9876's nits 1–3 are still open at this head, and there is a fourth of the same family: m_txAudioClientLeveled is write-only (Hl2Backend.cpp:3490, :3837; read nowhere) and its comment at Hl2Backend.h:890 still says it gates a diagnostic 1d9d063d deleted — inline; m_alcTargetPeak's comment at :1041 still names two readers; setMicGain's at Hl2Backend.cpp:4088 still says "the one path-dependent thing left is setKeying()'s raise mic gain diagnostic"; and submitTxAudio's at Hl2Backend.cpp:3825-3826 still explains the sticky OR in terms of "the unkey diagnostic".

6. @ten9876's nit 4 is still open. docs/radio-certification.md:44 — the TX:ALCGAIN row three lines below the one this PR rewrites still reads "between alcHoldBelowDbfs and the makeup ceiling" with "frozen below the hold threshold … capped at unity for clientLeveled audio". Both constants are deleted here and the cap is unity everywhere, so that row now fails a correct radio exactly as the TX:ALC row did — by the body's own standard ("Correcting it is this PR's job rather than the next reader's") it belongs in this diff. Inline. Related and also still open: Hl2Backend.cpp:5576 justifies the ALCGAIN meter's +40 top as Hl2TxDsp::Config::alcMaxGainDb, a field this PR deletes; after it the meter can only read ≤ 0 dB.

7. @ten9876's nit 5 is still open. docs/automation-bridge.md:3390-3392 — the health example still pairs micLevel 80 with micGainAppliedLinear 3.98 (= 10^(12/20), the old curve). On curve 2 that position is 15.849; after the migration a restored 80 is 65. Not CI-detectable — tools/gen_bridge_docs.py --check only validates the generated verb table, not the prose examples.

8. CI green does not include any of this. .github/ci-test-gate.txt is frozen and carries none of hl2_txdsp_test, hl2_tx_level_policy_test or hl2_dsp_readback_test, so all three first run on full-suite.yml after merge. Noting it because the three checks above read as coverage they are not.

---

What I tried to break and could not

• "Hermes-Lite 2 only." Held. new Hl2TxDsp occurs only in Hl2Backend; IcomCivBackend::submitTxAudio is the only other override and there is no Flex one.
• The migration arithmetic. Gain-preserving on every even offset, rounds up by ≤0.4 dB on odd ones, identity at and below 50, monotone and in-travel across 0…100 — and mutation-covered: replacing micLevelFromCurve1 with the identity fails both hl2_tx_level_policy_test and hl2_dsp_readback_test. The three-leg readback case (unstamped-above-unity, unstamped-below-unity, stamped) is the right three legs. I also checked the migration is actually reachable rather than defensive: 0f2aa148 (#5505) is contained in v26.9.3, so curve-1 documents exist in the field.
• Whether micLevelCurve should have been an extensionSchemaVersion bump. It should not — see the scope section; I read the load path rather than assuming.
• Thread-safety of m_alcSeedPending. Fine. m_txDsp lives on m_ioThread (Hl2Backend.cpp:403) and both reset and processAudioBlock reach it by queued connection, so the flag is single-threaded and FIFO-ordered behind the last block of the over.
• configure() mid-over. It clears m_inBuffer but leaves m_alcGain and the seed flag — deliberate-looking and harmless, since a mode or passband change mid-transmission keeps the settled gain rather than re-ramping.
• Silence, mute and alcEnabled == false. blockPeak > 1e-6 freezes the gain on a digitally silent block (pre-existing, bounded by reset()); slider 0 is a 0.0x multiply so nothing transmits either way; alcEnabled is written nowhere in src/, so the clamp-only path is not operator-reachable.
• Ran the full HL2 suite plus radio_state_memory_test on this head, Linux/RelWithDebInfo, ninja -j16: 35/35 pass. Also inverted the new seed guard (fails its two assertions and no others) and the migration (fails in two files) — and the stamp write (fails nothing, which is nit 2).
• Drove the app, offscreen, HOME/XDG_CONFIG_HOME/AETHER_SETTINGS_DIR all isolated, AETHER_AUTOMATION_NO_TX=1 (whoami → "txAllowed": false), explicit socket /tmp/aethersdr-pr5646, connected explicitly to DEMO-0001 ("model": "AetherSDR Demo", family sim) — the FLEX-8600 was visible in connect list and was never touched. health on the demo returns {"connected":true,"ok":true,"rows":[]}, so every HL2 surface this PR changes is unreachable through the bridge and the A/B harness above is what stands in for it. What the bridge did settle is the widget hop the body lists as reasoned-from-code: invoke "Microphone gain" setValue 100 → get transmit micLevel → 100, and setValue 76 → 76, so the slider reaches TransmitModel across the newly meaningful part of its travel. The remaining hop (TransmitModel → Hl2Backend::setMicGain) is still code-only. Instance disconnected and closed.
• Not tested: anything on the air, the AX.25 and RADE paths, and the certification rows, which need the radio.

🤖 Generated with Claude Code

[ten9876]

Approving at b6dbc789

Every blocker and nit from this review, @K5PTB's and aethersdr-agent's is now either fixed on the branch or answered on its thread — all 20 threads replied to and resolved. I pushed the fixes myself rather than handing them back; the two commits are 49c4d1d3 and b6dbc789.

One thing is deliberately NOT done: auto-merge is not armed. See the last section.

What changed since my last review

Blocker 1 — the ALC seed (49c4d1d3). The seed was cleared by the first block with blockPeak > 1e-6, and blockPeak is measured after m_micGain, so at the slider's new 100x that test corresponds to an input of −160 dBFS: in practice "is this block bit-exactly zero", not "does it carry signal". Any lead-in spent the seed on a block that wanted unity and handed the next loud block the full 40 dB ramp anyway.

It is gated on reducing now — a block that wants unity is not the block the seed exists for. Because the branch requires reducing, the seed can only ever move the gain down, which is the invariant the original comment claimed and which a naive re-arm would have broken.

The same reasoning covers a mid-over gain change, which the widening also doubled: setMicGain re-arms the seed on an upward move only, since a reduction cannot reach the clamp and should keep its normal release.

Measured on the real Hl2TxDsp, whole-run |IQ|, same instrument as the tests:

stimulus at slider 100	before	after
full scale from sample 0	0.8594, 0 clipped	0.8594, 0 clipped
100 ms of −60 dBFS room, then full scale	1.5391, 239 at the clamp	0.8594, 0
slider 50 → 100 mid-over, full scale	1.4952, 816 at the clamp (17.1 ms)	0.8594, 0

The functional diff is four lines. Everything else in that commit is the reasoning and the two new test cases.

The sweep the makeup ALC's removal left half-done (b6dbc789). docs/radio-certification.md's TX:ALCGAIN row still swept "between alcHoldBelowDbfs and the makeup ceiling" — the same defect as the TX:ALC row this branch already rewrote, three rows further down, and it would have failed a correct radio for the same reason. Rewritten. The meter's own face went with it: it was -20..+40 justified by alcMaxGainDb, so deleting that field would have left #5636 inheriting a needle that can never leave the bottom third; it is -20..0 now. Four comments that still explained themselves through the deleted unkey diagnostic are corrected, including one at submitTxAudio nobody had flagged. The bridge health example's micGainAppliedLinear is 15.849 rather than the old curve's 3.98. And migrateRestoredMicLevel no longer treats a zero or negative micLevelCurve as a curve from the future — that is a damaged document, so it logs.

Two test gaps, both found by mutation. Deleting the micLevelCurve stamp passed the entire suite, while the migration arithmetic is deliberately not idempotent — an unstamped round-trip would have walked an operator's +12 dB down to +0.8 dB over five launches. hl2_state_restore_test asserts the stamp now. And the separation case used a round −54/−34 dBFS; it now also asserts #5463's own −37.05/−12.4 dBFS loopback pair verbatim, where the merge base turned 24.65 dB of input separation into 0.33 dB.

The PR body is rewritten: the kQuietMarginBelowTargetDb section and the unkey-log-line section are erased rather than annotated (1d9d063d removed both), the "75 used to be +10 dB and is now +20 dB" paragraph is replaced by what the migration actually does, the two #5505-is-still-open paragraphs are corrected, and the seed and the migration each have a section — they had none.

Verification

• Full hl2_* family plus radio_state_memory_test: 35/35 pass, Linux/RelWithDebInfo. meter_model_test and meter_surfaces_test pass too, since the meter definition moved.
• Every new guard mutation-tested in isolation, against the commits: reverting the reducing gate fails the lead-in case and nothing else; reverting the setMicGain re-arm fails the mid-over case and nothing else; deleting the micLevelCurve stamp fails the new state-restore assertion and nothing else. The earlier round of this review found the stamp mutation came back green — it does not now.
• CI green on b6dbc789: build, check-macos, check-windows, Static checks, Sanitizer option configures. Worth repeating that this does not exercise the HL2 tests — .github/ci-test-gate.txt is frozen and carries none of them, so they first run on full-suite.yml after merge. The local 35/35 above is the real evidence.
• One change here has no test guarding it: the TX:ALCGAIN face range. meter_surfaces_test covers that meter's registration and units but not its bounds, so the new -20..0 is checked against alcGainDb()'s ceiling by inspection rather than by assertion.

What I did not touch

The merge-order question, which is not a code problem and is not mine to close: on its own this PR still changes the level of unattended transmissions, and #5647 is what removes the slider coupling. So auto-merge is deliberately not armed, and #5647 is not ready to be the vehicle either — it is CHANGES_REQUESTED and is stacked on an older #5646 commit, so it does not contain 6d3d12f8, let alone this head. It needs a rebase onto b6dbc789 and its own review cleared before either can land.

Approving so that this PR is no longer the thing in the way.

🤖 Generated with Claude Code

[on8st]

The seed under a crescendo — measured, because neither review tested that shape

49c4d1d3 gates the seed on reducing rather than on "the first block with signal", and @ten9876's lead-in rows all come back clean. Both of those measurements drive a step: a quiet lead-in, then full scale.

A crescendo is a different shape and it worried me. The seed fires on the first block that wants any reduction — so a source rising gradually could land a block in the narrow window where target is just under 1.0, spend the seed on a small correction, and hand every louder block after it the ramp. At slider 100 that window is an input between roughly −41 and −39 dBFS, which a rising source passes through.

It does not happen. Real Hl2TxDsp at b6dbc789, slider 100 (micSliderToLinear(100) = 100x), 700 Hz rising linearly from silence to full scale over the stated time, then held; 1.5 s runs, hl2_txdsp_test's own 240-sample chunking and whole-run |IQ| instrument:

rise      0 ms   peak |IQ| 0.8594   clipped 0
rise      5 ms   peak |IQ| 0.8452   clipped 0
rise     20 ms   peak |IQ| 0.8456   clipped 0
rise     50 ms   peak |IQ| 0.8533   clipped 0
rise    200 ms   peak |IQ| 0.8514   clipped 0
rise   1000 ms   peak |IQ| 0.8514   clipped 0

Zero clipped samples at every rise time, and the peak sits where the settled cases do.

The reason, as far as I can tell from the numbers rather than from reading: on a slow rise the signal changes little across one 5 ms block, so the ordinary attack tracks it without ever needing the jump. The seed's window matters only when the step is large, which is exactly the case it was written for. On a fast rise the first reducing block already wants heavy reduction and the seed does its job.

Not measured: anything on the air. This is the unit-level modulator only, on macOS/arm64, and the probe was temporary — it is not in the branch. I did not test a crescendo that stops partway, or one that rises and falls inside a single over.

I would not add this as a test case unless you want it: it asserts the absence of a failure in a shape the existing lead-in case already covers in spirit, and a case that cannot fail is the thing this project keeps arguing against.

🤖 Generated with Claude Code

[ten9876]

It reproduces — but not on the shape you drove

Your rise sweep reproduces exactly here, all six rise times, 0 clipped. And your
explanation is right: on a slow rise the per-block change is small enough for the
ordinary attack to track it, so a monotonic crescendo never exercises the path
you were worried about.

The path is reachable from the other shape you named as untested — the one that
stops partway. The seed fires on the first block wanting any reduction, so a
source that crosses the target gently spends it on a fraction of a dB, and every
louder block after that gets the smoothed attack with nothing in front of the
clamp. Real Hl2TxDsp at b6dbc789, slider 100, whole-run |IQ|, your instrument
and chunking:

B. rise 200 ms to a plateau, hold 300 ms, then step to full scale
  plateau -41.0 dBFS   peak |IQ| 1.5297   clipped 448 ( 9.4 ms)
  plateau -40.0 dBFS   peak |IQ| 1.5045   clipped 449 ( 9.4 ms)
  plateau -39.0 dBFS   peak |IQ| 1.4757   clipped 457 ( 9.6 ms)
  plateau -38.0 dBFS   peak |IQ| 1.4497   clipped 465 ( 9.7 ms)
  plateau -35.0 dBFS   peak |IQ| 1.3536   clipped 505 (10.6 ms)
  plateau -30.0 dBFS   peak |IQ| 1.1912   clipped 554 (11.6 ms)
  plateau -20.0 dBFS   peak |IQ| 0.9662   clipped   0          <- already pulled down

C. at realistic mic levels rather than full scale
  -38 dBFS word, then a -12 dBFS syllable   peak |IQ| 1.0768   clipped 223 (4.7 ms)

D. your other untested shape, rise AND fall in one over
  triangle 0 -> full -> 0                   peak |IQ| 0.8514   clipped   0
  quiet, one loud burst, quiet again        peak |IQ| 1.5045   clipped 727 (15.2 ms)

C and the second D row are speech, not corner cases.

So the seed is gone, and reduction is instantaneous

37ecd25f. The attack constant was never buying smoothing at this block size —
512 samples on 24 kHz is 21.3 ms, and 1 - exp(-21.3/5) already closes 98.6% of
the error in one block. It was leaving 1.4% of the step above the clamp. A
reducing block now simply takes the target; m_alcSeedPending, reset()'s
arming, setMicGain's re-arm and the now-dead alcAttackSec are all deleted,
with its bridge-doc key.

All eighteen shapes settle at ~0.859 with nothing at the clamp, including every
row above. The release is untouched — #4796's case still measures −0.15 dB
and the over-level client's crest is still 1.0001.

You were right not to want a test that cannot fail, so the one I added is the one
that could: a −38 dBFS word then a −12 dBFS syllable. It fails on a 5 ms attack
and none of the other three cases in the file can see it.

One honest limit, found by inverting it: it pins the observable property, not
the mechanism. A 0.5 ms attack passes it too. I think that is the argument for
instantaneous rather than against it — whether a constant is "short enough"
depends on dspBlockSize and inputSampleRateHz, so it is a guarantee that
expires silently the day either moves — but it is a judgement, and it is yours
and @jensenpat's to overrule if you would rather keep a fast constant.

Same caveat as yours: unit-level modulator only, nothing on the air.

🤖 Generated with Claude Code

[ten9876]

Re-approving at 37ecd25f

My earlier approval was dismissed by my own push, so this replaces it. The change since then is 37ecd25f, which came out of @on8st's crescendo challenge.

The seed is gone; reduction is instantaneous. on8st tested the key-on seed against a monotonic crescendo and found it clean — I reproduced their sweep exactly, 0 clipped at every rise time, and their explanation holds. The failure is on the other shape they flagged: one that stops partway. The seed only ever protects the first reduction of an over, so a source crossing the ALC target gently spends it on a fraction of a dB and the next syllable is unprotected. Measured at b6dbc789, slider 100, whole-run |IQ|: a −38 dBFS word then a −12 dBFS syllable reached 1.0768 with 223 samples clipped, and a quiet passage with one loud burst reached 1.5045 with 727 (15.2 ms). Those are speech.

The attack constant was never buying smoothing at this block size — 512 samples on 24 kHz is 21.3 ms, so 1 - exp(-21.3/5) already closed 98.6% of the error in one block; it was leaving 1.4% of the step above the clamp. A reducing block now takes the target. m_alcSeedPending, reset()'s arming, setMicGain's re-arm and the dead alcAttackSec are all deleted. The functional diff is a net deletion — this stage is simpler than the one I approved yesterday.

All 18 probe shapes settle at ~0.859 with nothing at the clamp. The release half is untouched: #4796's case still measures −0.15 dB and the over-level client's crest is still 1.0001.

Verified

• 37/37 — the full hl2_* family plus radio_state_memory_test, meter_model_test and meter_surfaces_test, Linux/RelWithDebInfo.
• CI green on 37ecd25f: build, check-macos, check-windows, Static checks, Sanitizer option configures. As before this does not run the HL2 tests — .github/ci-test-gate.txt is frozen and carries none of them.
• Mutation: reintroducing a 5 ms smoothed attack fails all four whole-run cases. Reintroducing a 0.5 ms attack passes them — so the new case pins the observable property, not the mechanism. I corrected the test comment after finding that, and said so in the code: whether a constant is short enough is a function of dspBlockSize and inputSampleRateHz, which is the argument for instantaneous rather than against it. If you or @jensenpat would rather keep a fast constant, that is a reasonable call and I would not re-block on it.
• All 20 review threads from the earlier rounds remain resolved.

Still not armed, and why

Auto-merge stays off, and there is now a second reason beyond the original merge-order one.

#5647 is APPROVED and CLEAN, and it is branched from f6f5fed7 — six commits behind this head. I checked its files directly: it carries the +40 dB slider widening but contains neither the limiter work (m_alcSeedPending / instantaneous reduction: zero occurrences) nor the curve migration (micLevelFromCurve1: zero occurrences). Merging #5647 today would ship the widened slider with the flat-topping and the silently-reinterpreted stored slider position that this PR exists to prevent.

So: #5647 wants a rebase onto 37ecd25f before either lands. That is the remaining blocker on the pair, along with @K5PTB's standing review here, whose four points are all either fixed on the branch or answered on their threads.

🤖 Generated with Claude Code