MusicXML Export: Percussion notes have wrong values (unverified)
Hello,
I have a simple score of two staffs. Oud staff and Tablas staff. I m using C# to read and parse the musicXml file produced by musescore. I noticed that the Xml nodes of precussion are not correct. I m using simple low conga(midi key number 64) and mute high conga (midi number 62). they correspond to E4 and D4 respectively. The problem is, when i export the score to Music Xml file. The corresponding display steps don't match with the real notes.:
this one is correct:
<unpitched> <display-step>D</display-step> <display-octave>4</display-octave> </unpitched> but this one is not: <unpitched> <display-step>F</display-step> <display-octave>4</display-octave> </unpitched>
F4 corresponds to high timbale not low conga.
I also noticed that the instruments names and Midi devices are correct in the part list:
<score-part id="P2"> <part-name>Tablas</part-name> <part-abbreviation>Tbs.</part-abbreviation> <score-instrument id="P2-I63"> <instrument-name>Mute High Conga</instrument-name> </score-instrument> <score-instrument id="P2-I65"> <instrument-name>Low Conga</instrument-name> </score-instrument> <midi-device port="1"></midi-device> <midi-instrument id="P2-I63"> <midi-channel>10</midi-channel> <midi-program>1</midi-program> <midi-unpitched>63</midi-unpitched> <volume>78.7402</volume> <pan>0</pan> </midi-instrument> <midi-instrument id="P2-I65"> <midi-channel>10</midi-channel> <midi-program>1</midi-program> <midi-unpitched>65</midi-unpitched> <volume>78.7402</volume> <pan>0</pan> </midi-instrument>
it states correctly and midi-unpitched values of 63 and 65..
So the problem is, if a developer like me wants to use the display-steps to generate the midi messages, it will mislead him and create wrong messages.
any idea why is this happening?
Update: Btw , the unpitched notes carry wrong info.. when it is F4, the instrument ID shows P2-I63 which is wrong and doesn't confirm with Midi standard. When it is D4, the instrument id shows P2-I65. It seems like the values are switched.
| Attachment | Size |
|---|---|
| Entizarak_with_precussion.mscz | 19.8 KB |
| Entizarak_with_precussion.musicxml | 73.25 KB |
Comments
Relates to #270643: [EPIC] MusicXML import/export issues
Why MuseScore 3.4.2? Is the same issue still happening with 3.6.2?
BTW: you can enclose xml code here using <xml>...</xml>
In reply to Why MuseScore 3.4? Is the… by Jojo-Schmitz
Thank you. I edited the post to show xml code correctly.
In reply to Why MuseScore 3.4? Is the… by Jojo-Schmitz
I will check with 3.6.2 and see if the same problem exist.
In reply to Why MuseScore 3.4? Is the… by Jojo-Schmitz
Hello Schmitz,
I updated to 3.6.2
compared the generated files from both versions. The issue still the same.
I feel the pattern of the error is like the instruments values are switched and the corresponding key numbers are incorrect.
fore example: The first couple of percussions notes in the xml file generated by v3.6.2 :
I manually modified the xml file to be like this:
I did this for all notes.. making E4 instead of F4. and switching D4 with E4 for each note..
The file then worked as expected.
3.4 is still the earliest this has been reported for so far, so let's leave it at that. Confirmation that it still is an issue in 3.6.2 is enough ;-)
In reply to 3.4 is still the earlies… by Jojo-Schmitz
Yes, thank you
@engrabuomar20, based on my understanding of MusicXML, I believe the display step and octave do not have to match with the MIDI note number and that you should use the midi-unpitched value found in the midi-instrument associated with the note instead.
See this example: https://www.w3.org/2021/06/musicxml40/musicxml-reference/examples/tutor…, which contains two different instruments using the same display-step and octave for two different instruments in the first measure of the first part.
Whether MuseScore's MusicXML export is correct for your attached MuseScore files is still to be checked.
Having reread the relevant specs, I am still convinced there is no relation between the display step and octave in MusicXML and the general MIDI note number. This also implies that IMHO MuseScore is correct and the issue should be rejected.
In reply to @engrabuomar20, based on my… by Leon Vinken
@Leon Vinken Thank you for replying. I modified my code and used the midi-unpitched value associated with the note and it actually worked fine.
I understand now that the display-step is only used for purposes of displaying the note only. right?
The problem is that it will be misleading if a developer used those display steps as if they are the corresponding notes used in standard MIDI for percussion channel i.e. In the examples i attached previously, the Low conga ( key = 64, E4,Low Conga as per standard MIDI) and Mute High Conga (key=62,D4,Mute Hi Conga as per standard MIDI) are not exported as E4, and D4. They are exported as display-steps F4 and E4. Which makes it somewhat misleading. I totally understand now that the exported steps are only indicating the display of the note and have nothing to do with its playback.
Greetings. I've also noticed incorrect
<midi-unpitched>values. The musicxml spec uses 1-indexed MIDI numbers (in agreement with users, not with developers or low-level file writers used to 0-indexing).Per this MuseScore document, for instance, Cabasa is note 69 (1-indexed).
https://musescore.org/sites/musescore.org/files/General%20MIDI%20Standa…
Open a fresh MuseScore document, load a Cabasa instrument, export to musicxml, and get
<midi-unpitched>70</midi-unpitched>instead of 69. This has the potential to import in other programs as Maracas, which is 70.I believe this means the original bug report is correct, and this statement (about the original file involving keys 62 and 64) is incorrect: "it states correctly and midi-unpitched values of 63 and 65.."
Cheers and thanks for MuseScore
Opened a draft PR, waiting to see if tests need updating.
https://github.com/musescore/MuseScore/pull/9732
MIDI numbers seem to cause endless confusion, as the various tables and specs fail to clearly mention if they use zero or one based numbers. Convention seems to be that note numbers are shown zero-based but program numbers are shown one-based.
MusicXML is clear: midi-program and midi-unpitched are one-based (https://www.w3.org/2021/06/musicxml40/musicxml-reference/data-types/mid…).
In https://musescore.org/sites/musescore.org/files/General%20MIDI%20Standa… the numbers used are note numbers and I interpret these as implicitly zero-based. Thus for Casaba zero based note number 69 equals one based midi-unpitched 70 is correct and no change should be made to MuseScore's MusicXML export.
Also, in https://musescore.org/sites/musescore.org/files/General%20MIDI%20Standa… e.g. Cowbell is MIDI KEY number ("NOTE#") 56, which results in https://www.w3.org/2021/06/musicxml40/tutorial/percussion/ in midi-unpitched 57.
Thank you, those links helped me verify that I was wrong. I'll close the PR and revert my edits to the issue title, since it is possible there is still an off-by-one issue with display pitch, based on last updates in thread.
After looking at MuseScore's display-step export, I think this can be closed. Leon is correct that display-step can be manipulated freely without any correspondence to the midi-unpitched values. Moreover, since display-steps do not encode accidentals, there is no way to map to black keys such as 61.
Regarding: "Update: Btw , the unpitched notes carry wrong info.. when it is F4, the instrument ID shows P2-I63 which is wrong and doesn't confirm with Midi standard. When it is D4, the instrument id shows P2-I65. It seems like the values are switched."
Reply: The display-step is correct for the display shown in your file, which uses a 1-line staff centered on E4. Switch to a 5-line staff and the display-steps will switch to G5 and E5 as expected. The instrument ID can be whatever MuseScore wants, but here it also behaves as you would expect, high conga midi (63) is "below" low conga midi (65) but above on the staff (F4 over D4).