Closed mogenslundholm closed 1 month 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
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.
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.
The absence of an <accidental>
element is how you say "Here there shall be no accidental" in MusicXML.
Sure this would do - but then you have to not allow automatic accidentals (to be sure there will not come an accidental anyway).
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.
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.
This is now addressed by our "support"
key with "useAccidentalDisplay"
from f3cf6cc20. See #347 for the history/discussion.
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.