Partial beam on wrong side with cross staff notation

• Feb 2, 2015 - 17:08
S4 - Minor

Ubuntu 14.04, GIT commit: e1a97ce

1) piano score
2) bass staff, note entry
3) 3 0 E 4 G Ctrl+Shift+Up to enter sixteenth rest, sixteenth E, eighth G moved to treble staff
4) double click beam and drag below the E

Result: the partial beam for the sixteenth E is below the main beam rather than above:



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

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.

Attachment Size
partial-cross.mscz 9.22 KB

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.

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" :-)

Looks great!

I found some corner cases.

The second one is the last paragraph on page 316 of Behind Bars. As we said, it would need a more general knowledge of the whole beam. However, I believe we are processing the note/beam in the right order to "remember" the decision we took previously so it could be done in a next iteration on the code.

The first one I didn't investigate it yet. (p318)

Capture d'écran 2015-03-07 10.07.37.png

Attachment Size
testbeam.mscz 9.92 KB

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.

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!