Stems length of beamed notes change with layout
Ubuntu 14.04, GIT commit: 699a5ee
Reported first in https://musescore.org/en/node/79436
1) load attached score
Note the stem lengths differ between the two note , for no apparent reason:
Now, press Ctrl+B to append a measure, and repeat this. Every so often, one or both of the note groups will see the stem lengths change.
I can't say one answer is right and the other wrong, but it makes no sense to me that this should be so variable. Knowing what I do of the beaming code, I suspect is going to be painful to track down exactly what is happening here.
| Attachment | Size |
|---|---|
| stem-length.mscz | 3.65 KB |
Comments
Here is the result using "Emmentaler". It is like what Marc has posted:
Now, here it is with "Gonville":
Here it is when using "Bravura":
I can't say which set of stem lengths is accurate, because I honestly don't know what length is correct when it comes to beamed notes. If anyone has input on that, maybe it could help.
EDIT: I did not download the attached score. I recreated this result.
Windows 7
MuseScore 2.0.2
If we abide by Behind Bars, then the correct beaming is the shorter case, which has 3sp C and 3.25sp F, as opposed to the longer case with 3.75sp C and 4sp F. I'm using the stem length to be the distance from the note's line position and the outside edge of the first beam.
Page 21 says "The stem that is going to be the shorter determines the starting point of the beam. This stem may be shortened to 3 stave-spaces when inside the stave and to 2.5 stave-spaces when outside the stave." The other stems get lengthened as necessary.
Looking through Gould's examples, each instance of beamed notes (with unequal stem lengths) has a shortest stem of at most 3 stave-spaces. MuseScore's current default behaviour appears to be this, too.
In our example, given the stem direction, the C's stem will be shorter, so it gets shortened to 3sp. The F gets whatever length is necessary to touch the beam. This is consistent with the case with shorter stems. The other case has a shortest stem of 3.5 stave-spaces.
I think the reason for the inconsistency is the code trying to round the beam's position to the nearest staffline. The C's stem "hangs" and the F's stem "centers". If the code decides the beam needs to begin lower (perhaps if it thinks the C needs a longer stem), then it will force the C's stem to center on the line below, and the F's stem will also move from its centered position to a sitting position on the line below.
There are probably multiple "correct" solutions. To be consistent, I think a good solution is to identify a beam group's "shortest" stem and base the beam's position on that.