MusicXML- Export Non-Standard Dynamics as Text
1. Open attached file, which contains musescore dynamics which aren't defined in musicxml (file created in 2.1)
2. Export to musicxml
3. Import into Finale or other notation engine
In a previous issue (https://musescore.org/en/node/177216), these non-standard dynamics were changed to correctly export in an other-dynamics node. The correct behavior should generally be to export these dynamics as words, rather than other-dynamics, because MuseScore considers text relating to dynamics, such as "m" "r" "s" "z" and "n" as dynamics, but MusicXML considers those to be staff-level text. MuseScore is less strict about what is defined as a dynamic, so it is safer to assume that what a user inputs as dynamics in MuseScore should be exported as staff-level text, rather than assuming everything the user enters is a dynamic instruction not in the MusicXML specification
Tested on 2.1 3543170
| Attachment | Size |
|---|---|
| Other Dynamics Test.mscz | 3.94 KB |
Comments
MuseScore considers text relating to dynamics, such as "m" "r" "s" "z" and "n" as dynamics, but MusicXML considers those to be staff-level text.
I don't understand this sentence. What is "other-dynamics" for in the MusicXML spec then?
An appropriate use of other-dynamics as I understand it would be to create, for example, a "fpp" (forte pianissimo) dynamic instead of a "fp". What the MusicXML spec is going for is that the dynamics element should be used for notations that directly alter the note's velocity.
The spec even points this out (common.dtd):
While things such as "niente" might modify the note's dynamic in theory by telling the notation software to go to a velocity of 0, in practice, that is usually accomplished with the accompanying decrescendo wedge. None of the other big notation editors (Finale, Sibelius, NoteFlight) use dynamics in this way; rather, the user generally uses expressive staff markings (below the staff text) to accomplish this. As such, exporting these markings as other-dynamics would harm, rather than aid, sharing the composer's intent with the notation software.
Also, MuseScore makes it easy for users to change a normal staff text element (for example, "cresc.") into a dynamic marking. Which, while it does have to do with dynamics, goes against the intent of the MusicXML specification.
Finale, for example, doesn't even import dynamics marked as "other-dynamics".
My perhaps naive take on this is that MuseScore shouldn't be in the business of interpreting things like "many of those should perhaps be". Many? Perhaps? To me, that's something the user should decide. If you create a marking using MuseScore's built-in "Dynamics" type, it should export as dynamics, period. If you want it exported as plain text, then it should be created as such - just as I believe you are saying a typical Finale user would do. Give it the Dynamics text style if you like. But I don't think we should be second-guessing which markings the user explicitly created as Dynamics should "perhaps" not be exported as such. How would we know? Have a second list of "approved" markings? Would it include German and English terms that can also be used?
Bottom line - to me, the current behavior is the right thing to do. If the user creates a marking as a dynamic rather than text, we should take him at his word.
If you feel this this understanding is off, could you elaborate?
In the OP:
I can't vouch for the accuracy of this, but that's the claim.
I'm basing my comment on the quote from the actual spec in #1. Which is to say, it seems to directly contradict the claim that anything not explicitly listed as one of the MusicXML-approved dynamic types must be represented as staff-level text. To me, "many of those should perhaps be" is an instruction to the *user* to create those markings as staff text, not an instruction to the *software* to be in the business of making these sorts of subjective determinations.