Skip to content

Real-world charts render: tolerant chord lines + bare section labels (v2026.09.07.002) - #36

Merged
cdburgess75 merged 1 commit into
mainfrom
claude/hello-lr09iw
Sep 7, 2026
Merged

cdburgess75 merged 1 commit into
mainfrom
claude/hello-lr09iw

Conversation

@cdburgess75

Copy link
Copy Markdown
Owner

Owner sent a screenshot of a ZZ Top chart from their own library showing almost no coloured chords and no visible section markers. Two detection defects, both fixed at render time, so songs already in a library heal without being re-imported.

1. One bad token no longer drops the whole line

isChordLine required every token on a line to be a chord. A single mangled token sent the whole line — its good chords included — down to plain lyrics. E G#dD# lost its E. A song pasted with damaged chords showed almost none, which is exactly what the screenshot was.

A line now qualifies when:

  1. every token is a real chord, a separator, a cue, or at least chord-shaped (chordShaped(): starts A-G, chord-legal characters only, no run of 3+ lowercase letters after the root — so G#dD# and C#d pass, while Cause, Blackis and Don't do not);
  2. at least one token is a real chord; and
  3. real chords are at least half the musical tokens.

Rules 2 and 3 are the lyric guard. Drop either and lines like "A big deal" become chord rows.

An unrecognised token is never treated as a chord. It renders as a neutral dashed pill keeping its literal text, and is never transposed or pitch-coloured — CHORD_RE would read G#dD# as root G# plus suffix dD# and shift only the root, quietly corrupting it on a key change. It stays visible so a bad import can be spotted and fixed. Inline cues (E riff, A (x4)) get a muted italic pill instead, since they aren't broken chords.

2. Bare section labels become headings

Intro Riff:, Verse 1:, Chorus: — what chord sites and OnSong actually emit. Only {c:...} became a heading before, so the shipped showcase song looked immaculate while the structure of every imported song was invisible.

The colon must be the last character, which excludes metadata rows like Key: G (they carry a value), and chord lines win the tie so E: stays a chord.

Verification

Tested against the owner's chart, transcribed from their screenshot — 14 assertions covering headings, recovered chords, neutral rendering of mangled tokens, cue styling, and that transposing never alters an unrecognised token. Ten ordinary lyric lines still parse as lyrics.

Existing suites green: song links 24, showcase 11, wake lock 11, UI audit 18. The six seed songs render byte-identically. CI equivalents run locally.

Known and unresolved

What mangled G#d, and what ate the spaces in "driving downthe" / "Jack Blackis", is still unexplained. Both are in the stored text, not the rendering, so this PR does not address them — that needs the raw imported characters.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RFni8j63y7ynwzmNLMPMTB


Generated by Claude Code

…(v2026.09.07.002)

Owner sent a screenshot of a ZZ Top chart from their library with almost no
coloured chords and no visible section markers. Two detection defects.

1. isChordLine required EVERY token on a line to be a chord, so a single
mangled token dropped the whole line -- its good chords included -- to plain
lyrics. "E G#dD#" lost its E. A song pasted with damaged chords showed almost
none, which is what the screenshot was.

A line now qualifies when every token is a chord, a separator, a cue, or at
least chord-SHAPED (starts A-G, chord-legal characters only, no run of 3+
lowercase letters after the root -- so "G#dD#" and "C#d" pass while "Cause",
"Blackis" and "Don't" do not); at least one token is a REAL chord; and real
chords are at least half the musical tokens.

Those last two rules are the lyric guard. Drop either and lines like "A big
deal" become chord rows; with them, ten sampled lyric lines stay lyrics.

An unrecognised token renders as a neutral dashed pill keeping its literal
text, and is never transposed or pitch-coloured -- CHORD_RE would read
"G#dD#" as root G# plus suffix "dD#" and shift only the root, quietly
corrupting it. It stays visible so a bad import can be spotted and fixed.
Inline cues ("E riff", "A (x4)") get a muted italic pill instead, since they
are not broken chords.

2. Bare "Intro Riff:" / "Verse 1:" / "Chorus:" labels -- what chord sites and
OnSong actually emit -- now become headings. Only {c:...} did before, so the
shipped showcase song looked immaculate while the structure of every imported
song was invisible. The colon must be the last character, which excludes
metadata rows like "Key: G", and chord lines win the tie so "E:" stays a
chord.

Both fixes are at render time, so songs already in a library heal without
being re-imported.

Verified against the owner's chart transcribed from the screenshot: 14
assertions covering headings, recovered chords, neutral rendering of the
mangled tokens, cue styling, and that transposing never alters an
unrecognised token. Ten ordinary lyric lines still parse as lyrics. Existing
suites green -- links 24, showcase 11, wake 11, UI audit 18 -- and the six
seed songs render byte-identically.

Still unexplained: what mangled "G#d" and joined words like "downthe" on the
way in. That needs the raw stored text, which the owner is sending as a song
link.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RFni8j63y7ynwzmNLMPMTB
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@cdburgess75
cdburgess75 merged commit 2063eb8 into main Sep 7, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants