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:

[mscuthbert]

Oh, as a renderer (something you can script MusicXML in and Image out), MuseScore is possibly/probably the best in the business. And I say this as someone who has never used it as their primary scorewriter.

[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).