FM: RequiredBandwidthRatio worst-cases the modulators over every wave but reads the carrier through the reachable lane #68

New issue

Open

opened 2026-09-05 23:17:49 +00:00 by bcox · 0 comments

bcox commented

2026-09-05 23:17:49 +00:00

Owner

There is a deliberate asymmetry in FmPairLayer::RequiredBandwidthRatio after branch
fm-followups, and it is worth revisiting with a measurement.

HarmonicPeaks takes the loudest each harmonic reaches across every wave in a
modulator's table, whatever the wave-position lane can actually reach.
CarrierHarmonicCeiling reads the carrier's table through
ReachableLaneMaximum(patch, kWavePosition), so a patch parked on wave 0 of
Init()'s sine-to-square morph is charged for the sine.

The asymmetry was priced rather than overlooked: being coarse about a modulator's
table costs a rung or two, while being coarse about the carrier costs the whole family
and more, because the carrier's harmonic number multiplies the reach. A blanket worst
case there would put the ordinary FM patch on the ceiling.

But the modulator side is now the loose one, and tightening it would lower shipped
provisioning -- which is the direction that needs evidence before anyone touches it,
not after. It wants:

A count of how many factory layers actually have a modulator table whose reachable
waves are narrower than its widest wave. If the answer is zero, this is a no-op and
should be closed as one.
The derived rung before and after, at every key from 12 to 120.
A re-run of plugin/fm_alias_test.cc's grid, because lowering a rung is exactly the
change that can put a cell under the -60 dB bar.

Not a tidiness pass. It is a provisioning reduction, and the alias grid is the only
thing that can say whether it is safe.

There is a deliberate asymmetry in `FmPairLayer::RequiredBandwidthRatio` after branch `fm-followups`, and it is worth revisiting with a measurement. - `HarmonicPeaks` takes the loudest each harmonic reaches across **every** wave in a modulator's table, whatever the wave-position lane can actually reach. - `CarrierHarmonicCeiling` reads the carrier's table through `ReachableLaneMaximum(patch, kWavePosition)`, so a patch parked on wave 0 of `Init()`'s sine-to-square morph is charged for the sine. The asymmetry was priced rather than overlooked: being coarse about a modulator's table costs a rung or two, while being coarse about the carrier costs the whole family and more, because the carrier's harmonic number multiplies the reach. A blanket worst case there would put the ordinary FM patch on the ceiling. But the modulator side is now the loose one, and tightening it would **lower** shipped provisioning -- which is the direction that needs evidence before anyone touches it, not after. It wants: 1. A count of how many factory layers actually have a modulator table whose reachable waves are narrower than its widest wave. If the answer is zero, this is a no-op and should be closed as one. 2. The derived rung before and after, at every key from 12 to 120. 3. A re-run of `plugin/fm_alias_test.cc`'s grid, because lowering a rung is exactly the change that can put a cell under the -60 dB bar. Not a tidiness pass. It is a provisioning reduction, and the alias grid is the only thing that can say whether it is safe.