Voice 1 rests collide with voice 3 rhythm slashes (above the staff)
S3 - Major
Workaround appears to be to manually move the rest; however it's something that didn't have to be done in 3.4.2.
- Use Voice 3 to create some rhythm slashes that go above the staff by typing in some notes, selecting them, and then go to Tools > Toggle Rhythmic Slash Notation
- Leave some empty rests in Voice 1
|Rhythm Slash Rest Collision.mscz||4.66 KB|
|Rest and Rhythm Slash Collision.png||14.03 KB|
Reuploading attachments since they seem to not work
I guess the code that tries to avoid collisions between notes and rests is backfiring here. 3.4.2 would have created lots of these collisions when not using rhythmic slash notation, and those are now fixed, but it seems this is somehow now creating one where it didn't exist before.
More generally, though, see #100521: Rests collide when using accent notation (Toggle Rhythmic Slash Notation), which is closed not because anything was actually fixed, but just because the details have changed. It shows that actually, similar collisions in rhythmic slash notation have long been a problem.
I think the deal is that for a few releases, the algorithm had been changed to not try to adjust rests in voice 1 if there was no content in voice 3 - only if there was content in voice 2 or 4. This would seem kind of logical and could explain the results, but I don't actually remember that code ever existing.
I think I found the code, it was a hack really and it probably shouldn't have worked for this case, but it happened to:
I think the intent of this code had nothing to do with voice 3 but was just to make sure a piece with only two voices and yet nothing but deleted rests in voice 2 wouldn't trigger the offset. It was just kind of dumb luck I think that a completely empty voice 2 forced the rest back down even if voice 3 was present. And really it was a bug - content in voice 4 would not force voice 1 rest up as a result of this code.
So I don't propose reinstating that code, exactly. But maybe a smarter check here would be good. Perhaps even something more like the code in https://github.com/musescore/MuseScore/pull/2475 that was originally written to solve the problem for 2.x. Although I'm not so comfortable with actually changing the semantics of checkMultiVoices (and then needing to account for that changes elsewhere, and then also make sure undo works.
Think there's a chance we'll ever get first-class rhythm slash support rather than having to finagle one of the voices to do it? Having standardized positioning and treatment for above-the-staff rhythm slashes would be fantastic for jazz purposes.
A chance? Sure. But, what about the current method doesn't work for you? Isn't the positioning standardized already? EDIT: other than the issue involving rests in voice 1 of course.
Related to #311175: [EPIC] Engraving issues and suggestions
The pull request avoid y-offsets for rests when there is any note in chord with slash notation. Is this the desired behavior?
Fixed in branch 3.x, commit 528db841bb
fix #308726: Avoid rest offsets with slash notation
Automatically closed -- issue fixed for 2 weeks with no activity.