Add enharmonic indication for switching between transposed and concert score

[mdgood]

A common source of confusion when switching between transposed and concert scores is how to spell accidentals in the view that is not encoded in the MusicXML file. MusicXML could add the ability to suggest when the enharmonic spelling should switch when moving between these two views. Michael Cuthbert (@mscuthbert) suggested this on the MusicXML forum:

For automatically changing concert-pitch-to-transposing scores, the tag that is most needed is an additional flag on the <accidental> or <note> element which specifies whether the enharmonic should be flipped (up or down) when switching from one view to the other. For instance, a passage in 6-sharps for C instruments, should probably become 3 flats (not 9 sharps) for the E-flat alto sax when moved from concert pitch to transposed (similarly, the accidentals should match the rest of the instruments' when going the other way).

See the MusicXML forum discussion at http://forums.makemusic.com/viewtopic.php?f=12&t=2395#p6481.

[mdgood]

If we reframe this issue in terms of differences between a concert score and a transposed part, perhaps #278 could address this.

[mdgood]

After reviewing the past forum discussion, I think that including the inclusion of the score together with parts in #278 is sufficient to address this. It means that you need to use a compressed MusicXML file to address things that cannot be computed automatically, but it seemed the consensus was that this was not as great a problem area as others involving concert scores.

[mdgood]

My current thinking is to leave this issue open in case we do want to add something in the future that helps with figuring out enharmonics in parts beyond looking at all the notes in a part file, but move it out of the version 4.0 milestone. Issue #278 has provided a standard solution for the underlying problem, and with more experience we can see if something more special purpose could help in the future.

[mscuthbert]

Thinking more about the issue, perhaps the <transpose> tag is best used rather than updating the <pitch> element for this. For instance, if I'm playing Bb clarinet and the passage goes to 6 sharps, we would probably specify that it's an A# clarinet (transpose = diminished 3rd instead of major second) -- so perhaps the only thing that is needed (if at all) is an attribute to the transpose tag like enharmonic-only="%yes-no" which specifies that the transposition change exists only for enharmonic spelling and that consumers should not regard this as a change in the instruments' transposition. (Again, this would be optional, but I think quite helpful for analytic software using MusicXML)

[mdgood]

@mscuthbert, could you please help my understand the use case for this? With MusicXML 4.0 we have a standard way to include the individual parts in a .mxl and link them to the corresponding parts in the score file. So these types of distinctions can be made by having the software look directly by comparing the key signature and transposition in the score to the same place in the part.

The features we have added to put this information in the score has generally been to help notation importers do the right thing for parts when all they get is a score file. However I agree with @joeberkovitz's comment in the forum discussion that most notation programs are already doing these simplified transpositions.

I'm sure there are cases where other types of programs could use information just in the score. But for enharmonic spellings I think the transposition isn't quite enough; sometimes you need the note-level data too.

Thanks for any further help in providing the bigger picture here!

[mscuthbert]

[what's] the use case for this?

It's this one:

The features we have added to put this information in the score has generally been to help notation importers do the right thing for parts when all they get is a score file.

It could definitely be done with an attribute on the note element instead (as originally proposed) but I'm just thinking that the transpose element's diatonic flag already literally does this (I don't think I remembered that in 2015 or before, whenever I put the message on the old forum) so it might be better to keep all the transposition information in one place.

[mdgood]

I propose removing this from the 4.0 milestone so we can see how well implementing #278 works to resolve this issue in practice. If that turns out to be insufficient, applications could work around this with processing instructions for the time being, and we could come back and standardize a solution in a future MusicXML version.