useAccidentalDisplay and accidentalDisplay

[rpatters1]

I am beginning a project to export MNX directly from Finale musx files. The goal is to lose far less information than the current musicxml export does. I've hit a snag straight out of the gate with useAccidentalDisplay and accidentalDisplay. Finale has floating accidentals that are determined by the program, and it has forced courtesy accidentals that the user sets (either on or off). How do I capture this with these options?

I could set useAccidentalDisplay and then specify all the accidentals. But then it seems like the floatiness of the floating accidentals would be lost. Since this is nearly all of them, that seems like a bad decision. Conversely, if I don't set useAccidentalDisplay, then I am forbidden (by the manual) from using accidentalDisplay, so I would lose the force on or off accis, which would be a major annoyance in an import.

Is there something I am missing?

[mscuthbert]

This is me speaking for myself, not for the W3C chairs or the decisions of MNX.

I'm a big advocate (since working the hard way w/ music21) of allowing formats to store for each accidental, (1) "what is its state? displayed, hidden, or unknown" (2) "why is it in that state? prior note w/ same accidental, prior with conflicting, user override, courtesy prior from previous measure, courtesy from conflict in other part, unknown, etc." and then (3) for this accidental, this region, or the piece as a whole, what is its "accidental strategy": "normal, show every accidental unless immediate repetition, show all even with immediate repetition unless tied, hide all but absolutely necessary accidentals, hide all including necessary, unknown... etc."

For displaying a score thats been given to you, (1) is all that's needed -- show or hide accidentals. For transposing, excerpting, etc. (2) and (3) are what's needed -- 1 will need to be recalculated. Most of our existing formats are designed for case (1) only, which is why editing after importing can be so frustrating.

[rpatters1]

Given that there seems to be a stated goal of being able to use MNX as a native file format (rather than just an interchange format), I think all of the above make sense. Then an exporter could implement as many or as few of them as can be implemented from its source data.

As I get a few more toes into the water, my first impressions make me think the current spec has not much addressed the kinds of requirements a native format would have. Despite the interesting aspirational goals, it seems to be focused on being an interchange format. This accidentals issue is just one symptom.

[adrianholovaty]

Thanks for bringing this up — I agree it's a "hole" in the existing MNX spec.

We discussed this in the latest co-chairs meeting and came up with the following proposal:

• The "accidental display" object gets a new key, "force", which is a boolean. (Its default value is false.) This value would mean "this accidental was intentionally set by the user, as opposed to being automatically determined."

@rpatters1 Do you think that would do the job?

[rpatters1]

That certainly matches what Finale does. Just to be clear: this would force both show true and show false.

[rpatters1]

Just so I understand it, this would still require useAccidentalDisplay and then an accidental display on every note? I am honestly a little unclear what the need for the global setting is.

[adrianholovaty]

Yes "force" would apply in both cases: "This is forced to be displayed" and "This is forced to be hidden." It would still require "useAccidentalDisplay": true.

The purpose of that global "useAccidentalDisplay" setting is to support encoding music in which the accidental display is unknown or left to consuming software to decide. For example, consider audio- (as opposed to notation-) focused software that generates MNX. It might not have its own algorithm for determining whether a note's accidental gets displayed; perhaps it only cares about the sounded pitches as opposed to the visual notation. If we didn't have "useAccidentalDisplay", then the software would be forced to calculate the accidental display for each note. Hopefully that makes sense?

At any rate, I'm ready to update the spec to add the optional "force" key, as outlined above. Could you confirm this would meet your needs?

[mscuthbert]

Not the recipient of the Q but I'm for it.

[rpatters1]

Isn't accidental display optional? If it is omitted, the software figures it out. If it is included, the software (may) use it. I am still confused about why a global setting is needed.

[adrianholovaty]

If accidentalDisplay is omitted for an individual note, there are two possible interpretations:

• Don't display an accidental on this note.
• Consuming software should decide whether to display an accidental on this note.

If the global useAccidentalDisplay is true, then we use interpretation 1. If useAccidentalDisplay is false, then we use interpretation 2.

Does that clear it up?

[rpatters1]

I guess a clarification along these lines in the docs would help. Personally, I think the interpretation should always be the second interpretation (when omitted) and then the accidentalDisplay object could be used to override.

Is there any reason for accidentalDisplay to be disallowed when useAccidentalDisplay is false? This would allow for accidental overrides and yet allow software to decide both their presence or absence if accidentalDisplay is absent.

[rpatters1]

I should add that, for Finale exports, it seems to me that it would make the most sense to omit the accidental display except when they are forced. But under the current spec It appears that I will have to add one to every notehead, forced or no.