Open clnoel opened 3 years ago
Is there any problem in following the MusicXML approach and using a <notehead>
element?
@cecilios Yes, there is a problem at least for cue notes which are not merely a variation in notehead size/appearance, but have a semantic aspect as well: the notes in question are actually the part of another instrument and aren't intended for performance by the reader.
There is also a whole question of whether to incorporate cues by reference to a run of notes in some other part, instead of by value i.e. creating a duplicate copy of the other part's notes. Some notation programs support this.
I would suggest breaking out cues into a separate issue because of these important differences.
@joeberkovitz Thank you for the explanation. Then I understand that there are two issues:
<part-layout>
. I understand that this is the topic for this issue #249. If this is the case, the MusicXML approach works well for specifying the symbol, I didn't find any problem with it and also allows to specify a SMuFL glyph. But in any case I'm open to other solutions. As to how to inherit it ... an element <notehead-layout>
analogous to the <stemming-layout>
?There is an existing cue-related issue: #102
A quick look did not find any issue that was about giving a note a "diamond" or an "X" or any other notehead other than the standard open/filled oval. This is going to be vital for representing percussion. This is the place for figuring out any kind of variation of noteheads from the standard closed/open/whole options, such as X, diamond, letter-note, cue-sized, colored, etc.
We might be able to do some of this this with SmufL codes on the notes, and we might also need to do some of this this in
<part-layout>
element if it needs to be combined in an odd way.(Found at https://www.pinterest.com/pin/8655424275488587/)
This was originally listed in https://github.com/w3c/mnx/issues/185#issuecomment-948018127 as Out-of-scope topic (E) and In-scope topic (6).