MusicXML - export of transposing instrument parts - key signature
If in a score we have a part for a transposing instrument, then with Concert Pitch turned OFF we will see the player part form of the notation; with Concert Pitch turned ON, we will see the concert pitch (sounding pitch) form of the notation.
If we export the score as a MusicXML file, which form of the notation for this part will be encoded? This will affect both the pitch notation for the notes and the code that indicates the key signature.
We might imagine that MuseScore does one of these:
• Which form it is depends on whether Concert Pitch is OFF or ON at the time the MusicXML file is generated.
• It is always the same one of those, independent of whether Concert Pitch is OFF or ON at the time the MusicXML file is generated.
In fact, what happens seems to be this:
• As to the encoding of the note pitches, it is always the player's part pitch that is encoded. This does not depend on whether Concert Pitch is OFF or ON at the time the MusicXML file is generated.
• As to the key signature, the key signature that is encoded is the one seen with the setting of Concert Pitch at the time the MusicXML file is generated. This will sometimes match the pitch encoding for the notes and sometimes not.
This is half of one plan and the other half of the other.
The result may well be an anomalous reconstruction of the score by an application that receives the MusicXML file.
Best regards,
Doug
Comments
I think I may have gotten off the rails here by thinking in terms of exporting a MusicXML file for the player part version of the notation for a transposing instrument from the "main score" (by setting Concert Pitch OFF), rather than by working from a separated part for the instrument.
So, for the moment, "never mind", as I go "back to the drawing board".
Later.
Doug
In reply to I think I may have gotten… by Doug Kerr
Well, it seems like, whether we work from the main score or a separated part, if we want the MusicXML file to be properly encoded for the player part, we need to be careful to have Concert Pitch turned OFF (not surprising, really).
If we wanted to have the MusicXML encode an instrument at sounding pitch, we will probably need to make a separate part (at sounding pitch, with no transposition set) for the instrument of interest.
Doug
In reply to Well, it seems like, whether… by Doug Kerr
What software are you opening the exported xml in that is giving you a problem?
In reply to What software are you… by bobjp
MuseScore.
But I think there is really no problem.
Thanks.
Doug
In reply to MuseScore. But I think there… by Doug Kerr
Upon further reflection:
I think it is unhandsome that, if we have a score with a transposing instrument part, and export a MusicXML file when Concert Pitch is ON, the MusicXML part for the transposing instrument is anomalous. It contains the proper note pitch encoding for the transposed ("player part") form of the part, but the key signature for the "concert pitch" (sounding pitch) form of the part.
If, just for kicks, we import this MusicXML file into MuseScore, this part in the reconstructed score will be anomalous. If we regard the reconstructed score with Concert Pitch OFF, we will see the proper notation for the player part form of the part but with the incorrect key signature.
Of course, if we avoid ever having Concert Pitch ON when we export a MusicXML file for a score including a transposing instrument part, there will be no problem.
Doug
In reply to Upon further reflection: I… by Doug Kerr
Well, I get it.
Export a score with transposing instruments as an xml in concert pitch. Reopen that xml and the key signatures and pitches for the transposing instruments are a mess.
However, xml files from other sources seem to be OK.
In reply to Upon further reflection: I… by Doug Kerr
Hi Doug,
my two cents: the MusicXML exporter switches concert pitch mode off before export and restore it after export. This is based on a remark by Michael Good in the MakeMusic forum: "Now if you have a transposition, indicated by the transpose element, the pitch is the written pitch pre-transposition. The transpose element indicates the transition from written to sounding pitch." (source https://forums.makemusic.com/viewtopic.php?f=12&t=1689&p=3889&hilit=wri…). Also in the documentation: "If the part is being encoded for a transposing instrument in written vs. concert pitch, the transposition must be encoded in the transpose element using the transpose type." (source: http://usermanuals.musicxml.com/MusicXML/MusicXML.htm#EL-MusicXML-trans…)
Wrt the key signature, the MusicXML exporter depends on MuseScore to do the right thing when switching concert pitch off.
If you can pinpoint an error in either MusicXML import or export, please submit an issue including relevant data and an explanation of observed versus expected behaviour.
Please note that I am a professional software developer but an amateur musician, gaps in my music theory skills are to be expected.
Regards, Leon.
In reply to Hi Doug, my two cents: the… by Leon Vinken
Hi, Lean,
Yes, all that Good word and the cited passages from the Good book are all so.
Here is the problem:
If we have a part for a transposing instrument in a score, and with Concert Pitch ON, we export a MusicXML file, then:
• The notes are encoded in their transposed pitch ("player part pitch"), as suggested in the material you quote. And the element is properly included.
• But the key signature that is encoded is that which applies to the concert pitch notation, rather than the key signature that applies to the player pitch - "transposed" - notation.
These are inconsistent and will generally result in an anomalous result at the "receiving" program.
Fortunately, we can avoid this by always having Concert Pitch OFF when we export a MusicXML file.
I am a telephone engineer, and my music theory is very spotty (and I am only a feeble dilettante at software development). But I keep handy cheat sheets about intervals and named intervals and key signatures and such, so I handle just enough to be dangerous.
Thanks for your input on this matter.
Best regards and stay safe,
Doug
In reply to Hi, Lean, Yes, all that Good… by Doug Kerr
What is odd to me is that the problem only occurs upon MuseScore opening its own files. Files from other software work fine. As do files from MuseScore opened in other software.
Me? I'm just a musician/composer. I know how to turn my computer on. Most of the time.
In reply to What is odd to me is that… by bobjp
As to receiving programs working properly with MusicXML files generated by certain application other than MuseScore, I would say that this is because those other generating programs do not make the error that MuseScore does in the situation I described.
As to receiving programs other than MuseScore responding "properly" to a MusicXML file generated by MuseScore under the situation I described, I think I will do a little of that so I can better discuss that matter.
Doug
In reply to As to receiving programs… by Doug Kerr
FWIW, for me either concert pitch or not, the export from MuseScore always works properly when opened in Sibelius. That's the only other program I have that reads xml.
In reply to FWIW, for me either concert… by bobjp
My apologies for not having screen shots in this report.
The test score has two parts, "flute" (a non-transposing instrument) and "Bb clarinet" (a transposing instrument). When viewed with Concert Pitch ON, both parts show a key signature of C major, and both carry a C major scale.
When viewed with Concert Pitch OFF, the flute part shows a C major key signature and carries a C major scale. The Bb clarinet part shows a D major key signature and carries a D major scale.
These are both proper and consistent notation presentations for those instruments.
I set Concert Pitch ON and export a MusicXML file.
I import the MusicXML file into Finale (2012c.r13). The score reconstructed by Finale, as initially displayed, shows, for the flute part, a key signature of C minor, and that staff carries a C major scale. For the Bb clarinet part, the key signature is C major, and that staff carries a D major scale. This latter is of course not consistent for either a concert pitch or player part pitch presentation of that part.
I then import the same MusicXML file into Sibelius (7.1.2-77). The score reconstructed by Sibelius, as initially displayed (with Transposing Score OFF), shows, for the flute part, a key signature of C minor, and that staff carries a C major scale. For the Bb clarinet part, the key signature is Bb major, and that staff carries a C major scale.
If I turn Transposing Score ON, then, for the Bb clarinet part, the staff shows a key signature of C major , and the staff carries a D major scale.
Neither of those are consistent for either a concert pitch or player part pitch presentation of that part.
Doug
In reply to I think I may have gotten… by Doug Kerr
Some will interpret the cited passages from the MusicXML documentation as prescribing that a part for a transposing instrument should in any case be encoded at "player pitch" (transposed pitch). I read those passages more directly, as meaning that if a part for a transposing instrument is written at transposed pitch, then the encoding into MusicXML should be on the basis of the transposed pitch.
But applying the latter interpretation to MuseScore is complicated by the fact that MuseScore (by way of the Concert Pitch button) allows us to "see" the part for a transposing instrument either at concert pitch (sounding pitch) or player part pitch (transposed pitch). So how should MuseScore behave? We might imagine the adoption of one of two policies:
a. Whether we have set MuseScore to view a part for a transposing instrument at concert pitch or transposed pitch, it should be encoded into MusicXML on a transposed pitch basis.
b. If we have MuseScore set to show the part for a transposing instrument at concert pitch, it is then in effect "written" at concert pitch, and should be encoded into MusicXML on a concert pitch basis.
But MuseScore does not completely follow either of those policies. As to the pitch encoding of the notes, it follows policy a, always encoding them at transposed pitch regardless of the setting, at the time of export, of Concert Pitch. But as to the key signature on the part's staff, it follows policy b, encoding the key signature as seen with the setting of Concert Pitch in effect at the time of export.
The result is, for export with Concert Pitch set ON, the MusicXML encoding is inconsistent between the encoded pitch of the notes and the encoded key signature.
Doug
In reply to Some will interpret the… by Doug Kerr
So, what would I suggest the MuseScore developers do in this area? I suggest they adopt and implement one of two policies; I make no recommendation as to one or the other. In each case, the situation is the generation of a MusicXML file from a score that includes one or more parts for transposing instruments, and the discussion is of such a part.
Policy X
X.1 If Concert Pitch is OFF at the time the MusicXML file is generated:
X.1.1 The notes are encoded at the pitch (and with the spelling) seen on the screen. (This is the "transposed", or "player part", pitch.)
X.1.2 The key signature is encoded as the signature we see on the screen.
X.1.3 A transpose element is included in the MusicXML code.
X.2 If Concert Pitch is ON at the time the MusicXML file is generated:
X.2.1 The notes are encoded at the pitch (and with the spelling) seen on the screen. (This is the "concert pitch" notation.)
X.2.2 The key signature is encoded as the signature we see on the screen.
X.2.3 No transpose element is included in the MusicXML code.
Policy Y
Y.1 If Concert Pitch is OFF at the time the MusicXML file is generated:
Y.1.1 The notes are encoded at the pitch (and with the spelling) seen on the screen. (This is the "transposed" pitch.)
Y.1.2 The key signature is encoded as the signature we see on the screen.
Y.1.3 A transpose element is included in the MusicXML code.
Y.2 If Concert Pitch is ON at the time the MusicXML file is generated:
Y.2.1 The notes are encoded at the pitch (and with the spelling) that would have been seen on the screen with Concert Pitch OFF. (This is the "transposed" notation.)
Y.2.2 The key signature is encoded as the signature that would have been seen on the screen with Concert Pitch OFF.
Y.2.3 A transpose element is included in the MusicXML code.
Essentially, policy Y is as if, when the export of a MusicXML file is commenced, MuseScore behaves as if Concert Pitch is OFF regardless of whether at the time it is actually set ON or OFF. (I think this was the description given of MuseScore's behavior in an earlier post by Leon Vinken. But that was not wholly accurate, as noted just below.)
I note that, at present, the policy followed is policy Y, except with respect to item Y.2.2.
Doug
In reply to So, what would I suggest the… by Doug Kerr
OK. So if we export mxl with concert pitch on, probably nothing, including MuseScore, reads the file properly. Maybe this needs to be fixed.
Or we can export with the button off, which I think is more correct, and other software reads it properly
In reply to OK. So if we export mxl with… by bobjp
Sure, all that.
Doug
In reply to So, what would I suggest the… by Doug Kerr
Just to complete the roster of the usual suspects, note that it is not really profitable to observe how Overture responds to the test MusicXML file mentioned above, since Overture takes a wholly different outlook on transposing instruments, not compatible with any of the Good words or Good book words, and thus to which the concepts of policy X and policy Y cannot even be applied.
But that is what a different one of my many lives deals with.
Doug