Deleting rest in voice 2 may result in offset rest in voice 1 with zero offset indicated by inspector
Deleting a rest in voice 2 that coincides with a rest in voice 1 may result in the voice 1 being visibly displaced but with the inspector reporting zero offset. See attached example. The result depends on the order in which rests in voice 2 are deleted.
A list of actions to reproduce is:
-
Create a single stave with time signature = 4/4.
-
In bar 1 enter crotchet, quaver rest, minim as voice 1
-
In bar 1 enter crotchet on beat one as voice 2. Result: bar is filled with crotchet rest + minim rest in voice 2 and the quaver rest in voice 1 is displaced upwards.
-
Select the crotchet rest in voice 2 and hit 4 to replace it with two quaver rests. Result: Voice 2 has crotchet, 2 quaver rests,
-
Delete 1st quaver rest in voice 2. Then delete remaining rests in voice 2. Result: Quaver rest in voice 1 returns to non-displaced location. This is expected behaviour.
BUT if instead of 5
- Delete 2nd quaver rest in voice 2, then delete remaining rests in voice 2. Result: Quaver rest in voice 1 remains displaced upwards. Looking at the voice 1 rest in the inspector shows that the Y offset is zero, but looking at the score, its offset is obviously not zero.
| Attachment | Size |
|---|---|
| Offset rests.mscz | 4.84 KB |
Comments
This is basically the same as #284481: Automatic placement of single rests in multiple voice areas. I should point out that the word "offset" refers to manual adjustments made by the user after any automatic (dis)placement has been applied by the software, so the inspector is actually showing the correct Y offset.
In reply to This is basically the same… by mattmcclinch
Looks like #284481: Automatic placement of single rests in multiple voice areas suggests the rests be dragged down to non-offset location, but #290454: Deleting rest in voice 2 may result in offset rest in voice 1 with zero offset indicated by inspector complains that the offset rests don't show its offset-ness in the inspector.
Right, and my point is that the values shown in the inspector are correct. It is not the inspector's job to tell us that the rests have been displaced.
In reply to Right, and my point is that… by mattmcclinch
Personally I second both voices: the shared rests should indeed be dragged down to normal location, and whenever a rest is displaced, whatever the reason, the inspector should tell the user about it.
That would have been a valid design, but it might be a bit late to change that design - it would create compatibility problems. Maybe if/when we change the algorithm to actually be smart about how much offset to apply, to actually avoid content in other voices rather than just guessing how far might be good to move, that would be a good time to change how the offset is represented.
In reply to That would have been a valid… by Marc Sabatella
Good to know that.
Fixed as #284481: Automatic placement of single rests in multiple voice areas is fixed.
Automatically closed -- issue fixed for 2 weeks with no activity.