Beaming over rests makes stems too long
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Few
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
Yes
Workaround
No
Project
If you move the rest, the beam moves exactly with it, so I think an incorrect value was entered somewhere for the minimum rest to beam distance.
Comments
Anything on this? Thanks.
This has changed a bit, I think? Now the beams don't avoid rests enough when they're pointing up, and still too much when down.
So by fixing beam information updating for rests and tweaking some parameters I was able to achieve something like this:
Not sure this is a perfect result but still seems to be better.
The pull request on this: https://github.com/musescore/MuseScore/pull/4377.
Fixed in branch master, commit 4eb78bab62
fix #279080: update beam info for rests, tweak rest beams parameters
Fixed in branch master, commit f66b4a1d2a
Merge pull request #4377 from dmitrio95/279080-beam-over-rest
fix #279080: update beam info for rests, tweak rest beams parameters
Current Nightly, b0c3cf5:
MS 2.3.2:
What the beam should look like:
We're not quite fixed here yet, I think.
Indeed, but not quite as bad, so while it's entirely possible this will get another look before release, I'm downgrading the priority slightly.
According to p.36 of Gould's "Behind Bars", it is the rests that are supposed to move to make way for the beams, not the other way around.
Incorrect:
Correct:
I also noticed that if you try to move the rest manually by dragging it with the mouse, or by changing the vertical offset in the Inspector, then beam will follow (correct), but if you double-click on the rest and move it with the arrow keys then the beam doesn't move (incorrect).
You are supposed to move rests, but not to this extent. Hence the picture. I actually think, after playing with it for a bit that what is happening is the eighth-sixteenth beam is avoiding the rest like a full sixteenth beam, when it should be doing so like a full eighth beam, although I do think the full sixteenth avoids the rest just a hair too much itself.
If you'll note in the pictures I had posted above, the rest was in the same place in every single one.
@Laurelin, my post was a criticism of MuseScore's engraving skills, not yours ;)
The rest is indeed supposed to move that far because the beam is not supposed to move at all (at least not according to Gould). She writes:
> Place the beam in its normal position. If necessary, rests may move away from the centre of the stave to a position closer to surrounding notes
I put the rest as close to the beam as it would go without making the beam move from its default position. The point is that MuseScore's automatic layout should do this for you.
Thanks, shoogle, lol.
Since the first fix made it better, here is a little more detail:
What the music should look like:
What music looks like if you adjust the rests so the beams don't get affected:
what the music looks like if you leave rests where they should be:
tl;dr: upward oriented beams are fine(when only eighth notes), downward oriented beams avoid rests by exactly 1 sp too much.
Came up again in #318910: 16th rest between beamed 8th note and 16th note moves upward when entering voice 2
At least similer, here only in a multi-voice context
Relates to #311175: [EPIC] Engraving issues and suggestions
See also https://github.com/musescore/MuseScore/issues/9009
#17784: Beaming across rests results in collisions
#16098: Rests between beamed notes don't relocate