editor: ApplyMaterial does not snap generated tables to the format grid #60

New issue

Open

opened 2026-09-05 12:31:37 +00:00 by bcox · 0 comments

bcox commented

2026-09-05 12:31:37 +00:00

Owner

patches/build.h's SetModeTable calls materials::Generate and then
playground::SnapModeTableToFormatGrid, in that order, because a generated
table carries per-mode ratio and decay values that are arbitrary doubles and
the format stores them as Q32.32.

editor/patch_view.h's ApplyMaterial is the second door onto the same
materials::Generate call -- the editor's Generate button -- and it does not
snap. grep -A 12 ApplyMaterial editor/patch_view.h | grep -c SnapModeTableToFormatGrid is 0.

This is documented as a known follow-up in plugin/patch_format.h's own
comment on SnapModeTableToFormatGrid, which says the editor path "has the
identical latent gap -- a table built there and never routed through this
function is exposed to the same rounding hazard on its own save/load".

Latent rather than live: WritePatch snaps on the way out, so a table built in
the editor and saved is fine. The exposure is a table built there and compared
or rendered before a save/load round trip, which is the shape that produced a
bit-exact divergence at sample 66 in patches/hihat.h (see that patch's
header, and the minor-25 entry in plugin/patch_format.h).

It matters a little more since minor 30, because the cymbals design leans on
ApplyMaterial as the faithful-regeneration path when it argues about what
an old reader loses -- and it is faithful only to about 1e-9 per ratio.

One call, beside the materials::Generate in ApplyMaterial.

Found by the whole-branch review of modal-cymbals.

`patches/build.h`'s `SetModeTable` calls `materials::Generate` and then `playground::SnapModeTableToFormatGrid`, in that order, because a generated table carries per-mode ratio and decay values that are arbitrary doubles and the format stores them as Q32.32. `editor/patch_view.h`'s `ApplyMaterial` is the second door onto the same `materials::Generate` call -- the editor's Generate button -- and it does not snap. `grep -A 12 ApplyMaterial editor/patch_view.h | grep -c SnapModeTableToFormatGrid` is 0. This is documented as a known follow-up in `plugin/patch_format.h`'s own comment on `SnapModeTableToFormatGrid`, which says the editor path "has the identical latent gap -- a table built there and never routed through this function is exposed to the same rounding hazard on its own save/load". Latent rather than live: `WritePatch` snaps on the way out, so a table built in the editor and saved is fine. The exposure is a table built there and compared or rendered before a save/load round trip, which is the shape that produced a bit-exact divergence at sample 66 in `patches/hihat.h` (see that patch's header, and the minor-25 entry in `plugin/patch_format.h`). It matters a little more since minor 30, because the cymbals design leans on `ApplyMaterial` as *the* faithful-regeneration path when it argues about what an old reader loses -- and it is faithful only to about 1e-9 per ratio. One call, beside the `materials::Generate` in `ApplyMaterial`. Found by the whole-branch review of `modal-cymbals`.