First-voice rest not repostitioning after Second-voice hiding (non-equivalent duration)

• Oct 14, 2019 - 03:09

For anyone knowledgeable about such functionality: when two voices are employed,
if the lower-voice and upper-voice both share a time domain of rests, and the
lower-voice's rest is made invisible, the upper voice will, instead of being
at the top of the staff, relocate automatically into the standard position of
one-voice positioning, e.g.:


Yet, if the rests do not share the exact same duration, this no longer occurs, e.g.:


The question is, is this by design? If not known for sure, would it be a 'bad' implementation to still re-position the rest even though they're not equivalent in duration? Fwiw, it has been said that when voices are hidden, MS doesn't take into consideration many things such as stem direction. Why would this be any different?



My guess is the thinking is, if the durations don't match. there must be other notes or rests to make up the different and they will need to be offset. I'm sure whatever decision is made will be what you want sometimes, not what you want others, but given there haven't been complaints about this, I'm betting we're guessing right more often than not.

In reply to by Marc Sabatella

Not to push the concept further, but here's a scenario that's worth mentioning:

Say the user inserts notes in a few systems as Voice-2 without Voice-1 first. Then, on second thought, there isn't a need to add an above voice to what was inserted (but maybe a below voice in a different staff), so the user can select in bulk those measures and do an Exchange Voice 1-2. Now the user has whole rests in Voice-2 position and the previous input is nicely fitting in Voice-1.

With that in mind, if the user wants the Voice-1 rests to not be "above" but as if a regular Voice-1's centered rests, the user has the option of deleting each Voice-2 rest, but there's a catch. To illustrate, after the given scenario, inserting into Voice-2 to delete the rests, the user begins and presses delete. Bam. The user can't press "Right Arrow" to delete the next rest because selection will have lost its place since there's no voice-2 anymore after deletion.

So one possible alternative is to go through and press 'V' quickly through to make invisible the rests (which is what a person should usually do if only using one voice and not delete rests--it becomes an acquired habit). But that won't give the desired result (unless the notes are whole notes) since as already mentioned so far, the durations have to be equivalent, and the rests in Voice-2 are now whole notes. So then, either the user has to use the mouse, select the rests, delete them and continue this way (or do some Select Similar Elements with Voice/Staff filtering). Or even more absurd, each rest needs to be altered duration wise to fit the above voice, and then make them all invisible.

Now I'm not saying therefore the developers need to rush in and change the above behavior, but this scenario does seem to give a bit of a credence to allowing the resetting of rest-positions without necessarily needing equivalent durations of voices.

I wonder if there's any counter-argument to this observation?

In reply to by worldwideweary

One other note that's worth mentioning:

If first voice utilizes tuplets and second voice doesn't, rest(s) in second voice, even if they align visually with any rests in the first voice, will not re-align the first-voice rests in tuplets.

E.g., notice that the following rests are made invisible, yet they do not move the 32nd-rest in the tuplet of the first voice. The point here is that the user is forced to either delete the rests (as JoJo mentioned), even though a user might have been in the habit of never deleting rests but only making them invisible, or manually reset the first-voiced rest's vertical position in the inspector, or even a worse idea, make a bogus second-voiced hidden tuplet:


BTW, it seems in 3.5 that this is a non-issue. So for example, second voice quarter rest when made invisible will let an eighth rest in voice-two "drop-down" to center position now. Not sure that was explicitly declared in release notes, but whoever updated it, thanks!

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