Beaming a rest moves it off-centre
OS: Windows 10 Version 2009, Arch.: x86_64, MuseScore version (64-bit): 4.0.0-223362132, revision: d050fb0
- Add a beam to a rest to group surrounding notes.
- Note that the rest moves to the left.
Expectation is that spacing is consistent on both sides.
(I also see an example of the old bug where sequential adding of notes by keyboard entry fails if the starting clef has been altered anywhere previously in that stave. When I typed D a second time, it was placed three octaves higher)
| Attachment | Size |
|---|---|
| Untitled.png | 6.92 KB |
Comments
I can confirm the rest placement issue. As requested in the beta announcement, please open this as an issue on GitHub so the developers can investigate further and fix the issue.
For the other issue, if you can manage to find precise steps to reproduce the problem, please open a separate issue for that and include those steps and/or the score that demonstrates the problem. I think many of use have seen this over the years indeed, but so far to my recollection no one has figured out steps to reproduce the problem - it just sort of happens randomly every hundred or so times.
See #337701: Beaming a rest moves it off-centre
But this isn't on GitHub
In reply to See #337701: Beaming a rest… by Jojo-Schmitz
The announcement gives the choice of using GitHub or "Alternatively, you can submit any issues you find on our issue tracker: https://musescore.org/en/project/issues/musescore"
In reply to The announcement gives the… by memeweaver
Have a look at this. MS3 versus MS4 (both not good, but v4 worse)
In reply to Have a look at this. MS3… by graffesmusic
The vertical positioning is something different. MU3 lengthened the stems to avoid the rests not good at all. The correct answer is to move the rest. MU4 does neither, but allows you to move the rest manually, so it's easy to get the right answer. And it's already being planned to do auto adjustment of the rest in a future update.
In reply to The announcement gives the… by memeweaver
You can submit on the issue tracker for initial "triage" (where the rest of the community helps determine if it's a real bug or not), but then in order for the actual developers to look at it, you'll need to post to GitHub. I consider this thread all the triage that is needed it's ready for GitHub now. The team working on these engraving issues is extremely proactive. Probably too late to make it into the initial 4.0.0, but I'd expect they would be able to fix this for 4.0.1.
https://github.com/musescore/MuseScore/pull/14866 (didn't make it into 4.0, but is in master/available in nightly builds)