Bug with moving note horizontally in edit mode: top of beam suddenly jumps to the top of the paper, out of reach
Shares partly similarity with issue https://musescore.org/en/node/99656
From the attached file, when double clicking on the 13th note in bar 3, to enter edit mode then nudging the note to the left with the left cursor key, then the image appears as can be seen in the following picture:
Bug is also present in 2.1, could not find this bug reported already.
Is there a workaround or solution for this?
Attachment | Size |
---|---|
Kreutzer_16.mscz | 16.37 KB |
Comments
Maybe it's best to use Inspector rather than arrows. Try using the Beam Properties palette after clicking the note (Are not they too close?)
To fix this: select measure 3 -> Ctrl + R
Basically, it occurs when you apply in "Chord" section a strong horizontal offset to a note (it was the case in your file with eg the E and F, inter alia) and so, leads to go beyond the other at a certain moment.
To reproduce (this issue recall something to me, but not sure if this behaviour was reported or where?):
1) Load this file: test file.mscz
2) Select the second 16th, and apply to "Chord" a strong horizontal offset (eg -7,50).
Result:
Ditto eg with the third 16th with let's say +7,00
In reply to Basically, it occurs when… by cadiz1
The reason for this dense notation is that I'd like to put bars 3, 4 and 5 on one system. Both inspector and arrows cause the same behaviour. Resetting bar 3 does not help to place these bars on one system.
I think the algorithm to evenly distribute the note-spacing after moving a note horizontally is with such extreme shifts unable to render properly. A remedy would be to not allow notes to jump before other notes, and instead placing the note as dense as possible.
Also a feature to select a range of bars and then set an option to force keeping these bars together would be helpful.
As a workaround, I moved from bar 3, 4 and 5 all 1/8th notes closer to their previous notes and with that, the software automatically placed those bars on one system. After that I was able to select the 1/16th notes as well, without any lengthy stems appearing.
What make you think it not to be a duplicate of #99656: Elongated note stems by moving beamed note before predecessor (using horizontal offset of *chord*)?
In reply to The reason for this dense… by w_m0zart
"As a workaround, I moved from bar 3, 4 and 5 all 1/8th notes closer to their previous notes and with that, the software automatically placed those bars on one system. After that I was able to select the 1/16th notes as well, without any lengthy stems appearing."
As a workaround, it takes a lot of operations. Simpler and faster is to reduce the Staff space (scaling) in Layout -> Page Settings. See: Kreutzer.mscz
But that's just another way to get that. Because, most importantly, it is much too early to want to adjust the layout right now.
Wait until you have entered your score before to finalize this layout (as a first aid, you may start by determining the number of measures per staff in Edit / Tools / Add / Remove line breaks, but this is only temporary help)
"Also a feature to select a range of bars and then set an option to force keeping these bars together would be helpful."
Add line breaks (when the entry of notes is finalized)
"What make you think it not to be a duplicate of" #99656: Elongated note stems by moving beamed note before predecessor (using horizontal offset of *chord*)
Ah yes, it's this, my remember! :) https://musescore.org/en/node/99656#comment-443841
So agree for duplicate.
In reply to What make you think it not… by Jojo-Schmitz
The fist image showing the issue at #99656 showed a very long horizontal beam, and I was having a very long vertical stem. Looking further down however, is exactly the same issue. So it is probably best to mark this issue as a duplicate of #99656
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.