Voice 1 rests collide with voice 3 rhythm slashes (above the staff)

• Aug 8, 2020 - 05:01
Reported version
3.5
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
MuseScore

Workaround appears to be to manually move the rest; however it's something that didn't have to be done in 3.4.2.

To reproduce:
- 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
- Observe

Attachment Size
Rhythm Slash Rest Collision.mscz 4.66 KB
Rest and Rhythm Slash Collision.png 14.03 KB

Comments

• Sep 17, 2020 - 17:55

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.

Reply

• Sep 17, 2020 - 18:08

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:

https://github.com/musescore/MuseScore/blob/3.4.2/libmscore/rest.cpp#L4…

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.

Reply

• Sep 17, 2020 - 19:43

@Marc Sabatella

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.

Reply

• Sep 17, 2020 - 19:57

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.

Reply

Fix version
3.6.0