Partial beam on wrong side with cross staff notation

Well, although I am not sure what the fix is, I can say exactly where this goes wrong:

https://github.com/musescore/MuseScore/blob/95cc9d8cd2d95885a23ff1e0bcb…

This line - "growDown = _up || _cross" - does exactly what it looks like: it makes the beams "grow" (from 8th to 16th to 32nd) downwards if the beam is "up" (eg, above the notes) or if the beam is connecting cross-staff notes. The first part makes total sense - notes with upstems have the eighth note beam on top, beams are added downward from there. But forcing cross-staff beams to always grow downward is why this partial segment ends up below the main beam even when the beam is below both notes.

Simply removing the "|| _cross" fixes this, but I strongly suspect it is not that simple. For one thing, the converse case - where the first note rather than the second is moved up - is broken with or without this change, and you don't even have to drag the beam for it to be drawn wrong. I tried a whole bunch of cases, including some with patterns like eighth and two sixteenths, case with sub-beams, cases with no cross staff notation but notes more than two octaves apart and the beam placed between them, etc. Some of them look a little funny, but it's harder to say they are *wrong*. I'd have to spend more time studying Gould and other sources to even know what the rules are supposed to be.

Here is how some of these case look currently:

Removing the "|| _cross" does't really make much of a difference. I've attached this test file if anyone wants to play with it.

Anyhow, that's as far as my investigation has taken me so far. I'm about done for the night (USA time) and have pretty busy day tomorrow, so I wouldn't be getting much further with this for aniother day or two, if someone else wants to take over from here. I think this single line needs to be replaced with something more sophisticated, but don't know the expected results or the code well enough yet to say. If no one else jumps on it soon, I'll take another look, as I'd love to see this resolved for 2.0 if possible.

EDIT: Gould has quite a few examples and guidelines on p. 314-319. I bet we could knock out a pretty good subset of this in not a lot of lines of code.

OK, I turning my attention to this. Probably won't get too far tonight, but I'll try to have something tomorrow.

I'm trusting for now that simply setting "growDown" appropriately will do everything that needs doing - that the beam and stems will do the right thing and align correctly. It sure looked that way in my initial playing with this.

One interesting thing I've discovered:

Currently, there is no workaround if you don't like the direction that the beams "grow". However, if I do simply remove the "|| _cross" from that line and do nothing else, it becomes possible to flip the grow direction by clicking the beam and pressing "X". So even if you can't come up with perfect defaults, doing this would at least provide user with a workaround.

I'm kind of hoping to find a solution that gives us better defaults in a good number of cases, while also allowing the user to override with "X". I am thinking that the calculation of "_up" is going to be the key to doing that. Right now, it doesn't seem this calculation is necessarily very meaningful except in the simplest cases. But this code is pretty hard to understand.

Working on this again...

Absolutely incredible - just as lasconic and I were discussing approaches to this on IRC, Thomas piped in with this link, just posted today on Daniel Spreadbury's blog for Steinberg:

http://blog.steinberg.net/2015/03/development-diary-part-10

Anyhow, apparently we are all on the same page, and I think I have a solution, just doing more tests and expecting to perhaps need to add a special case here or there.

So far, I've just read the parts directly relevant to what I'm working on. The fact that I plan to go back later and read the rest is what makes me an "engraving nerd" :-)

Took quite a while - and help from lasconic on top of the unintentional help from Daniel Spreadbury - to get to the bottom of this, but in the end, it's a quite simple change with very good results:

https://github.com/musescore/MuseScore/pull/1846

(checkout the vtests in the PR to see the effects)

The second could indeed probably be improved even if we don't always get it.

The first is something I worried about when I first started messing with this code - worried we'd add a beam somewhere that didn't make sense and we'd get a floating beam like this. Somehow I guess I need to keep track of the "current" group growth direction and not deviate from it as we start piling groups on top of groups.

PR to fix the first issue above, and other issues where my original fix produced "floating" beams.

https://github.com/musescore/MuseScore/pull/1849

Here is the vtest I created to exercise the new code:

I still don't totally get the second issue in the previous comment. Something about beams that include two separate groups, at least one of which has opposing outer stems, yes, but does it only apply if *both* groups have opposing stems? Does it only apply to the opposing-outer-stem groups, or should it also force non-opposing-outer-stem groups to have the same direction? Gould isn't that clear to me on this.

In any case, frankly, I don't think the suggestions given look that better than we already do, but there aren't enough examples for me totally understand the rule.

That PR is now merged too, along with a an improvement to the beam angle of two-note pairs.

Testing welcome - if there are regressions, let's catch them now!