question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

MusicXML accidental support

See original GitHub issue

This is a documentation of the current state of MusicXML accidental support in OSMD, based on the currently used VexFlow version. The end goal is to support all MusicXML accidentals.

MusicXML OSMD SMuFL class / glyph VexFlow 1.2.93 Notes
sharp SHARP accidentalsStandard / accidentalSharp #
natural NATURAL accidentalsStandard / accidentalNatural n
flat FLAT accidentalsStandard / accidentalFlat b
double-sharp DOUBLESHARP accidentalsStandard / accidentalDoubleSharp ##
sharp-sharp accidentalsStandard / accidentalSharpSharp TBD Verify if concatenation of accidentals is feasible
flat-flat DOUBLEFLAT accidentalsStandard / accidentalDoubleFlat bb OSMD also recognizes value double-flat which is absent from MusicXML
natural-sharp accidentalsStandard / accidentalNaturalSharp TBD Verify if concatenation of accidentals is feasible
natural-flat accidentalsStandard / accidentalNaturalFlat TBD Verify if concatenation of accidentals is feasible
triple-sharp TRIPLESHARP accidentalsStandard / accidentalTripleSharp ###
triple-flat TRIPLEFLAT accidentalsStandard / accidentalTripleFlat bbs OSMD’s TRIPLEFLAT uses a VexFlow accidental that is different than the one encoded in MusicXML. TBD Verify if concatenation of accidentals is feasible
quarter-flat QUARTERTONEFLAT accidentalsSteinZimmermann / accidentalQuarterToneFlatStein OR accidentalsAEU / accidentalKomaFlat d The interval values are different because Stein-Zimmerman is 24-TET and AEU (Turkish) is 53-TET
quarter-sharp QUARTERTONESHARP accidentalsSteinZimmermann / accidentalQuarterToneSharpStein OR accidentalsAEU / accidentalKomaSharp + The interval values are different because Stein-Zimmerman is 24-TET and AEU (Turkish) is 53-TET
three-quarters-flat THREEQUARTERSFLAT accidentalsSteinZimmermann / accidentalThreeQuarterTonesFlatZimmermann db
three-quarters-sharp THREEQUARTERSSHARP accidentalsSteinZimmermann / accidentalThreeQuarterTonesSharpZimmermann ++
slash-quarter-sharp SLASHQUARTERSHARP accidentalsAEU / accidentalKucukMucennebSharp ±
slash-sharp SLASHSHARP accidentalsAEU / accidentalBuyukMucennebSharp
slash-flat SLASHFLAT accidentalsAEU / accidentalBakiyeFlat bs
double-slash-flat DOUBLESLASHFLAT accidentalsAEU / accidentalBuyukMucennebFlat bss
sharp-down
sharp-up
natural-down
natural-up
flat-down
flat-up
double-sharp-down
double-sharp-up
flat-flat-down
flat-flat-up
arrow-down
arrow-up
sharp-1
sharp-2
sharp-3
sharp-5
flat-1
flat-2
flat-3
flat-4
sori SORI accidentalsPersian / accidentalSori o
koron KORON accidentalsPersian / accidentalKoron k
other Fallback to smufl attribute which specifies an explicit SMuFL glyph name
- - - ashs VexFlow’s Arabic-Sharp-Half-Sharp is not encoded in MusicXML nor in SMuFL
- - - afhf VexFlow’s Arabic-Flat-Half-Flat is not encoded in MusicXML nor in SMuFL

Issue Analytics

  • State:open
  • Created 2 years ago
  • Reactions:2
  • Comments:9 (9 by maintainers)

github_iconTop GitHub Comments

2reactions
infojunkiecommented, Nov 26, 2021

Updated table with fix above 🎉

2reactions
infojunkiecommented, Nov 11, 2021

Regarding the alter value of the accidentals, this is where things get complicated 😅 In a nutshell, different accidentals refer to different tuning systems and/or different notation systems (these are 2 different things), which may end up with overlapping intervals and therefore overlapping accidentals.

For example, quarter-flat in Stein-Zimmermann notation has the same value as flat-up in Gould arrow notation and slash-flat in Arabic notation (all of which are actual MusicXML accidental values).

Same for different accidentals representing quarter-sharp in different systems.

Read more comments on GitHub >

github_iconTop Results From Across the Web

The <accidental> element | MusicXML 4.0
The <accidental> element represents actual notated accidentals. ... Applications reading a MusicXML file that can understand both features should generally ...
Read more >
Accidentals on trills and turns in MusicXML - Music
The <accidental-mark> element refers to the ornament that precedes it when used as ... and are not widely supported in current applications.
Read more >
MusicXML import and export do not support non-standard key ...
MusicXML supports these key signatures… ... On import we can use key-accidental to determine the microtonal accidentals to import.
Read more >
MusicXML 4.0
7 issues involved better support for relationships between scores and parts: ... Adding support for additional SMuFL accidental glyph names ...
Read more >
New: Support for cautionary accidentals | The Soundslice Blog
If you create slices by importing from MusicXML files, then you're in good shape: we've improved our MusicXML importer to detect cautionary ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found