16th rest between beamed 8th note and 16th note moves upward when entering voice 2
Reported version
3.6
Type
Development
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
duplicate
Regression
No
Workaround
Yes
Project
OS: macOS High Sierra (10.13)
Arch.: x86_64, MuseScore version (64-bit): 3.6.2.548020600
revision: 3224f34
Step to Reproduce:
1.Enter 8th note, 16th rest and 16th note
2.Make them merge with beam middle via Beam properties
3.Enter note in voice 2
Result:
16th rest moves upward and beam extend upward.
Workaround:
Moves 16th rest down manually.
| Attachment | Size |
|---|---|
| 16th_rest.jpg | 30.86 KB |
| 16th_rest2.jpg | 30.83 KB |
| 16th_rest3.jpg | 37.81 KB |
Comments
This is what it supposed to do. May look strange in that perticular case and you can move the rest down manualy to remedy, but other than that it's not a bug
In reply to This is what it supposed to… by Jojo-Schmitz
OK, its by design.
In this particular case looks buggy, though.
Thanks !
Actually a duplicate, see #279080: Beaming over rests makes stems too long, at least related
Relates to #311175: [EPIC] Engraving issues and suggestions
In reply to Actually a duplicate, see … by Jojo-Schmitz
Indeed, Thanks!
In reply to Actually a duplicate, see … by Jojo-Schmitz
umm.. not sure if it’s a duplicate since this is occurred in multi-voices situation..
The multi-voice one might be really by design, as then the rests do move up and the beam has no choice than to move up too, to avoid colission
In reply to The multi-voice one might be… by Jojo-Schmitz
Yep, it’s by design to avoid collision for beam and rest, I understand :-)
Maybe the best is rest doesn’t move up when overhead beaming.
to then (potentially) collide with voice 2... Manual intervention would be needed in most cases here
In reply to to then (potentially)… by Jojo-Schmitz
ah.. right.
Thanks jojo :D