[Musicxml im-export] - New Transposition and pitches messed up
Reported version
3.2
Type
Functional
Frequency
Many
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
Hello,
When importing the attached file with instrument change from in D to in F, Musescore can have correct playback. But when exporting into Musicxml again, the transposition of the changed instrument is completely wrong, and the pitches are all messed up, some an octave higher or lower, sounding very terrible.
Regards
Haipeng
| Attachment | Size |
|---|---|
| changes.xml | 20.37 KB |
Fix version
3.6.0
Comments
To describe this more exactly, I'm attaching three files here. The exported Musicxml treates all as Clarinet in Bb, and at the first two bars transpose all C's an octave lower. Different change will shift different pitches down or up, very strange!
File changes.xml contains two transpose elements, diatonic -6 chromatic -10 in measure 1 and diatonic -4 chromatic -7 in measure 4. After saving to MusicXML by MuseScore, only one transpose is left: diatonic -4 chromatic -7 in measure 1.
Without further investigation I do not yet know what causes this, but my first guess would be that the MusicXML importer fails to associate the second transpose with the second instrument. In MusicXML transpose is a staff property, in MusicScore it is an instrument property.
Not only the import, as I can't see and do scores in Musescore, you can try to write some instrument changes with lots of major scales using Musescore alone, and do xml export. You will find:
1. the transpose of all changes will lost. Only the initial one is left;
2. There will be notes in wrong octave after the export.
Haipeng
Indeed on import only the first instrument's transposition is imported, on export only the first instrument's transposition is exported. Handling transposition for multiple instruments per staff has simply never been implemented.
For basically the same reasons as for #294814: [Musicxml im-export] - New Instrument name disappears, this issue is also definitely not trivial to solve. I do consider it more important that 294814, as it leads to very annoying information loss.
The most frustrating problem is not the transposition, but the pitches, some shifted an octave lower. Perhaps I must have someone enter an example in Musescore and open a new issue about that pitches for the export side.
Haipeng
Dear Leon,
Finally I got help from Mike320, and come up with a correct example showing the real problem I want to solve. The instrument names and abbreviations are correct, but besides the not exported second transposition, the most frustrating problem is the pitches of bar 4, where the note B is an octave higher when exported. There are too many such things, e.g., a F horn to Eb horn, when all C's are exported an octave lower. It's very strange why Musescore has such a mad behavior.
Haipeng
transposition
Notice I did these in the 3.3-RC to assure all merged PRs were included.
I don't understand anything about how MusicXML represents transposition, but I can say something about how these octave errors happen. For transpositing instrument, we usually store only a single representation of the pitch (a MIDI value that incorporates octave info), but two different values for the "TPC" (a numeric value indication used to differentiate, for example, D# from Eb). So for clarinet, say, we might store middle C as pitch 60, and the two TPC's as being the value for C and Bb if the 64 is meant to represent written pitch, or D and C and if the 60 was meant to indicate concert pitch. We calculate actual note to display from those pieces of data and checking whether we are in concert pitch mode or not.
Then If somehow the wrong MIDI pitch or TPC's get recorded in the file, or they are created incorrectly based on incorrect interpretation of the info on import, then the algorithm that tries to calculate the note from the info I mentioned (one MIDI pitch and two TPC's) will often produce an incorrect octave. We've fixed a nuber of bugs with that type of symptom over the eyars having nothing to do with MusicXML.
So I'm guessing that's what is going on here. Somehow, we either write the MusicXML info wrong or read it wrong, such that by the time we try to construct the note from what we believe to be the MIDI pitch and the two TPC's, one or more of those values is off, and we get the wrong answer. But I don't understand enough about how the info is supposed to be represented in MusicXML in order to say more.
I note that the same thing happens in 2.3.2, BTW. I implemented much of the code having to do with transposition of instrument changes back around 2.1, and I have no trouble believe I didn't handle MusicXML correctly. But I don't know if the problem is on the export or import side.
There are indeed (at least) two different issues here
- only the first transpose is imported/exported from/to MusicXML (working on that)
- sometimes something in the pitch calculations breaks
The first issue I know how to solve, the second one I still need to investigate.
Mike, Haipeng, thanks for the example. Do you know where the issue originates (import or export, i.e. is the MusicMXL file produced by MuseScore correct) ? Could you produce the same example using one of our competitors ?
Additional remark: the second issue may be a side effect of the first issue (as the transposition for the second instrument is incorrect, pitch calculations may fail). Do you also see the pitch issue for a file with a single instrument ?
Dear Leon,
The problem only appears when there's an instrument change with different transposition setting. A staff with only one transposed instrument will never have pitch issue. The last example was an original Musescore engraving and I produced the xml file using the latest nightly build. Using other softwares like Finale and Sibelius to do such changes will never have such a strange issue, and the second and other consequent transposition settings will all be included.
Haipeng
Manually fixed file clarinet scales (using an editor), it now imports correctly into Finale Notepad (the only competition I have available). Two changes were required: adding a transpose element for the second instrument and fixing a note that was exported one octave off. Thus it seems we are on the right track towards fixing this issue, it looks like multiple issues will have to be fixed. Does this file works as expected for you ?
Yes, this is what the correct output should be. Thank you!
Haipeng
Any solution or plan here? I suddenly run into trouble in this issue, when comparing my braille transcription of a Wagner score done by a Musescore user with a newly engraved Sibelius score full of errors. This is part of our engraving trial of DAISY Music Braille Project. I found there are lots of wrong pitch shifts in the musicxml exported from Musescore where horns change from this key to that key, and this stops me from making correct comparison. I also have to put a warning message on the page of my published braille score before I correct all these wrong shifts. So there will be a nightmare when meeting instrument changes with different transpositions.
Haipeng
Relates to #270643: [EPIC] MusicXML import/export issues
It seems this one managed to escape my attention for too long and it looks like a showstopper for the next release to me :-(.
Issue investigated, found exporting an instrument change with a changed transposition simply has never been implemented. Solution is not very difficult. Will be providing a pull request shortly, hoping this still makes it into 3.4.
Thanks!
Partial solution: pull request https://github.com/musescore/MuseScore/pull/5589 solves the export part ( import still to do, but that is more complicated and I assume export is more important as it enable MuseScore to MusicXML conversion).
Export fix merged in 7efbe85
Pull request https://github.com/musescore/MuseScore/pull/6834 fixes the import part.
Fixed in branch 3.x, commit dbe3d3bb9b
fix #294815: [Musicxml im-export] - New Transposition and pitches messed up
Automatically closed -- issue fixed for 2 weeks with no activity.