Odd handling of beams in certain MusicXML files
This problem arises when a MusicXML file is exported by Encore from a file having two or more voices active in a measure in which there are beams.
When the file is imported into MuseScore, at first the beams are not present. But applying Format>Reset Beam puts them in place.
A similar oddity does not take place with a MusicXML score from essentially the same score generated by Overture or MuseScore itself.
Testing suggest that the difference in behavior comes about because of a difference as to the sequence in which the notes of the two voices in a measure are encoded. In Encore, the encoding ziz-zags between the notes in the two voices, short <backup> elements being used frequently. In Overture and MuseScore, all the notes in the measure in one voice are encoded, following which there is a big <backup> element, and then all the notes in the measure in the other voice are encoded. I'm sure both schemes are "legitimate".
The attached MusicXML file, generated in Encore, should exhibit this oddity when imported into MuseScore.
This odd behavior is certainly not debilitating, as it is so easily corrected. But it is disconcerting.
Best regards,
Doug
Attachment | Size |
---|---|
Beams and voices 1004M.xml | 9.63 KB |
Comments
I recently imported an Encore generated MusicXML file. And indeed, it was a two-voice score.
UPDATE: I've deleted a section of my original post where I mentioned that, on MusicXML import, notes were swapped between V1 and V2. But that appears to have been entirely in error. Sorry for any confusion!!
I immediately noticed that the resulting Musescore document contained a sea of flagged eighths rather than properly beamed groups as found in the original. Thankfully that is easily rectified by running Format>Reset Beams.
So yes, I've got easy workaround. But I think it would be far better if Musescore handled the import with greater panache. Doug Kerr and Leon Vinken have fixed the problems related to Encore's use of the MusicXML element—which results in an unmanageable mess on import. Once MuseScore commits Leon and Doug's fix, Encore MusicXML score import will be less problematic However, It should be know that, pre-export workarounds exist within Encore—but one has to be in the know and take steps to set modify score playback:
• Measures>Align Playback: This quantizes the start time of selected note match the literal onset according to the note's face value.
• Notes>Change Duration>Set play duration to 100% and uncheck Set Note Duration (i.e. face value)
In a similar way, why not roll out the welcome mat for the newcomers by fixing this beaming issue?
Imagine the hapless Encore refugee using Musescore for the first time, expecting this on import:
... but finding this:
The seminal and once-thriving Encore has a large community of scorists looking somewhere to go. I think Musescore is the place.
But Musescore has to convince Encore refugees that Musescore is a viable alternative by providing a good experience in their first few minutes. Likely a new use explores two avenues in their first minutes:
• 1) poking around the interface to see how one creates a score from scratch
• 2) importing MusicXML files generated from scores created in other notation applications.
Regarding 2) MuseScore needs to provide a clean bridge to Musescore via MusicXML so Encorians can easily leverage their existing scores into a new and better incarnations in MuseScore. Fixing beam import would be another step in that direction. And Encore users will confidently conclude, wow, that was easy. And they can immediately begin exploring Musescore from the perspective of a working score they're already familiar with.
scorster
In reply to I recently imported an… by scorster
In my case (https://musescore.org/en/node/328606) and with that specific XML file, applying the Format -> Reset Beams has zero result, nothing change. I've got to correct them one-by-one all by hands!
Thanks in advance for doing something for this issue.
In reply to In my case (https:/… by Trottolina
For some reason that I ignore it seems there are more instances in the piano stave than the voices ones, when SATB is involved.
Probably best to put this into the issue tracxker
In reply to Probably best to put this… by Jojo-Schmitz
#323168: Issues with beaming when importing Encore generated MusicXML
The simple explanation is that the "big backup" encoding is the recommended practice and different encodings have not been encountered often enough for me to support them in MuseScore.
In reply to The simple explanation is… by Leon Vinken
Reported again in https://musescore.org/en/node/328606.