You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AI-assisted (disclosure block included as described in AGENTS.md)
Current Behavior
Note
AI-authored disclosure (alphatab-ai-authored-v1)
Portions of this content were authored by an AI agent. The agent has read AGENTS.md and the human submitter accepts responsibility for
compliance with the rules in that document.
When a MusicXML score for a fretted instrument carries left-hand fingering in <notations><technical><fingering>, every value is imported one finger lower than written.
Loading the attached four-note file (MIDI program 24, acoustic nylon guitar) and reading Note.leftHandFinger:
written <fingering>
imported as
1
Fingers.Thumb
2
Fingers.IndexFinger
3
Fingers.MiddleFinger
4
Fingers.AnnularFinger
Right-hand <pluck> values in the same file import correctly — p/i/m/a become Thumb/IndexFinger/MiddleFinger/AnnularFinger as expected. Only the numeric <fingering> values are shifted.
The shift is visible in rendered output. In a browser, a guitar score whose MusicXML holds the fingering sequence 4 3 4 1 3 1 displays as 3 2 3 t 2 t — so every printed fingering is wrong, and a written 1 appears as a thumb.
Expected Behavior
In MusicXML, <fingering> inside <technical> denotes the fretting-hand finger. For guitar and other fretted instruments the conventional numbering is 1 = index, 2 = middle, 3 = ring, 4 = little, with 0 for an open string — the numbering MuseScore writes and displays. <pluck> is the element that carries the plucking hand (p/i/m/a).
So <fingering>1</fingering> on a guitar part should import as the index finger and print as 1, and the sequence above should display as written: 4 3 4 1 3 1.
Steps To Reproduce
Save the file in "Anything else?" below as fingering-offset.musicxml.
The rendered symptom described above was observed separately, on a full guitar score displayed in a browser — not on this reduced file, which I only loaded and inspected via the API as shown.
Note the instrument matters: with a piano MIDI program the imported values line up with piano numbering and nothing looks wrong. The offset is only apparent on a non-piano (guitar) program.
Link to jsFiddle, CodePen, Project
No response
Version and Environment
[AlphaTab][VersionInfo] alphaTab 1.8.4
[AlphaTab][VersionInfo] commit: 022a45c8e42370f9e12e68949d11eada370da83d
[AlphaTab][VersionInfo] build date: 2026-07-05T14:46:18.224Z
[AlphaTab][VersionInfo] High DPI: 1
[AlphaTab][VersionInfo] Platform: NodeJs
[AlphaTab][VersionInfo] WebPack: false
[AlphaTab][VersionInfo] Vite: false
Also reproduced, with identical output, on the current prerelease:
[AlphaTab][VersionInfo] alphaTab 1.9.0-alpha.1883
[AlphaTab][VersionInfo] commit: a186437bb3263e5ae3f8fd373aef1fef5ebbc7e7
[AlphaTab][VersionInfo] build date: 2026-08-02T03:44:59.527Z
[AlphaTab][VersionInfo] High DPI: 1
[AlphaTab][VersionInfo] Platform: NodeJs
[AlphaTab][VersionInfo] WebPack: false
[AlphaTab][VersionInfo] Vite: false
Node.js v22.23.2, macOS 15 (Darwin 24.6.0).
The rendering symptom was originally noticed in a browser, in an application that displays MuseScore exports. The reproduction above is the reduced Node case; I have not captured printEnvironmentInfo() from that browser session, so I am not quoting browser details I did not record.
Platform
Node.js
Anything else?
Minimal reproducible example. Measure 1 carries <fingering> 1–4; measure 2 carries the equivalent <pluck> values p/i/m/a for comparison.
Is there an existing issue for this?
I have read the contribution rules
AI authorship
AI-assisted (disclosure block included as described in AGENTS.md)
Current Behavior
Note
AI-authored disclosure (
alphatab-ai-authored-v1)Portions of this content were authored by an AI agent. The agent has read
AGENTS.md and the human submitter accepts responsibility for
compliance with the rules in that document.
When a MusicXML score for a fretted instrument carries left-hand fingering in
<notations><technical><fingering>, every value is imported one finger lower than written.Loading the attached four-note file (MIDI program 24, acoustic nylon guitar) and reading
Note.leftHandFinger:<fingering>1Fingers.Thumb2Fingers.IndexFinger3Fingers.MiddleFinger4Fingers.AnnularFingerRight-hand
<pluck>values in the same file import correctly —p/i/m/abecomeThumb/IndexFinger/MiddleFinger/AnnularFingeras expected. Only the numeric<fingering>values are shifted.The shift is visible in rendered output. In a browser, a guitar score whose MusicXML holds the fingering sequence
4 3 4 1 3 1displays as3 2 3 t 2 t— so every printed fingering is wrong, and a written1appears as a thumb.Expected Behavior
In MusicXML,
<fingering>inside<technical>denotes the fretting-hand finger. For guitar and other fretted instruments the conventional numbering is1= index,2= middle,3= ring,4= little, with0for an open string — the numbering MuseScore writes and displays.<pluck>is the element that carries the plucking hand (p/i/m/a).So
<fingering>1</fingering>on a guitar part should import as the index finger and print as1, and the sequence above should display as written:4 3 4 1 3 1.Steps To Reproduce
fingering-offset.musicxml.The rendered symptom described above was observed separately, on a full guitar score displayed in a browser — not on this reduced file, which I only loaded and inspected via the API as shown.
Note the instrument matters: with a piano MIDI program the imported values line up with piano numbering and nothing looks wrong. The offset is only apparent on a non-piano (guitar) program.
Link to jsFiddle, CodePen, Project
No response
Version and Environment
The rendering symptom was originally noticed in a browser, in an application that displays MuseScore exports. The reproduction above is the reduced Node case; I have not captured
printEnvironmentInfo()from that browser session, so I am not quoting browser details I did not record.Platform
Node.js
Anything else?
Minimal reproducible example. Measure 1 carries
<fingering>1–4; measure 2 carries the equivalent<pluck>values p/i/m/a for comparison.fingering-offset.musicxml