Beam properties issues on file imported from MusicXML

• Mar 5, 2016 - 16:56
Reported version
S4 - Minor

Nightly acf6580 on Win 7 / MS 2.0.2 on Win 10.

See attached score. The detailed instructions are in the file but here's a summary:

1. It's not possible to beam all 1/8th notes in a bar using the "Beam middle" tool.
2. If you select the whole score (Ctrl + A) and click on "Auto" (in "the "Beam properties palette) beams appear unexpectedly between lone 1/8th notes and rests.
3. If you beam all the 1/8 notes into one group in the "Time signature properties" of the displayed time signature, it does not seem to affect the score at all.

Attachment Size
beaming_problems.mscz 29.05 KB


Status (old) active needs info

The beam property for the "E" in between the two red notes is set explicitly to "beam end". That is indeed why the beaming doesn't work as you expected when changing the beam properties on the following note.

Now, as far as I know, "beam end" is not meant to be something you can set yourself - it's something used internally only for the most part I believe. So I'm not sure how the score got into this state - there may be a bug that led to this. If you have any insight into how this might have happened - ideally if you can provide steps to reproduce the problem - please let us know. I guess maybe import from MusicXML or some other format might have legitimately created this result. If so, can you post the original file that was imported?

As for #3, changing time signature properties only affects the *default* beaming, but you have override the defaults all over the place, and these overrides are preserved. That much is by design.

Status (old) active needs info

As far as I can tell, then, this is by design - your MusicXML file clearly sets a beam end for the notes in question. Now, perhaps we could convert this to an auto if we detect that it will result in the same thing, but I have no idea if that is a reaosnable or legitimate thing to do. So perhaps this could be turned into a feature request for such automatic conversion of explicit beam ends into "auto" properties. Would be good to hear from a MusicXML expert, which is why I'm leaving this at "needs info" for now. If it is deemed appropriate, we could turn it into a feature request.

Meanwhile, though, you should treat this as by design - your input file specifically requested beam ends where it did, so if you wish to override that, you'll have to do so manually. In general, MusicXML files usually overspecify a lot of things - stem directions, etc. This is so the default rendering will be as close to the original as possible. But it does mean these things are locked as opposed to left automatic, so future edits won't necessarily work the way you might have expected had the elements been entered from scratch. So if you import a MusicXML file into MuseScore and then intend to edit much, you should generally be in the habit of resetting as much as you can to automatic settings. Usually, Ctrl+A followed by Ctrl+R followed by Layout / Reset Beam Mode should be the first thing you do after import if you intend to do much editing.

Interesting that in MuseScore's Beam palette there is no "End Beam". And these notes can't get set to "Auto" directly, you need to set them to something else first, like "No Beam"!
Also strange that the XML imports as virtually empty in MuseScore 2.0.2

Like I said, as far as I know "end beam" is not meant to be user accessible - it doesn't really fit well with how we present beaming to the user. I think it's probably provided just for MusicXML import, but I don't know that for a fact.

Anyhow, I don't have any trouble setting directly to Auto. What goes wrong when you try? For me, the following works fine:

1) click first red note
2) double click "beam middle"
3) click next note
4) double click "auto"
5) click next red note
6) double click "beam middle"

If I select a note with end beam and apply auto, deselect it, then select it again, it doesn't show auto, but still nothing in the palette

I can't reproduce that. Can you give me more precise steps? I tried the following: using the current master and 2.0.2:

1) click the note between the two red notes
2) double click "auto"
3) press left to move selection to previous note
4) press right

Result: auto shows in palette, as expected

In any case, whether the icon in the palette reflects it or not, it *behaves* like auto has been applied, right?

Title Beam properties issues (in 3/4) Beam properties issues on file imported from MusicXML

I wouldn't mind hearing from a MusicXML expert before deciding there is nothing we can/should do. Hopefully the title change will help...

Most MusicXML files explicitly state where beams begin and end, the importer unconditionally translates this into begin and end flags. I could imagine making this behaviour optional or user defined, but cannot judge whether ignoring MusicXML info would help or hurt.

This is basically a question of trying to import as much information as possible (layout included) versus the minimum (only the musical information etc).

Finally, creating many import settings will probably confuse the users.

Since we don't normally otherwise support "beam end" as a separate entity, my impression is that converting beam end to auto would work fine. We'd still have explicit beam starts on the next note, so files should still import properly, but it would be a bit simpler to figure out how to override this - you'd only have to change the property on the start of the enxt beam, just as with scores created from scratch. But of course, resetting all beams works just fine, so it's really not a big deal either way. Just slightly surprising and hard to discover.

Just checked: in the trunk as of commit ad066ac (day before yesterday) there is no fix yet.

See file mscore/importmxmlpass2.cpp, functions MusicXMLParserPass2::note(), MusicXMLParserPass2::beam() and findOrCreateChord().

Function beam() directly translates MusicXML begin and end into MuseScore's Beam::Mode::BEGIN and Beam::Mode::END, which is then unconditionally set by findOrCreateChord().

Same code is in the 2.1 and 2.2 branches.

Put a quick fix in branch 100901-musicxml-beam in repo

Unfortunately, I won't have time for testing / creating a pull request for quite some time. Would not mind if some volunteer does that.