musecore 3.6 - percu stave : rythmic slash notation problem on voice 3 ?
Hello.
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 |
Comments
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 It is unfortunately a… by Marc Sabatella
I'll take care of it.
In reply to It is unfortunately a… by Marc Sabatella
Please see #308726: Voice 1 rests collide with voice 3 rhythm slashes (above the staff)
The fix disabled rest avoidance when there is any slash notation in place. If this is not desirable what is the way to go?
In reply to Please could you have a look… 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 See my comment in the PR… by Marc Sabatella
Ah well. I didn't noticed this one.
In reply to See my comment in the PR… by Marc Sabatella
So we have a regression? Better get it into the issue tracker then ;-)
In reply to So we have a regression?… by Jojo-Schmitz
It's been there a while already, see #318860: Rests in rhythmic slash notation not offset.
In reply to It's been there a while… by Marc Sabatella
Oops, I must have missed that, thanks
In reply to See my comment in the PR… 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 The original issue are… 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 No, I said skip that code if… by Marc Sabatella
I have investigated the problem and in my opinion the regression is caused by #294085: All elements set to normal position if all rests in voices other than voice 1 are deleted
If this is really the case, I should better rollback the "fix" for #308726: Voice 1 rests collide with voice 3 rhythm slashes (above the staff)
In reply to I have investigated the… 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 https://github.com/musescore/MuseScore/pull/6757/commits/9ac4f8cd5f34ce… - 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 Except that was actually a… 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 I tried your suggestion and… 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 Well, we (actually "I") made… 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.
In reply to That said, probably the is… by Marc Sabatella
Thank you very much for the detailed explanation. Very appreciated.
I will prepare a PR that checks voice > 1.
In reply to Thank you very much for the… by tobik
https://github.com/musescore/MuseScore/pull/7952
In reply to https://github.com/musescore… by tobik
and https://github.com/musescore/MuseScore/pull/8017 for master