stems of bottom staff notes wrong with cross staff beaming
Enter the following chords
move the 3rd and 4th chord in the 2nd group to the upper stave and get this
double click the beam and adjust it, double click the stems to adjust them to get this:
2.0 Beta 1 and later nightly builds up to at least fc3ea8e
See http://musescore.org/en/node/30866#comment-161106
Workaround: select the bogus stems and increase their vertical offset to 2.5sp in inspector.
See also #26936: Issues with cross staff notation in 1.3 scores with flipped beams/stems, #22638: Stem of beamed note in cross staff incorrectly positioned and #18943: Request for implementation of optical spacing, not sure whether these are all duplicates of one another.
Attachment | Size |
---|---|
Cross-staff-beam.mscz | 1.83 KB |
Comments
Current behavior is much better, if still not ideal - here is the result on initial move:
If you adjust it manually, then undo, you get something not unlike the arrangement in the original report. But then if you hit Ctrl+R (with the beam selected), it returns to what I show above.
Actually, it's only slightly better. Immediately after the move, things do indeed look like the picture I posted. But if you do try to adjust the beam, you can get it to look OK for a moment, but as soon as you enter more notes or do anything else to cause a relayout, the stems get messed up as in the original. That is, not just Undo but anything you do after adjusting the beam messes up the stems.
So, to recap:
1) open attached score
2) select last two chords
3) Ctrl+Shift+Up to move up
4) Ctrl+A to force a relayout
Result: as shown in original report
seems to be fixed in f262e9c107. I cannot reproduce anymore.
No, it is not, unfortunately , this is the fix Marc (and I) tested with too (starting at #2), as soon as it was available.
But seems Marc's steps are incomplete?
Insert
step 3.4) double click bar to enter edit mode
step 3.5) adjust beam (left handle up, right handle down)
step 3.6) Esc to end edit mode
Fixed in 6bbcfb55e5
Indeed, in #3 I left out the important step of moving the beam between steps 3 & 4. But in any event, I can confirm it is now fixed.
Automatically closed -- issue fixed for 2 weeks with no activity.