musecore 3.6 - percu stave : rythmic slash notation problem on voice 3 ?

• Mar 14, 2021 - 11:22

1. Set some drum figures in voice 1
2. exchange voice 1-3
3. Select voice 3 and toggle rythmic slash notation
4. Fill voice 1 with slash
The rests are not on top of the stave but "in" the slashes

Could it be a regression in 3.6 version or there is another way to do this ?
Thank you !

Attachment Size
Drums notation problem.mscz 7.01 KB


It is unfortunately a regression indeed, the algorithm for avoiding collision between rests and other content is not accounting for the slash notation properly. Previously rests would happily collide with other notes, now they don't, but do collide with slashes. Workaround is to right-click one such rest, Select / More / Same voice, then adjust the Y offset in the Inspector.

In reply to by tobik

See my comment in the PR that fixed that issue:

"If I'm following this correctly, the original problem was that rests not in slash notation were being offset unnecessarily. Now, unfortunately, the rests that are in slash are not being offset either, and they definitely need to be (and were previously).

Probably the code added here needs to be skipped if the current rest is itself in slash notation. Well, at least if in voice 3 or 4, which are the ones that need to be offset."

In reply to by Marc Sabatella

The original issue had displaced rests when the slash notation is above the staff

The new issue does NOT have displaced rests when the slash notation is in the staff

Marc suggestion is displace if the current rest is in slash notation. But as far as I can see this would not fix this issue.

In reply to by tobik

No, I said skip that code if the current rest is in slash notation. The code I am saying to skip is the code you added that changed the first picture into the second. Thus, the blue rest in the first picture continues to get fixed by your code because that rest is not in slash notation. And the red rest in the second picture would go back to what it would have been before you added your code, which was correct.

In reply to by tobik

Except that was actually a good fix that helped a lot of other cases. Did you try what I suggested above? Maybe I'm missing something, but I am not seeing how it could fail to work. The specific block of code in question - the one at… - should simply be skipped if the current rest is in slash notation.

More specifically, that means checking accent() for the current rest. So instead of "if (offsetVoices)", make it "if (offsetVoices && !iaccent())". This preserves your code in the other cases where it is needed, but disables it here where it is not appropriate.

I tried it and as far as I can that one-line change fixes it and shouldn't break anything else. So assuming we're otherwise OK with how the rest positioning code is working, this seems the right thing to do.

In reply to by Marc Sabatella

I tried your suggestion and at the first glance it works with both examples. But just set the rest to standard size will make it fail because of Rest::accent() { return voice > 1 && small() }

a) Is Rest::accent() really the correct condition that characterizes a slash notation?

b) I still assume that all rests in both examples are not in slash but in standard notation. Is Rest::isSlashNotation() really the correct property to distinguish this two cases?

c) My proposal is Chord::isThereAnySlashNotation && Rest::Voice() > 1

In reply to by tobik

Well, we (actually "I") made the conscious choice not to introduce new properties for slash notation. So the best we can do is rely on the specific properties that are actually set by the slash commands. Rests aren't part of "fill with slashes", only "rhythmic slash notation". In voices 1 & 2, the rhythmic notation is full size and not offset outside the staff; only in voices 3 & 4 is it made small and offset.

So, technically, a rest in voice 1 or 2 that is part of rhythmic slash notation probably should be considered as slash notation also. But there is absolutely nothing about it to indicate that it is anything but normal. And probably that's OK. I guess if you try combing rhythmic notation in voice 1 with accent notation in 3, weird things might happen, but that's a weird case to begin with. Not worth worrying about to me.

Bottom line: I still think my prospal does what we want. There just isn't anything we can reasonably check other than Rest::accent() here, and since that's the only case that is known to be a problem, I think it's a mistake to try to do anything else.

For MuseScore 4, we could certainly consider adding an actual new property so we know if a note or rest is "slash" without having to guess from its other properties. But I'd like to see this fixed within the current framework first.

In reply to by Marc Sabatella

That said, probably the is no harm either in what you suggest, not actually checking accent but just voice > 1. I don't think anyone would likely add accent notation then make the rest fullsize, but it's certainly possible something might think to use voice 3 for some other purpose on top of the slash notation - like to represent an actual melody. And in such cases rests could still be offset, I guess.

Do you still have an unanswered question? Please log in first to post your question.