Per-section syncing (non-uniform time-map) for songs that change tempo/meter

[carochacs]

Status

Backlog — not being worked on right now. Filed to capture the design so the current uniform sync work (issue got-feedBack#16 / the sync-detection follow-up) can stay in scope.

Problem

The Sync Tempo/Offset feature applies one uniform BPM factor + one offset across the entire song (deliberately — issue got-feedBack#16 scoped full per-note DTW warping out). That model can't correctly align a song whose tempo or time signature changes mid-track, because no single factor fits every section.

Concrete case: Pink Floyd — "Money" is in 7/8 for the verses/main riff and switches to 4/4 for the guitar solo. On a correctly-synced .sloppak of it:

• whole-song beat tracking reads ~128–129 BPM (the 7/8 quarter-note tempo), matching the tab;
• but the solo section (the Lead arrangement's opening, ~186s in) has a genuinely different local tempo/feel.

A uniform factor derived from one section would smear every other section. For songs like this the best the uniform model can do is recognize the tab is already aligned and do no harm (factor ≈ 1, offset ≈ 0) — it can't actually improve a section-varying song.

Proposal

Add an optional per-section sync that produces a piecewise / non-uniform time-map instead of one global factor+offset:

• Use the arrangement's existing sections[] markers (Intro/Verse/Chorus/Solo/…) as region boundaries.
• Run the same chroma + DTW alignment (from the current sync redesign) per section, anchored on each section's opening notes against the audio for that region.
• Produce a per-section (factor, offset) (or a set of anchor correspondences) and bake it into note timestamps once, offline — consistent with the rhythm-game model (fixed committed timestamps; no live warping at play time).
• Per-section confidence + the ability to apply/skip individual sections (a bad match on one section shouldn't move the others).

Design considerations / open questions

• Beat grid interaction. A non-uniform warp changes what "BPM" means afterward and how the shared ebeats grid (used for quantization/snapping in the canvas timeline) is reconciled. Needs a real decision: re-derive ebeats from the warped timeline, or keep a separate authored grid?
• Data model. Today sections are {name, number, start_time} and there's one song-wide beat grid. Piecewise correction likely needs either per-section tempo metadata or a resampled ebeats array — a schema change with save/build/XML round-trip implications.
• Boundary handling. Discontinuities at section edges (a section that ends early/late) — clamp, blend, or snap to the next section's anchor?
• Scope guard. Should stay offline/baked (not a live score-follower — see issue feat(editor): author teaching marks fg/ch/sd in the note inspector (§6.2.2) got-feedBack/feedBack-plugin-editor#16's note on why Slopsmith isn't a live-alignment system).
• UX. How to present per-section results without overwhelming (per-section confidence badges, "apply all high-confidence" vs. review each).

Relationship to current work

The uniform sync redesign (issue got-feedBack#16 + follow-up PRs) remains the shipped model and should keep its do-no-harm guarantee: on an already-synced song (including meter-changing ones like Money), it must return factor ≈ 1 / offset ≈ 0 rather than inventing a damaging global correction. This issue is the strictly-bigger feature to actually correct section-varying songs, and is intentionally deferred.

🤖 Generated with Claude Code

---

Migrated from Maestro-Ltd/slopsmith-plugin-editor#23.