Some rests in voice 1 don't get dragged down when rests in voice 2 are deleted
Reported version
3.2
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
Come from https://musescore.org/en/node/290732. Try re-create the sentence shown on the top of the screenshot, and you'll see the quaver rest doesn't raise automatically while the minim rest does.
Fix version
3.2.0
Comments
See #290454: Deleting rest in voice 2 may result in offset rest in voice 1 with zero offset indicated by inspector.
Do you have reason now to believe this is not a duplicate? If so, we need precise steps to reproduce this without deleting rests. Right now I can't see any sense in which these are different.
In reply to Do you have reason now to… by Marc Sabatella
This sure needs deleting, but it's not a duplicate as far as I can tell.
"I don't really get what #290454 mean because whether or not the rests in voice 2 are deleted, and wherever the rests in voice 1 are, the inspector suggests all rests are zero offset, I think this is at least consistent ... But via this #290735 I try to say that some notes come back to normal while other notes are still offset, and this is not a normal condition. ..."
-- from https://musescore.org/en/node/290732
If it's not a duplicate, then please provide precise step by step instructions to reproduce the whatever problem it is you are seeing that is not explained by #290454: Deleting rest in voice 2 may result in offset rest in voice 1 with zero offset indicated by inspector. That issue details, quite clearly, how the position of the voice 1 rest depends on the order in which you delete things in voice 2. If you have a case where the position differs from is described in those two scenarios, that's what we'd need the precise for.
As it is, I still can't imagine any possible sense in which this isn't exactly the same thing. Your image clearly shows two different measures with deleted voice 2 rests and voice 1 rests in different positions. It seems almost unfathomable to me this could be due to anything but the same thing described in the other issue. But again, if you believe so, please provide the precise steps so we can verify.
The Inspector has absolutely nothing to do with any of this. It is completely normal that rests show as zero offset if you have not manually moved them. The offset is offset from the default. So remove any concern about the Inspector from your thinking, and focus entirely on the step required to produce this behavior in a way that differs from the way described in the other issue.
In reply to If it's not a duplicate,… by Marc Sabatella
The steps are simple, re-create the top sentence in the screenshot and delete the rests in voice 2 in the last bar. You'll see the quaver rest in voice 1 go back to normal location, but with an exit and re-open, the quaver rest returns to -2.00 sp offset. So my report is on the "go back to normal location" part, not the "offset" part in #290454: Deleting rest in voice 2 may result in offset rest in voice 1 with zero offset indicated by inspector. The score attached in #290454 has the quaver rest in voice 1 offset, from the beginning to the end.
OK, I think I follow. I still suspect the underlying cause will turn out to be the same, but whatever fix is devised, it will be important to test both scenarios. Thanks for sticking with me!
In reply to OK, I think I follow. I… by Marc Sabatella
No problem, these two are indeed very similar. I'll keep track of whatever you've come up with.
So this is basically the same as #284481: Automatic placement of single rests in multiple voice areas, except you think that the rests in voice 1 shouldn't move back down when the voice 2 rests are deleted?
In reply to So this is basically the… by mattmcclinch
#284481: Automatic placement of single rests in multiple voice areas assumes the whole offset system is bugged -- when there're neither notes nor rests in other voices, those rests in voice 1 should be in the middle because they're shared by all voices. But here I assume the offset isn't bugged, instead this is the very normal condition (nevertheless I agree that the shared rests should be dragged down to their original place, but it's another issue which, as Mr. Sabatella points out in https://musescore.org/en/node/290454#comment-926883, is a bit late to fix, so I don't discuss it here and take the offset system for granted temporarily). What's abnormal is the rests which jump back into the original position, however they return to the offset position once the score is re-opened.
So you would prefer that we not fix #284481: Automatic placement of single rests in multiple voice areas, but rather fix one of the side effects instead?
Hold on, so if you agree that the shared rests should be dragged down, then you are agreeing that #284481: Automatic placement of single rests in multiple voice areas is the real issue that needs fixing.
In reply to So you would prefer that we… by mattmcclinch
At least fixing the side effect can beautify the original score layout by making it consistent. Even if we've fixed #284481: Automatic placement of single rests in multiple voice areas as it suggested at sometime future, if the consistency cannot be promised, who knows if the rests won't jump up and down irregularly then?
#284481: Automatic placement of single rests in multiple voice areas is indeed the ultimate goal, but if it cannot be realized in the near future why not have this one fixed? At least after this is fixed if you want to drag down the notes manually you can select them all and adjust the position simultaneously without considering every one of them whether it has a different offset.
Well then, as we fix #284481: Automatic placement of single rests in multiple voice areas we will be sure to see what happens after save and reload.
In reply to Well then, as we fix #284481… by mattmcclinch
If we can fix #284481: Automatic placement of single rests in multiple voice areas. :D I'd love to see that too.
In reply to Well then, as we fix #284481… by mattmcclinch
Well, congrats on the fix of #284481: Automatic placement of single rests in multiple voice areas! Didn't realize you're also a developer.
The fix of #284481: Automatic placement of single rests in multiple voice areas automatically fixes this.
Automatically closed -- issue fixed for 2 weeks with no activity.
Seems like the problem is reserved here in 3.2.3.
![批注 2019-07-11 151204.png]( "批注 2019-07-11 151204.png")
As always, you need to either attach a score or provide steps to reproduce from scratch. The only way I can achieve that result in 3.2.3 is by manually applying an offset to that one 16th rest.
Never mind, the note in voice 2 is an 8th, so the rest surely only applies to voice 1.