v2026.08.26.002 — charts saved before the import fix now repair themselves - #33
Merged
Merged
Conversation
…elves
Owner reported an already-imported chart was "a bunch of gibberish". They
were on the fixed build, so my answer that the fix was live was wrong in the
way that mattered: .21.004 only cleans text AT PASTE TIME. A chart already
in the library still holds raw [Verse] labels, "G#sA" slide shorthand and
guitar-tab rows in its stored body, and nothing was repairing those on the
way to the screen. Telling them to delete and re-import was a poor answer to
data already sitting on their device.
parseSong now handles all three at render, so an existing song heals itself
with no re-import:
- a bare bracketed non-chord label ([Verse], [Instrumental] (x4)) becomes a
section heading instead of literal lyric text
- slide shorthand resolves so the chord row parses as chords again
- guitar-tab rows get their own "tab" line type rendered in a .tabline
monospace row instead of being wrapped as mangled lyrics
The slide rewrite is LENGTH-PRESERVING ("slide" -> 5 spaces, "s" -> 1 space)
in BOTH the import and render paths. pairToSegs aligns chords by COLUMN, so
a shortened chord line drags every chord onto the wrong word — the harness
proves it with a control: the naive rewrite collapses "F# B C#" onto the
first word, while the length-preserving one keeps F#/B/C# on their own
words. This also fixes a latent alignment bug shipped in .21.004's
import-side rewrite.
Verified on a song stored in the pre-fix format, rendered without
re-importing: labels become headings, zero literal "[Verse]" text left in
lyrics, slide rows parse as chords, tab rows stay tab, and every chord lands
on the correct word.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RFni8j63y7ynwzmNLMPMTB
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Owner reported an already-imported chart was "a bunch of gibberish". They were on the fixed build, so my answer that the fix was live was wrong in the way that mattered:
.21.004only cleans text at paste time. A chart already in the library still holds raw[Verse]labels,G#sAslide shorthand and guitar-tab rows in its stored body, and nothing was repairing those on the way to the screen. Telling them to delete and re-import was a poor answer to data already sitting on their device.Fix —
parseSongrepairs at renderAn existing song now heals itself with no re-import:
[Verse],[Instrumental] (x4)) becomes a section heading instead of literal lyric texttabline type rendered in a.tablinemonospace row instead of being wrapped as mangled lyricsThe subtle part: rewrites must preserve column width
The slide rewrite is length-preserving (
slide→ 5 spaces,s→ 1 space) in both the import and render paths.pairToSegsaligns chords by column, so a shortened chord line drags every chord onto the wrong word. The harness proves it with a control:This also fixes a latent alignment bug shipped in
.21.004's import-side rewrite, which used the shortening form.Verified
On a song stored in the pre-fix format, rendered without re-importing:
[Verse]text left in lyricsF# B C#,G# A Eb E)node --check×2, duplicate-id scan, brand == CACHE; screenshots + hero GIF regenerated🤖 Generated with Claude Code
https://claude.ai/code/session_01RFni8j63y7ynwzmNLMPMTB
Generated by Claude Code