differences between MusicXML exported from Windows / Mac

[Hans Vereyken]

I was working with some percussion parts when I stumbled on a problem with a MusicXML file exported from Finale 2014 on Mac. Pitches (unpitched) are wrong...
I restarted from Linux to my Windows to investigate the problem (I have the .musx file). I didn't find any reason for these pitches to be wrong, but nevertheless I tried exporting on Windows (Finale 2014) and yes ... Windows exports correct pitches (unpitched).

I further investigated the differences between all these files and found out there are more problems, using native/Dolet does matter (although the native is labeled as dolet-light).

Most important differences between Windows and Mac (Native and Dolet!): unpitched notes, instrument and midi-instrument information, measure width.

Most important differences between Native and Dolet: Tempo! Native gives me 20, Dolet 140...

Dolet export on Windows, Finale 2014 seems to be the best choice to get a decent file. But why is it that Mac, Finale 2014, both Dolet and Native can make such mistakes, I would expect the same codebase (and thus the same features/problems)? Also, why is the native export giving me another tempo?

All files included

[Hans Vereyken]

Since we want to support as much as possible we are searching for a solution to the wrong step and octave from Mac exported MusicXML files in percussion parts. We do have some MusicXML files without the corresponding mus(x) files with the same problem. Unfortunately I couldn't find a way to deal with it. Does this bug happen in a consistent way and (if yes) can you explain me how to handle it to get the correct pitches?

If it is possible I will add the fix to our MusicXML Sanitizer.

Thanks in advance!

[Michael Good]

Hello Hans,

Thank you for the report. I apologize for the delay in getting back to you on this. I see the percussion unpitched issue and am still trying to figure out what is going on here. The missing instrument and mid-instrument information is likely related to the incorrect unpitched notes. The minor differences in positioning between Windows and Mac for measure width etc. are due to difference between platforms in how that information is reported to the MusicXML export and is a separate issue.

The difference in tempo is because the full Dolet for Finale plug-in exports the data from Finale tempo records, while the built-in MusicXML export does not. There is a tempo record that is overriding the default tempo from the playback settings. I am not sure why we kept that difference in when we brought over 99% of the Dolet-specific features into the built-in MusicXML functionality.

[Mogens Lundholm]

Thanks for the fine example files.

Well - I thought that <unpitched> was merely a question of displaying "not real notes". But now I see that the notes are to be played, because there is a midi-definition. The next thing I notice is that the midi channel specified is 6 - while the Midi Specification says that percussion shall be in channel 10.

The instruments in the midi-section are named "Ride Cymbol", "Cabasa" and "Maracas" numbered 52, 70, 71. They correspond to the "General Midi Percussion Map" numbered 51, 69, 70. So that one must be subtracted from the numbers in Music Xml to get the Midi number.

What bothers me also is the use of an instrument lookuptable for every single note (in "PERCUSSION - Win - Native.xml"). This could be a performance problem.

My interest is plaing the Music Xml-file. I could identify "<clef><sign>percussion</sign>" and change the channel from
6 to 10, and I can subtract one from the Percussion Midi Map number. But is it right?

Kind regards
Mogens

[Hans Vereyken]

I think you are correct, I didn't look into that yet.
The 'unpitched' element is a question of displaying "not real notes", but the information is critical when displaying scores. The documentation:

The display-step-octave group contains the sequence of elements used by both the rest and unpitched elements. This group is used to place rests and unpitched elements on the staff without implying that these elements have pitch. Positioning follows the current clef. If percussion clef is used, the display-step and display-octave elements are interpreted as if in treble clef, with a G in octave 4 on line 2. If not present, the note is placed on the middle line of the staff, generally used for a one-line staff.

So with the display-step and display-octave I can calculate the staffline of the unpitched note.

FYI: A nice representation of the differences between the files: https://www.diffchecker.com/70g4fx1l (this link will last for a month)

[Michael Good]

As I mentioned earlier, I have verified the problem that the Mac MusicXML export is incorrect on this file while the Windows MusicXML export is correct. It appears that on Mac the percussion map instrument definitions are not being picked up properly, which likely leads to the problem with the incorrect unpitched values.

Percussion notation is complex so it may take a while to understand and fix what is going on here. I don't recall seeing this problem reported before and we have had lots of people using percussion notation exported from Finale.

[Mogens Lundholm]

I think that Windows Music Xml should specify midi channel 10 for percussion.
Mogens

[Mogens Lundholm]

Dear Hans

Could you tell me if this sounds OK?
It is played with my Midi and Music Xml player (WIN NATIVE - tempo changed to 120, channel 10).

Kind regards
Mogens

PS: File at: http://programfabriken.com/PERCUSSION.WMA

[Michael Good]

Hello Hans and Mogens,

Mogens, the MIDI channel assignments in the MusicXML export come straight from the Finale file, which is as it should be.

Hans, I was able to look into this some more. There is a difference between Mac and Windows due to differences in the way the MusicXML export is handling Finale's MIDI Device Annotations across platforms. These files are external to the Finale score file, so that makes a bit more sense as to why the exports are different across platforms.

I see this file was originally created in Finale 2003 on Windows and last saved in Finale 2014c on Windows. This gives to mind a couple of best practices for MusicXML export:

• For best results, export to MusicXML on the platform where the file was created. This is especially important for pre-Finale 2012 files that use non-Roman scripts. Finale did not support Unicode prior to Finale 2012, and reading in files cross-platform could cause problems with Eastern European and other Windows or Mac scripts.
• In general results will be better with files created with newer versions of Finale. Files created with older versions have to go through more conversion steps when read in with the latest version of Finale, and are also prone to use older music entry techniques that are more difficult to export to MusicXML.

I'm not saying that these are directly related to this issue. Percussion export is complicated and I still have not found the real root cause of the problem, just one factor in why things are working differently between Mac and Windows.

[Hans Vereyken]

@mogens: I think it sounds correct, except from the thrill and accents. Also the Timpani is missing, but I guess that's because it isn't in the MusicXML nor the .musx file (just a direction). For the time being I am focussing on displaying the notes, not playing them. I'll get back to you if I find out something is wrong with this playback.

@michael: The only thing we got is a .musx file. Suggesting it wasn't made in Finale 2003. We'll contact the engraver about this (maybe he is using a template from Finale 2003?).
I understand your second point, however, we receive files from many different sources, many different Finale versions from Mac and Windows. It's impossible to have all these versions installed and ready to (bulk)export MusicXML files. Another problem is the necessary licenses, where can I get one for Finale 2003? Will it work on a modern Windows / Mac computer, or should we buy old versions there as well?
As a programmer I do understand why this would 'best-practice', but I don't think we will be able to follow them entirely.

I'm happy you are looking into this problem and share your findings with us.

Thanks Michael!