ChrisBeWithYouandClaude Opus 4.8 233f5280e8 fix(gp2rs): write beat times at 6-decimal precision
The editor/timeline derives per-bar BPM from beat spans
(bpm = beats*60/span), which amplifies rounding: at millisecond
(3-decimal) precision a constant-tempo GP import (e.g. 140 BPM) shows a
spurious per-bar "tempo drift" of ~0.05-0.7 BPM because most bar lengths
don't land on a ms boundary (worse for fast/odd meters). gp2rs computes
these beat times exactly from the GP tempo map, so the only precision
loss is the ebeat/startBeat format string. Writing them at 6 decimals
(microseconds) makes the derived tempo match GP's authored value.

Verified on GP5 imports (Highway to Hell 116, Equivalence 140, Living
After Midnight 138): the derived per-bar BPM collapses from two drifting
values to the single authored constant.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013JgxKh99UAeQqmhzSc73tv
Signed-off-by: ChrisBeWithYou <christian.a.cowan@gmail.com>
2026-07-09 00:17:43 -05:00
2026-06-16 18:47:13 +02:00
2026-06-16 18:47:13 +02:00
2026-06-16 18:47:13 +02:00
2026-06-16 18:47:13 +02:00
2026-06-16 18:47:13 +02:00
2026-06-16 18:47:13 +02:00
2026-06-16 18:47:13 +02:00
2026-06-16 18:47:13 +02:00
2026-07-03 13:41:50 +02:00
S
Description
No description provided
AGPL-3.0
985 MiB
Languages
JavaScript 56.4%
Python 37.1%
HTML 3.2%
CSS 1.2%
TypeScript 1.1%
Other 1%