Beam properties issues on file imported from MusicXML

ad1) seems the note before the 2nd read note has no beaming property, Change it to Auto fixes the issue
ad 2) see #99761: Unnecessary beams over rests and #52151: "Auto" beam setting for *Rests* should not beam (if no stemlets)
ad 3) probably the same as 1)

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.

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 to.it, 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?

Oops I think I didn't use double-click

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.

how about just translating beam end to Auto in XML import, automatically, without Options?

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.

Simple fix, will check if this works OK and does not cause regression.

Has a fix been implemented and merged?

I am not quite sure, this will take some time to investigate (I could not quickly find it).

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 github.com:lvinken/MuseScore.git.

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

URL to that: https://github.com/lvinken/MuseScore/tree/100901-musicxml-beam and 69488b0

It does work fine with the XML from this issue here, so I turned it into a PR, see https://github.com/musescore/MuseScore/pull/3221. Let's see what the mtests look in Travis.

Fixed in branch master, commit d44c73e1f9

fix #100901 by setting beam mode auto instead of end

Fixed in branch master, commit 3137868ac2

Merge pull request #3221 from Jojo-Schmitz/xml

fix #100901 by setting beam mode auto instead of end

Fixed in branch 2.2, commit ee770b626d

fix #100901 by setting beam mode auto instead of end

Automatically closed -- issue fixed for 2 weeks with no activity.