Clarify defaults and behavior for accidental attribute

[mdgood]

In the current spec, the note element's accidental attribute is described as follows:

The accidental attribute supplies an accidental value for this note. In the standard MNX-Common profile, this attribute must match the alteration of the pitch attribute. Omission of the attribute indicates that no accidental is to be displayed. The special value auto indicates that a consumer application should determine the proper accidental based on musical context.

Omitting the attribute to indicate the absence of an accidental is what MusicXML does, but it has proven to be one of the more error-prone decisions. It would be good to revisit this and reconsider other possibilities. Perhaps a missing attribute could default to the "auto" value, and there could be a "no" value to indicate that no accidental is displayed.

[bhamblok]

I agree, but I would prefer the "none" value instead of "no", like in the css-world "display:none" or "border:none" ...

[shoogle]

Is there a need for a "no" value? Is it not enough to have "auto" (the default, which only displays an accidental when necessary) and "yes" (to force one to be displayed - i.e. a cautionary accidental)?

[adrianholovaty]

I agree with @mdgood that people should have to explicitly "opt-in" to deliberately hide accidentals, rather than relying on the lack of an attribute. I think it makes sense to treat missing data as "auto" as a general principle throughout MNX-Common.

Here's a quick attempt at outlining the possibilities for rendering accidentals. It errs on the side of too many options, just in case this triggers any ideas from people. Please let me know what I missed!

--

1. Accidental is explicitly rendered; it was deliberately chosen by the score creator (it "should be preserved even if the chromatic context is changed by edits," from a to-do note in the spec)
2. Accidental is explicitly rendered; it was chosen automatically by software (and, as such, is presumably more fungible than option 1)
3. Accidental is explicitly rendered but technically unnecessary (e.g., a courtesy accidental; we'd likely need to define "technically unnecessary")
4. Accidental is explicitly not rendered due to being in the key signature
5. Accidental is explicitly not rendered due to a previous note in the bar having already rendered it
6. Accidental is explicitly not rendered for some other editorial reason (I can't think of any reasons...help?)
7. "Auto" (leave accidental rendering for the MNX-Common consumer program to decide)

--

Some questions that came up as I pondered these cases:

• Question 1: Do people need to distinguish between cases 1 and 2? The aforementioned to-do note in the spec seems to indicate this was important to Joe.
• Question 2: If we decide to distinguish cases 1 and 2, what is the specific markup to differentiate them? Does it go within the accidental attribute (hence creating another microformat), or is it a separate attribute?
• Question 3: For courtesy accidentals (case 3), what is the specific markup to specify a courtesy accidental? Would be nice to have a unifed answer with question 2.
• Question 4: Do people need to distinguish between cases 4 and 5? It seems to me to be an implementation detail — but if MNX-Common is to be used as an internal file format, maybe it makes sense...?
• Question 5: Is case 6 feasible or only theoretical?
• Question 6: If an MNX-Common file mixes "auto" with explicit accidental data within the same bar for the same part, what (if anything) should the spec encourage implementers to do?
• Question 7: Putting this all together, which cases should we explicitly support?

[hhpmusic]

In braille music transcription, the display of accidentals should be explicitly indicated other than "auto", which will increase the load of braille conversion. There are also rules for braille music to add auxiliary accidentals, so the explicit indication is much useful than just an "auto". For missing attributes, is it the same case in Musicxml where there are only alter without accidental? This will give the same result of not displaying an accidental, such as the one repeated or just in a key.

[adrianholovaty]

I believe this can safely be closed, since we added the "support" key with "useAccidentalDisplay" in f3cf6cc20. See #347 for the history/discussion.