We render Sibelius-exported MusicXML with alphaTab 1.8.4 (@coderline/alphatab). Two standard MusicXML features are silently dropped by the MusicXML importer. We verified the dist of both 1.8.4 (latest stable) and 1.9.0-alpha.1891.
1. Slur placement is ignored
The MusicXML importer's _parseSlur(element, note) only reads number and type (start/stop). The placement attribute ("above"/"below") is never read, so the model carries no orientation information and slur layout relies purely on heuristics (stem direction etc.).
Consequence: explicitly placed slurs may render on the wrong side of the staff. Empirical test: taking a file with <slur type="start" number="1" placement="above"/> and flipping all placements to below produces pixel-identical rendered output.
<notations>
<slur type="start" number="1" placement="above"/>
</notations>
Expected: the parsed orientation should be stored on the slur and respected by layout (falling back to the current heuristics only when placement is absent).
2. Caesura and breath-mark articulations are not parsed
_parseArticulations(element, note) handles accent, strong-accent, staccato, tenuto and a few others, but breath-mark and caesura — standard MusicXML articulation elements since MusicXML 1.0 — are not handled at all (the strings "caesura" and "breath-mark" appear 0 times in the whole 1.8.4 dist). They are silently discarded on import, so scores with phrase/section markings lose them when rendered.
<notations>
<articulations>
<breath-mark>comma</breath-mark>
</articulations>
</notations>
<!-- and -->
<notations>
<articulations>
<caesura>normal</caesura>
</articulations>
</notations>The SMuFL range "Breaths and caesuras" has ready glyphs (breathMarkComma U+E4CE, breathMarkTick U+E4CF, caesura U+E4D1, caesuraThick U+E4D2, caesuraShort U+E4D3 per SMuFL glyphnames.json), and Bravura ships them.
Expected: parse these articulation elements into the model and render the corresponding glyphs.
Notes
- Rendering backend/OS: browser (SVG), but the gap is in the importer/model, so it is backend-independent.
- We are happy to provide full sample files if helpful.
We render Sibelius-exported MusicXML with alphaTab 1.8.4 (
@coderline/alphatab). Two standard MusicXML features are silently dropped by the MusicXML importer. We verified the dist of both 1.8.4 (latest stable) and 1.9.0-alpha.1891.1. Slur
placementis ignoredThe MusicXML importer's
_parseSlur(element, note)only readsnumberandtype(start/stop). Theplacementattribute ("above"/"below") is never read, so the model carries no orientation information and slur layout relies purely on heuristics (stem direction etc.).Consequence: explicitly placed slurs may render on the wrong side of the staff. Empirical test: taking a file with
<slur type="start" number="1" placement="above"/>and flipping all placements tobelowproduces pixel-identical rendered output.Expected: the parsed orientation should be stored on the slur and respected by layout (falling back to the current heuristics only when
placementis absent).2. Caesura and breath-mark articulations are not parsed
_parseArticulations(element, note)handles accent, strong-accent, staccato, tenuto and a few others, butbreath-markandcaesura— standard MusicXML articulation elements since MusicXML 1.0 — are not handled at all (the strings "caesura" and "breath-mark" appear 0 times in the whole 1.8.4 dist). They are silently discarded on import, so scores with phrase/section markings lose them when rendered.The SMuFL range "Breaths and caesuras" has ready glyphs (breathMarkComma U+E4CE, breathMarkTick U+E4CF, caesura U+E4D1, caesuraThick U+E4D2, caesuraShort U+E4D3 per SMuFL glyphnames.json), and Bravura ships them.
Expected: parse these articulation elements into the model and render the corresponding glyphs.
Notes