w3c / mnx

Music Notation CG next-generation music markup proposal.
176 stars 19 forks source link

Specify "accidental" to overrule the value of "alter" and having a "no accidental". #180

Closed mogenslundholm closed 1 month ago

mogenslundholm commented 7 years ago

Some time ago I wrote about some problems with MusicXML-files in the collection of the Turkish Makam music. One construction is:

<accidental/> or <accidental></accidental>

I thought that there was no sense in this, but now I changed my mind. Like you can force a specific accidental to be written, you must be able to force no accidental (nothing) to be written. The value "natural" is not sufficient, because this means remove current sign, defined in the predefined keys or on previous note in the current measure. This writes the natural sign.

There must be a specific accidental saying "no accidental" in order to specify that the value of "alter" e.g. <alter>-0.5</alter> shall be overruled.

This could be "<accidental>void</accidental>" (adding "void" to the list of accidentals) or just like it's done in the Turkish Makam songs: <accidental/>

I think that note.mod should be changed - the text from note.mod: "Actual notated accidentals. Valid values include: sharp,..." should be changed to something like: "Actual notated accidentals overwrite the values specified by the alter-command concerning the graphic appearance. Valid values are even an empty field (<accidental/>) and include..."

Consequences: There will be no backward compatibility problems since old systems can't handle this anyway.

mogenslundholm commented 7 years ago

There are "quarter-sharp" and "quarter-flat", there is "slash-quarter-sharp" but no "slash-quarter-flat". There is "double-slash-flat, but no "double-slash-sharp".

Michael Good has mapped these to the makam-commas 1,4,5,8. (Re: Accidentals of Turkish Music). But what about comma 2,3,6 and 7? There are "sharp-1" to "sharp-5" and "flat-1" to "flat-4". If these are intended for the makam commas there should also be "sharp-6" and "sharp-7" et vice versa for flat. Maybe even "sharp-8" = "slash-sharp" and "flat-8" = "double-slash-flat"?

Is it a Musescore problem? Is this a Finale problem? When I don't know what the accidentals mean from the note.mod-description, how can I claim that Musescore and Finale does it wrong?

Because it is impossible to put them right due to some automatic calculation based on the alter-value. The note.mod file need to say exactly this: <accidental> shall define the accidental and even be able to specify specify "no accidental". Only when there is no accidental-definition at all, the notation program may calculate an accidental to be applied.

Note that w3c/musicxml#108 also addresses this issue

mdgood commented 7 years ago

The empty accidental element is a bug in the export software which appears to be being fixed. The absence of an accidental element is what is used to indicate no accidental, as long as there is no supports element indicating the contrary.

The accidentals listed in MusicXML and SMuFL are the ones that are used in Turkish maqam repertoire.

Clarifying and perhaps simplifying the relationship between the accidental and alter elements could be a topic for MNX.

mogenslundholm commented 7 years ago

I worked with this tune from the makam-suite: hicazkar--kocekce--aksak--gece_gunduz--muallim_ismail_hakki_bey Used Finale and Musescore but had to give up. I cannot get the accidentals right. Finale-problem? Musescore-problem? Or caused by the MusicXML-specification?

I think this should be obvious: If I specify an accidental it is because there shall be this accidental. But I cannot say: Here there shall be no accidental.

mdgood commented 7 years ago

The absence of an <accidental> element is how you say "Here there shall be no accidental" in MusicXML.

mogenslundholm commented 7 years ago

Sure this would do - but then you have to not allow automatic accidentals (to be sure there will not come an accidental anyway).

mdgood commented 7 years ago

That is correct, but that is more the domain of issue w3c/musicxml#108. That issue gets into the area where MusicXML or MNX could do a better job of encoding engraving intent. In general MusicXML 3.0 does not support this, and it is a design area that is outside the scope of MusicXML 3.1.

mdgood commented 4 years ago

I am transferring this issue over to the MNX repository. Although the current version of the MNX-Common spec tries to make this easier with an optional accidental attribute, the design of that attribute could likely be improved. For example, we might make the special value "auto" the default, so that the attribute is only needed for forced, alternate, or hidden accidentals.

adrianholovaty commented 1 month ago

This is now addressed by our "support" key with "useAccidentalDisplay" from f3cf6cc20. See #347 for the history/discussion.