Empty custom signature converted to standard C major in MusicXML export

• Feb 9, 2015 - 19:22
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

Right now, an "empty" custom key signature gets converts to an ordinary C major key signature on export. I would like to have it exported instead as whatever MusicXML expects for an "open" or "atonal" key signature - the distinction being that it does not transpose.

I am happy to implement this myself; it seems easy enough if only I knew exactly what it should look like. I found this:

http://forums.makemusic.com/viewtopic.php?f=12&t=2235

But I don't see any particular evidence of followup - nothing in the MusicXML spec appears to be directly relevant. Perhaps it is supposed to be an empty "key" element - eg, no "fifths" element?

BTW, I would of course also volunteer to implement the corresponding import support.

Comments

• Feb 12, 2015 - 05:53

Hmm, I don't know. This appears to specify a very clear key signature of 4 sharps (5 for the horn part), but the horn key signature is marked to not display (as is traditional for horns). So that's just an ordinary E major concert key signature in which it happens to be invisible in the horn part - not at all the same thing as what I am asking about. Unless I'm misunderstanding something, but I don't think so.

To be clear: I am talking about a truly "atonal" key signature, one that displays no flats or sharps for any instrument regardless of transposition.

Reply

• Feb 12, 2015 - 15:33

Ah, much better, thanks! "mode none" is the relevant line, then. Should be a piece of cake. I'll make the change. Leon, I understand you're in the middle of something, but I can redo my change in your new code if necessary.

Reply

• Feb 12, 2015 - 18:16

Marc, feel free to go right ahead !

As my new code lives in separate source files, which are not public at this time, there is currently little you can do to help me. Adding a test case would help a lot, as the biggest risk is that your code changes could be in a part of the importer that is already copied to the new code and I might forget to add your changes.

Small changes won't be much of a problem. Large changes would mean that either you implement them later in my redesigned code or that I reverse engineer your changes to the old code and apply them myself.

Reply

• Feb 12, 2015 - 21:27

Thanks. Now that I know what needs to be done, it's a two-line change to exportxml.cpp and importxml.cpp, already done :-). I'll add a test and submit PR.

Reply