[MusicXML Import] Losing Tempotext when saving as mscz/mscx
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
When I import the attached file into the latest version of MS everything is fine with the tempo text. After saving the file into MS-file it still is fine, as long as it stays open. But after closing the file and reopening it, the tempo texts are gone and the file is played with its default 120 bpm.
| Attachment | Size |
|---|---|
| Tempoproblem.xml | 881.95 KB |
Fix version
3.0.2
Comments
Confirmed with the latest build from master. See also https://musescore.org/de/node/163721
@enaef's findings:
In the object debugger those vanishing tempo markings are shown to be attached to track 4, i.e. the 1st voice in 2nd staff. In the status bar it is reported to belong to staff 2.
Newly added (and non-vanishing) tempo markings though are shown to be attached to tack 0, i.e. 1st voice in 1st staff.
Strange enough that XML files seems to have been created/exported from MuseScore 2.0.3.
And there are other strangenesses with it: in the instruments dialog moving instruments up/down doesn't work
May be, the reason lies in the history of the file. Some more information here:
Originally the file was created with SmartScore X2 Pro by scanning a score on papier, then recognising it, then revising it manually.
As there was no accolade with all the necessary choir-voices in ONE accolade, system(s) had to be added. I also had to add clef and key signs to one or two systems, for example S2 I think.
After a first manual revision the file vent via xml into Finale 2012c for further revision. Goal: to have each voice in its own system in order to emphasize it for learning issues. And finlally rendering it into wav/mp3 in Finale with Garritan Instruments (Aria Player).
Tempo marks have been added in Finale 2012.
Unexpectatly I finally also had to transpose into d-minor. This did not work proparly in Finale nor did it in SmartScore. MuseScore however did the job. The only problem were the lost tempotexts after saving the file in the MS-format. I needed the MS-format also for exchange with other choir members.
If someone wants to do some detective work (I'm not able since I do not understand it): I have attached two xml-exports: one from SmartScore, the other one from Finale (after importing the SmartScore export and adding a tempo mark of 180 bpm at the beginning).
The SmartScore export doesn't have these tempo text, the Finale export does though, and already shows them to be attached to the 2nd staff, and These vanish when saving as mscz and reopening the file.
So it seems Finale (actually the "Dolet light for Finale2012") is to blamed for this problem.
However: a) the XML-Import in MuseScore might well fix this ("be generous in what you accept") and b) the XML-Export in MuseScore should not have exported that apparently wrong setting in the first place ("be strict in what you generate"). If we fix the Import problem though (by automagically re-attaching tempo texts to top staff), we won't have the export problem anymore ;-)
The tempo text has only be added in Finale, therefore the SmartScore Export can't have it.
However, this is not a genuine problem of Finale.
Attached another example (another score), which went the same way like the problematic file:
SmartScore --> Finale (with added tempo texts and other changes) --> xml.
In this case, the tempo text is not lost in MuseScore after saving it in MS-filetype.
One main difference between the problematic and the unproblematic file is, that I did not need to add system(s) in SmartScore in the unproblematic file.
As I mentioned above, the transposition into another key in Finale failed with the problematic file. A transposition with the attached unproblematic file works with Finale. May be all this is connected and starts nonetheless in SmartScore ... But who am I to judge that, as I have no business in Software Development.
However, I certainly do not expect MuseScore to fix a problem which is firstly caused by other software ...
Insofar the issue is solved for me after recognizing that the problem is not in MuseScore.
Relates to #272381: [EPIC] Tempotext issues
Fix typo in issue title.
Investigation shows:
- the MuseScore GUI forces tempo text to be in the first part at track 0
- the MuseScore MusicXML importer does not know about this and ignores it
- the failing Finale export has tempo text in the second part
- the unproblematic Finale export has tempo text in the first part
Thus I think the solution would be to have the MusicXML importer put all tempo text in the first part at track 0
This is not a difficult change.
Solution known, PR still to be created.
https://github.com/musescore/MuseScore/pull/4488
Fixed in branch master, commit ff8da2124e
fix #163726 - [MusicXML Import] Losing Tempotext when saving as mscz/mscx
Automatically closed -- issue fixed for 2 weeks with no activity.
relates to #270643: [EPIC] MusicXML import/export issues