Skip to content

Per-section sync 2/5: decide the data model, beat-grid and boundary handling for a piecewise time-map #23

New issue
New issue
Closed
#68
Closed
Per-section sync 2/5: decide the data model, beat-grid and boundary handling for a piecewise time-map#23
#68
Labels
enhancementNew feature or request

Description

@cchacs
cchacs
opened on Oct 2, 2026

Part of #8. Design decision; no feature code. Sub-issues 3 and 4 depend on the answers.

#8 lists open questions that must be settled before a non-uniform time-map can be built. Settle and record them (in this issue, then link from #8).

Questions to answer

  1. Beat grid. A non-uniform warp changes what "BPM" means and how the shared ebeats grid (used for quantization/snapping in the canvas timeline) is reconciled. Re-derive ebeats from the warped timeline, or keep a separate authored grid?
  2. Data model. Sections today are {name, number, start_time} with one song-wide beat grid. Does piecewise correction need per-section tempo metadata or a resampled ebeats array? State the schema change and its save / build / XML round-trip implications.
  3. Boundary handling. At section edges (a section that ends early or late): clamp, blend, or snap to the next section's anchor?
  4. Scope guard. Confirm the result stays offline and baked into committed note timestamps, not a live score-follower (see the note in Per-section syncing (non-uniform time-map) for songs that change tempo/meter #8 and the earlier issue fix(security): restrict youtube-audio to YouTube hostnames #16 reasoning).

Acceptance criteria

  • Each of the four questions has a written decision and a reason, including the rejected alternative.
  • The schema change (if any) is specified well enough to review without code, and is checked against the pack format rules in feedpak-spec before implementation (any new manifest key must land in the spec first).

Out of scope

Implementation, UI, and the alignment engine.

Activity

  1. cchacs
    added a parent issue on Oct 2, 2026
  2. cchacs
    added
    enhancementNew feature or request
    on Oct 2, 2026

  3. pullfrog commented on Oct 2, 2026

    @pullfrog
    pullfrogBot
    on Oct 2, 2026 – with Pullfrog

    Pullfrog  ｜ Build this ➔ ｜ Make a plan ➔

  4. cchacs commented on Oct 2, 2026

    @cchacs
    cchacs
    on Oct 2, 2026 – with Claude
    CollaboratorAuthor

    @itsjustroxi this sub-issue is the design decision behind #8 (per-section sync), and the engine-to-timestamps work waits on it. Decisions to make and record (no code):

    1. Beat grid: re-derive ebeats from the warped timeline, or keep a separate authored grid?
    2. Data model: per-section tempo metadata or a resampled ebeats array, and the resulting schema and save/build/XML round-trip implications (a new pack-format key must land in feedpak-spec first).
    3. Boundary handling at section edges: clamp, blend, or snap to the next section's anchor?
    4. Scope guard: confirm it stays offline and baked, not a live score-follower.

    Generated by Claude Code

  5. cchacs
    added 2 commits that reference this issue on Oct 11, 2026

    docs(editor): decide per-section sync time-map contract (#23)

    58d4362

    Merge pull request #68 from get-flashbacks/feat/per-section-sync-desi…

    780a7fd
  6. cchacs
    closed this as completedin #68on Oct 11, 2026

  7. cchacs commented on Oct 11, 2026

    @cchacs
    cchacs
    on Oct 11, 2026 – with ChatGPT Codex Connector
    CollaboratorAuthor

    Resolved by merged PR #68. The recorded decisions answer all four questions and include the rejected alternatives:

    1. Fit the existing shared beat grid to the audio; keep beat identity and meter, rather than introducing a separate authored grid.
    2. Bake into existing chart fields and song_timeline.json. Checked against pinned feedpak spec/schema sources; no schema change or new manifest key is needed.
    3. Use a continuous, strictly increasing piecewise-linear map with shared boundary anchors, identity constraints for skipped sections, and preserved locks. Reject incompatible proposals rather than clamp or silently blend; preserve skipped objects exactly, including crossing spans.
    4. Apply explicitly as one undoable offline edit; playback uses baked timestamps.

    The document specifies the save/build/XML contract, precision requirements and acceptance fixtures for #25. Implementation remains in #24–#26; parent #8 remains open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions