Add hint as to whether an accidental has been deliberately displayed or hidden

[mdgood]

MusicXML represents whether accidentals appear or not, but nothing indicates if this is a result of applying standard music notation rules, or a deliberate choice to display or hide an accidental. This hint could be helpful for higher-quality exchange between interactive applications doing transposition and other types of formatting.

This will run into similar problems as a stem direction hint in terms of there being no uniform cross-application definition of a "usual direction". However, like that hint, it can suggest why an engraving is done a certain way, in a form that is both relatively simple and reasonably portable across applications.

Since missing accidentals are omitted from the MusicXML 3.0, a new "none" accidental value may be needed, to be used only in conjunction with a hint that the accidental has been deliberately hidden.

This issue was raised in multiple conversations with MusicXML developers at the NAMM and Musikmesse shows, as well as via private email.

[joeberkovitz]

I agree that this is a problem and Noteflight's data model has had to address this concern separately, as a further validation that the issue is significant. However, I feel that this falls into a large category of semantic/visual gray areas in MusicXML that need more careful thought before being resolved.

I do not see this issue as a showstopper for interop. MusicXML has lacked this capability for some time and it does not prevent import/export from working acceptably, nor has it encouraged developers to roll their own out-of-band mechanism. Until authors modify the measure containing the accidental, the issue is not detectable, and when they do, they are in a position to correct it in the host application.

[artexanis]

"but nothing indicates if this is a result of applying standard music notation rules, or a deliberate choice to display or hide an accidental"

Which rules? There are a lot of (conflicting) rules. (eg: http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Displaying-pitches#Automatic-accidentals)

I think we need this because it's not clear what 'standard music notation rules' are. Lilypond has 14 different ways of placing accidentals.

Maybe we can specify which 'accidental method' was used (in the 'defaults' element). It's easy to spot divergent accidentals and handle them correctly.

[mscuthbert]

Ah -- this has been a recent discussion of the current W3C group for MNX (@adrianholovaty and @dspreadbury) and something we've been taking up in the talk on #288 . The reason why idea is still relevant. (music21's accidental.displayStatus vs accidental.displayType might be useful here).

There may be three separate things to consider: what the general rule for displaying accidentals is (music21's displayType), whether it's displayed or not (music21: displayStatus; mnx new's: accidentalDisplay), and (newly) what of the rules apply here (something music21 doesn't have a setting for, but if we did it would greatly simplify recomputing displayStatus based on displayType when another note in the measure changes).

Something that took a lot of time for us recently (solved by @gregchapman-dev at cuthbertLab/music21#1545) was dealing with the interpretation of accidentals on realized ornaments (what does Trill+# mean when trilling on E (or E#) in G major? and does it differ based on any F-naturals earlier in the measure?). Things to think about.

[adrianholovaty]

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