Don't use a `cautionary` attribute for accidentals

[lemzwerg]

As we all know, a 'cautionary accidental' can be one of three things:

1. an ordinary accidental
2. an accidental in parentheses
3. an accidental over the note

As much as I love semantic concepts, I think we should avoid the term 'cautionary' since it is too ambiguous IMHO, and it gets really problematic in the case of transpositions.

Consider the following example.

Obviously, the flat with parentheses is a cautionary accidental. However, if we transpose this to an instrument in B-flat, we should be able to automatically get the following:

As can be seen, we now have two cautionary accidentals in the second bar, where the first one must not have parentheses.

I thus propose to split the cautionary attribute into two attributes: forced and parentheses. In the example above, the first flat in the second bar would have the attribute forced, and the second one parentheses. [The second note in the second bar would also get a forced attribute, BTW.]

It would also be backwards-compatible to MusicXML, where major notation programs (I tested Finale and MuseScore) render the cautionary attribute unconditionally as a parenthesized accidental; this could be then directly mapped to the suggested parentheses attribute.

This issue is related to #287; however, I think it makes sense to have this separate since the discussion in the other issue is already very long, and my suggestion covers only a small part of it.

[adrianholovaty]

Thanks for opening the issue. Just pointing out that #288 had some related conversation that's perhaps relevant here.

[williamclocksin]

Yes. Naming things is always an issue, and it is good to look for better ways to name things. I’ve never liked the term ‘cautionary’ for the reasons listed by Werner and also by the extra freight that the term ‘caution’ bears. On 17 Apr 2024, at 06:40, Werner Lemberg @.***> wrote: As we all know, a 'cautionary accidental' can be one of three things:

an ordinary accidental an accidental in parentheses an accidental over the note

As much as I love semantic concepts, I think that we should avoid to use the term 'cautionary' since it is too ambiguous IMHO, and it gets really problematic in the case of transpositions. Consider the following example. image.png (view on web) Obviously, the flat with parentheses is a cautionary accidental. However, if we transpose this to an instrument in B-flat, we should be able to get the following: image.png (view on web) As can be seen, we now have two cautionary accidentals in the second bar, where the first one must not have parentheses. I thus propose to split the cautionary attribute into two attributes: forced and parentheses. In the example above, the first flat in the second bar would have the attribute forced, and the second one parentheses. It would also be backwards-compatible to MusicXML, where major notation programs (I tested Finale and MuseScore) render the cautionary attribute unconditionally as a parenthesized accidental; this could be then directly mapped to the suggested parentheses attribute. This issue is related to #287; however, I think it makes sense to have this separate since the discussion in the other issue is already very long, and my suggestion covers only a small part of it.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[mscuthbert]

My feeling is still similar to 288 but maybe things have changed that it's worth stating in brief and another way.

There are three things (at least) to consider in rendering an accidental or not:

1. Do we know if this accidental is displayed or not? Yes/No/Unknown. If unknown we better figure it out before drawing. (Music21 calls it displayStatus)

2. What has the user expressed as a wish for the accidental? Maybe they always want it displayed. Or never. Or just normal display according to context. Or generally don't display but do if not displaying it definitely means it will be interpreted wrong. Music21 calls this displayType. If the note changes or the note context (key or notes around it) change then the accidental displayStatus can be reconstructed from displayType, unless it's "normal" in which case we turn to...

3. What is the overall strategy for determining accidental rendering in this piece. Does it behave according to normal rules regarding cautionary by barline and octave, or just what's the minimum to make the notation correct (the minimum I'd expect a notation renderer to follow), or is it Webern style (accidentals on almost every note except immediate repetition or obvious), or early Cage (accidental on every, I mean every note) or a sort of modal chant interpretation (accidentals only when displayType is always otherwise hidden). Every notation engine has this encoded in some way, most just don't have a way it can be changed.

Encoding just on or off is enough for rendering a static score like as a PDF or Vexflow etc. but at least 1+2 is needed for any notation editor.

[lemzwerg]

@mscuthbert What I want is to tag an accidental semantically as

"Show always an accidental without parentheses, and if there would be no accidental normally, show a natural."

As mentioned above, this is for automatic transposition. Answers to your items in the last comment are thus

1. yes
2. always display
3. irrelevant, since accidental style selection is a higher-level concept and shouldn't affect the low-level encoding of MNX

[adrianholovaty]

In a12a2575, I changed accidentals to encode the literal symbol as opposed to their semantics. Upon discussing this a few weeks ago with my fellow co-chairs, we decided we'd err on the side of practicality here, rather than pure semantics. It's much more practical to simply encode the symbol. :)

In the future, we may add a "reason" key that would provide some additional semantics for why the accidental has been given the symbol it's been given.

[lemzwerg]

It's much more practical to simply encode the symbol. :)

Given that you completely loose the ability to get decent transposition with this simplistic solution I suggest that you implement the reason key right now...