Cross staff 8ths lose beam if all notes moved to staff above

1. I don't see any issue with slurce, not in measure 8, except them being too low in 3.0 so cut trough steh setm of the none in the middle, and even that only when resetting them to their default position.
2. the 8th in measure 18's piano treoble cled are usaing cross staff notation from bass cleff, and I don't see and good reason for that, they could just as well be notated on voice 2 on treble clef, like you did in measure 40 and 44.
   And deleting measure 18, treble and bass and copying measure 44 works without a problem too.
   Not sure what issue you see with measure 12 though, looks exactly the same in 2.3.2 and 3.0 except for the slur being too low in 3.0, same issue as in 1. Looks the same as measure 16, not at all like 18 or 44

So yes, there is an issue with the slur and the beam of the 3 cross staff 8ths in measure 18, but I don't see any other issue.

I see, that slur indeed behaves strangely )and may need an issue on its own). And yes, that cross staff problem is a real one

Before the sample score gets lost or updated, I'm attaching it here

Cross-staff slurs are a known issue, see #279182: Cross-staff slurs/ties trying to avoid note on wrong staff. Cross staff beams work fine normally, and I don't see a problem here in this score. Can you explain in more detail what the problem you are seeing with beams is?

I don't see the beam at all, the notes look like quarter notes
3.0:
2.3.2:

Oh, not just 18, 14 too, indeed

(EDIT: never mind the request for additional info, posts crossed)

So, not measure 12 at all, but other measures, thanks for clarifying. I can see now. Also, the pickup numbering made it ambiguous.

• Measure 12 has an issue with the slur in bass clef, double clickt it and see how it seems to related to the top staff.
• Measures 14 and 18 have the cross staff beams lost issue
• Measure 18 additionaly has the wrongly positioned slur

Clear as mud now? (and yes, this is measure numbers as displayed, I didn't spot that there is a pickup)

I can reproduce from scratch in 3.0, in one very specific case: moving from bottom staff to top, if all notes of the beam are moved. So:

1) new score for piano
2) enter four (beamed) eighths on bottom staff
3) select all four, Ctrl+Shift+Up to move to staff above

Result: beam disappears

And in this case, it's probably a duplicate of #280531: Beam separates from stems when crossing staves., but since the described case is slightly different, I'll leave both open.

Came up again in https://musescore.org/en/node/281258.

Came up again in https://musescore.org/en/node/281399

And again in https://musescore.org/en/3.0#comment-886311.

You can also do this from the top staff by
1) new multistaff score
2) enter notes of any duration so long as they're beamed on top staff
3) select any number of beamed groupings of notes
4) ctrl-shift-down and set steam direction to 'up'

The problem this creates is slightly different because the beam is still there just moved down a ridiculous amount.

Came up again in https://musescore.org/en/node/282054

Seems to affect beamed notes of any duration, not just 8ths. Also affects mixed durations, like a dotted eighth that shares a beam with a 16th. As Marc said, it the beam is only lost when moving notes to a higher staff, not when when moving notes to a lower staff. However, I find that if I move notes to a lower staff and then press Undo (Ctrl+Z) then the beam becomes detached (not lost) in a manor similar to #280531: Beam separates from stems when crossing staves..

My workaround is to score the 8th notes separately (no beam) and then move each one up separately and at least when they're up they still have the little tail/flag that denotes them as 8th notes.

Still a regression since this wasn't necessary in MuseScore 2.

This has happened to me too.

Relates to #285233: [EPIC] Cross-staff notation issues

Came up again in #285785: Display inconsistency when moving notes with beams between staves.

AGAIN in https://musescore.org/en/node/286325 !!!

BLOCKER !!!

sorry for editing regression

See the guidelines for the issue tracker to understand our system for determining severity:

https://musescore.org/en/handbook/developers-handbook/getting-started/h…

By the guidelines given there, this is "Major", not "Blocker". Please do not edit this field.

Could well be seen as Critical

FWIW, the distinction to me is whether cross-staff notation is a "key" feature or not, combined with whether the issue "prevents the user from using" the feature. To me this particular issue is borderline on both counts. Cross-staff notation is used by only a small percentage of scores, and much about cross-staff notation does work despite this bug (eg, the "normal" use case of a single beamed group that encompasses both staves). So, I would want all of this taken into account in categorizing this (or any) bug, lest we end up calling everything critical and thus end up losing the value of the categorization.

On the other hand, many other things about cross-staff don't work either - see #285233: [EPIC] Cross-staff notation issues. See collectively I definitely see cross-staff issues as critical, indeed one of the top three most critical regressions we need to fix before 3.1 (along with similar regressions involving small staves and with barlines, again none of which individually are necessarily critical in themselves). So in the end. it's indeed borderline major/critical. But definitely not "blocker" in any sense according to our definitions.

Anyhow, worth discussing because we're still feeling out these definitions.

Almost every symphonic score with a harp uses cross staff notation, sometimes because MuseScore doesn't support other things like cross staff arpeggios other times because that's the way it's notated. This is far from a rare occurrence if you transcribe 20th century music, it's common.

Orchestra music with harp might not be "rare" but it is. as I said, a "small percentage of scores". Piano scores probably make up a bigger percentage. But also, it's not all uses of cross-staff notation that fail, just the specific ones involving all notes being moved, which is probably itself a relatively small percentage of all uses of cross-staff notation, since these cases can generally also be notated with multiple voices.

Again, the point isn't to say we don't want to fix this - of course we do, and as I said, issues with cross-staff beaming collectively are in my personal top 3 must fixes for 3.1. So please don't think I'm trying to minimize the importance of this - I am the single biggest advoctae for fixing this there is, which is why i went to the trouble of creating the EPIC I linked to.

But I also think it is important we try to be consistent about how we apply the categorizations. So we do need to make distinctions, or we'd have no way of assigning relative severity of this compared to a bug that, say, rendered all beaming useless. I might personally have developed a somewhat different scale than the one in the guidelines I linked to, but it's better if we all learn to apply them consistently than if we each just assign things however we feel like.

https://github.com/musescore/MuseScore/pull/4814

I have a possible workaround ONLY FOR PIANO:
1.For the original voice, instead of actually moving these notes to the upper staff, just create a rest that covers the time of all these notes. (e.g. if there are four 8ths to be moved, create a 2nd rest.) Then hide that rest using the "V" button.
2. Create a new voice on the upper staff and place your moved notes on that staff. Use the aforementioned method to create "invisible" rests to fill the time length of the whole bar, just as if it were a brand new voice. (Otherwise some other bugs would arise. )
3. Now your score should be 100% similar to the one you wanted to create, but without any problems on beams.

Fixed in branch master, commit 8dd7a02da0

fix #280969: cross-staff notes lose beam if all moved up

Fixed in branch master, commit 0a0a9c6745

_Merge pull request #4814 from MarcSabatella/cross-staff-1

fix #280969: cross-staff notes lose beam if all moved up_

This came up in https://musescore.org/en/node/287522 with grace notes. I'm curious if this PR fixes grace notes also or does there need to be a new bug report?

I checked, and the file posted there works fine in current master. I didn't do anything special to make grace notes work, but I guess they weren't any worse than regular notes.

My suspicion was the the grace notes used the same code as regular notes, I just wanted to be sure.

Automatically closed -- issue fixed for 2 weeks with no activity.