GSoC 2020 Week 10 Recap: MusicXML in Difficult Circumstances
What a week.
What a week.
Update from last week
One sweltering day in August, a well-loved MacBook went to sleep and never woke up. During the very week when I was over 300 miles away from my (non-Mac) secondary machine.
I am amazed at how much I was able to accomplish under the circumstances. I commandeered someone else's gaming laptop, set up a guest account, and immediately began downloading at least a dozen gigabytes of stuff (Visual Studio, Qt, cloning the repo, Sibelius trial, Finale trial, etc.), none of which will ever be used again after those few days when I needed to borrow it. After that, I focused on completing the mission for the week—getting MeasureRepeats into and out of MusicXML files.
Some notes on MusicXML handling of measure repeats in Sibelius (Ultimate 2020.6), Finale (26.3.1.520), and MuseScore (PR #6365):
- Sibelius is just bad. It doesn't include the
"number"
attribute in the<measure-style>
tag surrounding the<measure-repeat>
tag (for when a part/instrument has more than one staff and the measure repeat is not the same in all staves); it doesn't write the"slashes"
attribute; it can't even import its own exports. - Finale is better, unsurprisingly; I think MusicXML started there. Finale writes the
"slashes"
attribute as well as the staff"number"
, although it does not repeat the underlying content as the spec demands. Its export is definitely better than its import. The software actually only supports one- and two-measure repeats, and thus converts a four-measure repeat into two consecutive two-measure repeats on import (not good). Strangely, it also gets confused when importing its own exports, getting the end measure wrong. - MuseScore up to now has had no support for importing or exporting (and, of course, only one-measure repeats were supported in the software). I have implemented export for one-measure repeats as well as the new subtypes, including the
"slashes"
attribute (although I have yet to see a legitimate case where it is meaningful), the"number"
attribute in the<measure-style>
tag, and repeating all the content. This export is read perfectly by Finale, and, as designed, the repitition of the content gives Sibelius something that it can understand as an alternative. The import I have implemented ignores the"slashes"
attribute if present, as there is for our purposes an identity between the slashes in the symbol and the number of measures it indicates. But it reads both Sibelius and Finale export correctly (or, in the case of Sibelius export, it reads it at least as well as Finale does).
Looking forward to this week
I'm typing this on the third computer I've used in a week, my backup Windows laptop. Today I replicated the process I went through on the borrowed computer of setting up the Visual Studio build environment. At this point I have to confront some of the other massive problems I'm presented with, being suddenly forced into an OS that can't run any of the software I've used for years. Just finding replacements will take me a couple of days, I'm afraid. But I hope to still remain on track with my remaining tasks:
- Week 11 (August 10–16)
- Implement ID-ing sequences of measure repeats
- Add style options for automatically numbering them
- Week 12 (August 17-23)
- Create tests
- Rebase as needed to resolve conflicts with other GSoC projects
- Week 13 (August 24–31)
- Final evaluation of mentor due
- Complete work product
Previous post | Next post |
Comments
Lots of hurdles there. Go, Isaac!