Renderers that support notehead-text?

[mmcc-xx]

Are there any MusicXML renderers out there that support the notehead-text element?
Here's the description of the element: https://www.w3.org/2021/06/musicxml40/musicxml-reference/elements/notehead-text/

OpenSheetMusicDisplay does not support it:
opensheetmusicdisplay/opensheetmusicdisplay#823

Thanks!

[infojunkie]

What I would really like to see is a compatibility table for MusicXML elements and attributes, sort of like the MDN Browser Compatibility.

[adrianholovaty]

I agree 100%, and I've actually started working on something with the long-term goal of doing exactly that. (I'm making it for MNX, but it'll be general-purpose enough to work for MusicXML as well.) Hoping to have something ready to show in the coming weeks/months.

[samuelbradshaw]

This would be awesome! However, there is a little difference in potential audience that I think should be considered.

MDN (and CanIUse) are primarily used by developers to help them make prioritization decisions – deciding how to build their product so it can support the most important segments of their target audience. People don't generally use MDN data to decide which browser they will use, or which browser is "best." Instead, it's all about supporting users who use a variety of browsers.

In the case of MusicXML/MNX compatibility, I suspect such a table would start to be used for choosing a single rendering engine – deciding which engine is "best" – the engine with the most features ranked at the top. It could end up turning into an advertisement for some rendering engines, and bad press for others.

It's undeniable that some rendering engines are better than others, or have more features than others, so a chart would be very useful – but it would need to be presented carefully, if it's created under the W3C umbrella, to avoid making it look like W3C is endorsing certain products over others.

[mscuthbert]

I agree about your concerns @samuelbradshaw but I also think that part of a standard committee's purpose is to celebrate ways the standard is making a difference. So maybe we agree not to put red "X"s for unimplemented features anywhere -- that makes sense -- my music21 is probably never going to implement some of the more esoteric playback aspects of any encoding (getting roman numerals right--that we'll do). But things like @mdgood 's saying that Finale supports notehead-text was something I didn't know, and if I could see that someone supported notehead-text I would've probably prioritized putting it into music21 back when that was a huge part of my day. (Maybe I still will -- a second implementation of any part of the standard is always important).

[infojunkie]

In my experience with many MusicXML renderers, I can safely say that they cannot be linearly ordered with respect to their MusicXML support: Depending on the focus of each renderer, some features of MusicXML will be better supported than others. As a developer of music apps myself, I am interested in knowing which features are supported by which renderers, to guide my choice depending on the use case of the apps I develop.

[mscuthbert]

I don't know of any that do. Michael Good did have an explicit notice that people should use the notehead-text element (with its own accidental code) rather than the SMuFL Note name noteheads or Note name supplements. Though it does make it hard for rendering engines that plan to use the SMuFL glyphs to know whether they can display the notehead-text or not. For instance, C# quarter note is supported, but not Cx (double sharp). Whole note, half note, and black note (Quarter and below) noteheads have glyphs, but not breves, etc.

[mdgood]

Finale supports this for text that can be represented using the SMuFL note name noteheads range (maybe the supplement too, I don't remember.)

[infojunkie]

Inasmuch as MuseScore can be used as a renderer, it does support this element. I am using version 4.5.0.

Given this file, it produced this image:

[rettinghaus]

This feature was added for MuseScore 4.5: musescore/MuseScore#25916

[samuelbradshaw]

Does MuseScore provide a way to generate SVGs from a MusicXML file programmatically (via command line, a Python API, or something similar)?

[infojunkie]

You can invoke the MuseScore executable from the console with --export-to filename.svg and many other file types.

I'm not aware of a full doc reference for MuseScore 4, but here's the relevant source file.

[samuelbradshaw]

Nice – good to know. Thanks!

[rettinghaus]

Here's the full list: https://handbook.musescore.org/appendix/command-line-usage

[adrianholovaty]

I'm curious what the use case is for encoding this on a per-notehead basis. Perhaps for educational music you might want some noteheads to have the pitch name and others not to...?

The reason I ask is: when we get around to specifying this for MNX, my instinct would be to encode it at a higher-level, like per-part or even per-document. Just trying to understand the reasons people might need a per-notehead override.

[mscuthbert]

Adrian -- often for teaching you want to include the names on the notes the first time they appear (like in the first measure or two) but then stop including them after the first few notes so as to make students start to learn the names from the staff position instead on counting on the names always being there. But then later when there's the first time that something special appears (like a Bb where the accidental needs to be read from the key signature; or maybe a note on a ledger line) you'd want to have the note name appear for just one note again.

[adrianholovaty]

@mscuthbert Thanks, exactly the kind of use case I was asking for!

[mscuthbert]

Something related to notehead-text (but generally for the opposite end of the beginner<-->virtuoso spectrum) are note identification marks for extreme ledger line pitches:

(from Knussen, Whitman Settings, pub. Faber Music (Elaine Gould's house))

As far as I know MusicXML does not have a setting for these, nor do I know of a semantic encoding for these marks in any encoding (though I didn't check MEI too deeply).

[infojunkie]

An update to the meta-discussion about supported features across renderers:

As part of my work on a MusicXML => MuseScore converter, I was asked to provide a listing for supported MusicXML elements (thanks @rettinghaus !). Doing some research, I found this lovely table by alphaTab that does something similar and which inspired me to take it a step further. I've coded a small XSL transformation that traverses the MusicXML XSD schema and generates a Markdown table of all MusicXML elements and their attributes, initially marked as "not supported". The idea is to copy that table into a documentation page that is then incrementally updated by the code maintainers as they add support to various MusicXML elements. You can see an example here. The XSL is here.

There is more that can be built upon this - for example, linking it to unit tests that exercise various elements to automatically fill the table with pass/fail test results.

I am mentioning this here in case other music app maintainers are interested in this approach and would like to collaborate on taking it further.

[lemzwerg]

Very nice! However, its current form is far too verbose IMHO. Using a slightly adjusted version of your XSL and calling

saxon10 -s:musicxml.xsd -xsl:supported.xsl -o:supported.md
pandoc -f markdown -t pdf < supported.md > supported.pdf

the 6936 lines in supported.md are converted to an output file with 158 pages...

[infojunkie]

Thanks for your interest! Yes, it's quite verbose. Note that it is effectively 2x the size of MusicXML elements, since everything is duplicated between score-partwise and score-timewise. My first thought would be to add a way to filter out elements or attributes as parameters to the XSL.

[mscuthbert]

I would suggest not including score-timewise if it makes a big difference -- we have officially deprecated it for MusicXML and I have never actually seen a (non-test) score-timewise file in the wild.

[infojunkie]

I selected the answer about MuseScore as the featured answer not because I gave it 😇 but because Finale is no longer in operation, whereas MuseScore is.