Keyfifth flip examples

[rpatters1]

This PR proposes two new examples to clarify edge cases around keyFifthsFlipAt in part-transposition. I would have preferred to combine them in a single example, but my tools (MuseScore and Finale) each can only do part of the example.

• keyfifths-flip.json illustrates flipping around the edge case values 5, 7, and 8. The result is this:

• keyfifths-flip-2.json illustrates what happens if keyFifthsFlipAt is omitted:

One reason I am submitting these examples is that I want to be certain that I have interpreted the text of the specification correctly.

[mscuthbert]

Wow. Wonderful. I'm wondering if there should be a default of 8? That allowing double sharp key signatures should have to be opted into?

For A clarinet and other sharp instruments I suppose though it would want a default of -8. And that's hard to have both.

[rpatters1]

From the spec:

If this value isn't provided, default behavior is to not flip the key signature.

One reason I posted this example was to be certain it was the intended consequence. (Double sharps/flats in signature.) For reference, Finale does this. It keeps piling on sharps or flats until it maxes out its 4-bit bucket for accidentals. Meaning it will keep piling them on until you reach 7 septuple flats or sharps. (The only arguable use case for this is key signatures on larger EDO values than 12-EDO, which Finale can represent, but even that is no more than a theoretical use case. It seems to me Phil Farrand was just fascinated by the mathematical side of music notation.)

FWIW: I think keyFifthsFlipAt being a signed value is confusing. Unless I fundamentally misunderstand something, the sign is always going to be in the direction opposite the transposition delta, so the sign can be inferred. Being signed just leaves an opportunity for an implementer to get it wrong. If it were changed to an unsigned value, then the default could be 8.

EDIT: I also question the utility of any absolute value less than 5, since that also leads to double sharps/flats in the key sig. I would be interested to know if such a thing ever happens in actual music notation read by humans to make music.

[rpatters1]

As a total aside in the weeds, here is an actual use case for the Finale behavior that is more of a workaround. Finale has an artificial limit of +/-7 alterations. When the microtonalists set up higher EDOs, e.g., 96-EDO (with 8 divisions per half step), they can't reach a full chromatic half step with the available alterations. The workaround is to change the key so that the needed sharp or flat note is in the key and turn on the "hide key sig and show accis" option. That displays them correctly. Not something we need to worry about here at MNX, though.

[mscuthbert]

EDIT: I also question the utility of any absolute value less than 5, since that also leads to double sharps/flats in the key sig. I would be interested to know if such a thing ever happens in actual music notation read by humans to make music.

This might be a legacy of the original way we designed the specification in person which was originally from the perspective of concert pitch (so flipsAt = 8 for Eb Sax would have been flipsAt = 5, and any change of transposition would have required a change of flipsAt) -- the specification changed before announcing, but we didn't have a chance to see if there were any other things to tighten up in the process.

Note though (as I'm sure you do know RP, but for others) that this is not just a specification for key signatures, but for enharmonics as well; so it can be useful even if a key is defined but the key signature is not displayed, and where double accidentals are not a conceptual problem as they are in key signatures.

(Good to know all this about the arcane insides of Finale's key system -- I remember composing a 19-tone piano duet piece [where # and b were not enharmonic] and being deep in that world for a few months). I think I've forgotten (and never documented) why music21 also has a limit of quadruple sharp after like v0.2 even though the original idea was to allow arbitrary numbers of sharps and flats; there was some very common optimization step that would've run much slower if the combination of step+octave did not define a finite range of midi numbers)