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

• Dec 31, 2018 - 13:08
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Many
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
Tags

When importing the musescore 2.x mscx file from
https://musescore.com/wglas/scores/5280158
into musescore-3.0.0, I observer the following problems:
1. Slurs misplaced an associate to treble stave instead of the bass stave (first seen in bar 8, slur displayed in bass stave, but somehow logically associated to the treble stave, when the slur is selected)
2. Eigths movement misformatted, because the three eigths in the second voice are associated to the bass stave instead of the treble stave. (bar 12 and 18, eigths movement displayed in treble stave, but somehow logically associated to the bass stave, when the three eigths are selected)

When trying to fix problem 2., the program sometimes crashes. I was able to copy the eigth movement from bar 44 to bar 12 and 18, so I have found a workaround.
Problem 1. may be fixed by deleting the slur and re-entering it again.


Comments

Status active needs info
  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.

Hello Jojo-Schmitz,

Thanks for your response.

  1. As far as I analyzed the slur issue, the wrong position is cause by the fact, that the slur is somehow associated to the wrong stave, see the attached screen shot, where the handles of the stem-to-be-edited are draw in the wrong stave.
  2. I was unaware of the cross-stave notation feature and probably I incidentally used it. However, MS3 does not render the eighth-beam on the cross-stave eighths, which is a regression to MS2.
Attachment Size
musescore-280969-cross-stave-stem.png 53.35 KB
Title Import errors with artifacts associated to wrong stave Cross staff 8ths lose beam and have slur placed wrongly on import from 2.x
Priority P1 - High

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

Hello Jojo-Schmitz,

Thanks for your response, please be patient with me as I was unable to figure out how many issues are contained in my example. It even took me several minutes to discover, that this has something to do with cross-stave artifacts ;-)
Regards, Wolfgang

(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)

Title Cross staff 8ths lose beam on import from 2.x Cross staff 8ths lose beam if all notes moved to staff above
Priority P1 - High P0 - Critical

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

In reply to by Marc Sabatella

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.

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..

Regression Yes No

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.

Title Cross staff 8ths lose beam if all notes moved to staff above Cross staff 8ths LOSE beam if all notes moved to staff above!!!
Regression No Yes

sorry for editing regression

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

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.

Workaround No Yes

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.

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.

Fix version
3.1.0