Four tester-reported GP-import issues, all in the converter/parse layer:
* String count (bugs 2 & 4): <tuning> is padded to 6 slots, so a 4-string
bass, 5-string bass and 6-string guitar were byte-identical and the real
count was lost — a 5-string bass played on 4 strings and a 4-string bass
showed a phantom B in the editor. Record the authoritative count in a new
<tuning stringCount=N> attribute (gp2rs._build_xml) and trim the padded
tail back to it on read (song.parse_arrangement). All consumers already
trust a non-6 tuning length (arrangement_string_count, the editor's
_stringCountFor and build-time _normalize_tuning_to_count), so this fixes
the create-mode preview AND the built sloppak with no consumer changes.
* Lead/Rhythm reversed (bug 3): guitar arrangements were named by appearance
order (first guitar -> Lead), swapping roles for files that list Rhythm
before Lead. Honor 'lead'/'rhythm' in the GP track name; unhinted tracks
keep positional fallback. Applied to both convert_file's fallback (the
editor's track_indices-without-names path) and _auto_select_gpx, with
cross-role dedup so name-based and positional labels can't collide.
* Preview note count (bug 1): the importer's per-track count included
tie-continuation notes, which are folded into the previous note's sustain
and never become separate RS notes (260 shown vs 241 imported). Exclude
tie destinations so the preview matches the imported result.
Adds regression tests for all three. Bug 5 (no stems from synced audio) is
environment-dependent (best-effort demucs backend) and not addressed here.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
