Rests shared by two voices
Hi,
By default, with the development version, when we have two voices resting at the same time, rest symbols are added for both voices:
MuseScore 1.3 shares rests, so symbols are not displayed twice:
Is this change deliberate? Is there any notation convention about this specific situation?
Thanks a lot.
| Attachment | Size |
|---|---|
| rests-two-voices.png | 7.77 KB |
| rests-shared.png | 7.17 KB |
Comments
Would be interesting to see what Gould says about this.
It's not that MuseScore 1.3 has some special code that detects opportunities to share rests. It never adjusts rests, period. Shared or not shared, rests in either voice display in the middle of the staff in 1.3, thus very often colliding with notes or rests of other durations in other voices. It only happens to "lucky" in the case where both voices have rests of the same length starting on the same beat, as instead of an ugly collision, you get an overlap that looks like it could have been on purpose. 2.0, on the other hand, detects the case of multiple voices and automatically adjusts rest position to avoid most collisions - including the case where both voices happen to have a rest of the same length on the same beat.
Whether it is "correct" to share rests where possible is somewhat subjective and situation dependent. It is normally OK in piano or guitar music where it's a single person reading both lines. More questionable in other cases.
There are a number of places where it might make sense for MuseScore to overrule its usualy automatc-rest-adjustment and place rests at the default location even though multiple voices are present. However, even detecting those cases is pretty much beyond the scope of the layout algorithm. It probably would be possible to detect this specific case, but there would still be others where manual adjustment will be needed (or at least desirable).
Bottom line: worth filing to issue tracker. Could be feature request, minor bug, or even task. FWIW, neither Finale nor Sibelius combines these rests.
In reply to It's not that MuseScore 1.3 by Marc Sabatella
Turns out it's not so easy to detect the opportunities if we want to do it *right*. It's simple to merge the rests if we see there are two rests of same duration in same segment on same staff. But this is actually only correct if there is no third or fourth voice - not just on that segment, but anywhere in the measure. That information is not easily available at the time we are laying out the rest.
In reply to Turns out it's not so easy to by Marc Sabatella
For what it is worth, since working with 2.0 over the last 5 weeks as compared with 1.3, when I am doing scores with two voices, I routinely 'combine' rests of the same duration for both voices whenever they occur, without regard to anything else in the measure.
My procedure has been to select all the rests for one voice, and make them invisible. Then select the rests for the other voice, and adjust their position (usually by 2.0 spaces up or down, depending which voice you are picking). I have only been working with two voices at a time. While this is certainly very flexible, as you have complete control, it takes a lot of manual effort and time. It would be nice if this could be a layout function you could turn on or off, or a way to do this more quickly. Again, my premise is that with multiple voices on the same staff, you share the rest whenever possible -- it just makes for a cleaner, more readable score.
In reply to Multi-voice rest positioning adjustment by Jim Newby
What instruments are you writing for? In any case, see my comments above, - it *not* always the correct thing to do, and unfortunately, automatically detecting when there are legitimate opportunities and when there are not would be more difficult than it's worth I think.
In reply to What instruments are you by Marc Sabatella
The instruments I am using are almost exclusively voices (I am copying music for singing).
In reply to Multi-voice rest positioning adjustment by Jim Newby
Jim Newby - You make a good point about the time-consuming nature of 'combining' rests to have them appear as they did in 1.3 by default.
Personally, my only objection to the 1.3 default was that I dislike, as a matter of principle, having congruent items sitting atop one another unless there's a handy way to cycle through them layer by layer in order to see and/or select a specific element that's otherwise hidden because it's not on top.
I remember using graphics programs in years past that did offer that functionality (including 'send to back' and 'bring to front') - but MuseScore does not, obviously; even the usage of a term like 'layer' is fraught with potential problems and confusion because its meaning isn't standardized.
In reply to You make a good point about by [DELETED] 448831
Let me remind people that, as I explained a while back, 1.3 did not have some sort of magic rest-combining algorithm. It simply never adjusted the vertical position of rests, period. So when your rests are *not* shared - which probably make up the majority of rests in a multiple-voice context overall - your rests sat centered on the staff overlapping the contents of other voices and had to be adjusted one by one. So that was the price you paid: no need to adjusted shared rests, but you did need to adjust non-shared rests.
Now, there is a "TODO" comment in the code to make the amount of adjustment for rests a style parameter. A complicating factor is that different rest durations may need different amounts of adjustment, and the amount of downward adjustment might be different from the amount or upward adjustment. But if we did implement some sort of style setting, it would certainly be possible to offer "0" as a choice. That would return you to the (bad, IMHO) old days of 1.3 where you needed to adjust your non-shared rests, but if you are working on a piece of music that happens to have mostly shared rests (I guess this would tend to be the case for hymns), it could be advantageous.
The real trick here would be deciding how to offer the style setting given my comments about different adjustments needed for different rests and different directions. It would probably look very messy. Probably not a thing to offer via the regular style dialog, but through some sort of "advanced settings" facility that every once in a while we talk about maybe someday adding.
In reply to Let me remind people that, as by Marc Sabatella
As a piece of information to resurrect discussion on combined (or perhaps coincident) rests, I quote the relevant passage from page 528 of Gould's 'Behind Bars':
"Separately stemmed parts share rests wherever possible."
Other layout books I have all say the same thing. On page 12 of 'Preparing Traditional Music Manuscript' Second Edition by Michael Mohn:
"Do not double rests in split-stem parts if the rhythm is obvious."
To decrease much manual work and effort, when there are two (or more) voices that share a staff, and both (or all) voices have identical rests, those rests should be 'shared' on top of one another in the center of the staff. It does bring up the challenge (which exists with rests, notes, etc.) of how to pick (select) an individual note or rest from a particular voice when two notes or rests are the same in more than one voice. When that occurs, perhaps there should be a dialog upon clicking an element to allow you to select which voice you want, or perhaps in some cases you may want all voices, such as needing to revise the pitch of a note.
I vote highly that making identical rests in multiple voices on a staff should, by default, be shared.
In reply to As a piece of information to by Jim Newby
The problem is context. Gould has separate sections with different recommendations for different types of music (eg, vocal music versus orchestral scores versus divisi parts versus piano music versus guitar music). And there are qualifiers like "where possible" and "if the rhythm is obvious". It's by no means as straightforward a determination as might appear from the simple cases one might immediately think of.
Still, as I said in http://musescore.org/en/node/41646, maybe it is better to do this by default and let people separate them manually in the cases where it ends up *not* being proper to combine the rests. The code I posted elsewhere does this, and I haven't ruled out the possibility.
As for how to select an object when they overlap, just select or double click whichever selects by default, nudge it out of the way (one click of cursor key), then select the other, then you can reset the position fo the first when one (Ctrl+R). Ends up being no more work than responding to a dialog, really. Especially given that in many cases, such as separating overlapping rests, you'll end up needing to move them both anyhow.
In reply to The problem is context. by Marc Sabatella
Marc, are you saying that the default behaviour in 1.3 of combining rests was wrong for many contexts? I didn't see many, if any, people complain that it shouldn't.
Which is more difficult: move rests to centered positions if a rest in one voice was made invisible, or combine them where they are the same as 1.3 did?
In reply to Marc, are you saying that the by schepers
Once again, 1.3 *did not have any magic rest-combining algorithm*. It did not "combine them when they are the same" at all. it simply never under any circumstances adjusted vertical position of rests, not ever. So a quarter rest in voice 1 would happily collide with a note or rest of a different duration in voice 2. It was a big mess that reqwuired hundreds of adjustments for even the simplest mutli-voice.
Only in the very special case where both voices happened to both have rests, *and* those rests furthermore happened to both be of the same duration, *and* the rest of the measure was such that it was notationally acceptable for the rests to be combined, did it just so happen that this failure to ever vertically adjust rests would accidentally happen do what you wanted in this particvular instance.
The 2.0 behavior, where rests in multi-vocie music are automatically adjusted, is much, much, better for the majority of music. There is virtually no adjustment of rests required any more, *except* in the very special case where both voices happen to have rests *and* both rests happen to be the same duration *and* the context is such that it happens to be notationally acceptable to combine them. In these exceptional cases only - the cases where 1.3 happened to produce what you wanted purely by accident (because it never ever adjusted rests period) - you now have to manually adjust the rests. it just so happens that choral music runs into these cases more often than other types of music.
Now, the idea of automatically centering a rest if the content of the other voice is invisible is good. It's still tricker than you might think because we have to consider voices 3 & 4 and the effect they could have on this. But I do like the idea that we already have a pretty simple and obvious mechanism that could be used to override the default. Something like this: if voice = 1, *and* there exists a hidden rest of the same duration in some other voice(s) at that time position, *and* there exists nothing else in any other voice at that time position, then we skip the vertical adjustment. I could be happy implementing this, as the need to manually hide the vocie 2 rests means we wouldn't break any of the cases where it is *not* proper to combine the rests.
In reply to Once again, 1.3 *did not have by Marc Sabatella
I'm glad you like the idea of the invisible rest concept. With the work I do in choral, much of the time I will need to combine rests or make one invisible and adjust the position of the other. I do not delete voice 2-4 rests, but rather just make them invisible. And combining the rests takes more work especially if you don't constrain-drag so they perfectly overlap. Having the code auto-adjust rests if it sees the opportunity would be beneficial.
In reply to I'm glad you like the idea of by schepers
BTW, dragging will never be the fastest way to adjust manually. Much better to simply ctrl+arrow twice. Or multi-select and use Inspector.
But if the algorithm I suggest above seems acceptable, I will probably give it a shot. I already have most of it written; I just need to add the check for visibility. And with that check added, there is no worry about messing things up for piano or guitar music.
In reply to BTW, dragging will never be by Marc Sabatella
Again, see my comment posted earlier below, I don't see the need for the check for visibility. I think the rests need to be combined as well for piano music, and I can't speak directly about guitar, but I would think that should also be the same case.
Perhaps for piano you are concerned about a voice that moves from treble to bass clef and back. But the key thing is the rests being on the same staff. I can not think of any example where two rests of the same duration at the same time should appear on the same staff when there are no notes in any voice on that staff at the same time. Show my any example where that is not the case.
In reply to Again, see my comment posted by Jim Newby
Since you mention Gould, see the example at the bottom of page 36, also the first example of page 529. See also the discussion on p. 312-3, even though she doesn't show a specific example.
As for real world printed music, I am not sure what you have access to, but if you have the Norton Anthology of Western Music, see the Scriabin "Vers la flamme", for example measure 96. Or if you have the Bach WTC, you can find examples in almost every single fugue. For example, see the 4th-to-last bar of the C minor fugue, or all throughout the first page of the C# minor (in the Schirmer edition, anyhow), or bar 9 of the D major, etc. You basically won't find examples where they *do* combine rests in that music. If you are writing contrapuntally, it is usually considered important to show all voices explicitly.
Which still isn't to say I am *completely* opposed to doing some sort of automatic combining. But as you can see, it really is not a simple matter *at all*.
In reply to Since you mention Gould, see by Marc Sabatella
Point taken on the 'strict contrapuntal' examples, etc. Perhaps this can be a characteristic of the instrument. Or is it the difference between instruments and voices? I have, as of yet, not seen that you can actually within MuseScore add an instrument to share a staff with another instrument. It seems to me you can only split an instrument into voices to get multiple lines on the same staff. In any case, I think it may be a characteristic of the instrument, namely do I want this instrument (and its voices) to share rests with other instruments (or voices) that occupy the same staff? Such a setting for an instrument, that could be turned on or off, even after entering a score, would make the process easy to control. Then, for the 'strict contrapuntal' writing, you could say that the instruments (and voices) do not share rests. I would think that the default choice would be that most instruments would share rests if they could.
As a musician for over 50 years, it is a matter of what is easiest to read. And that does not change depending on instrument. That is a matter of what the eye sees, where it has to look, and what the brain needs to interpret.
In reply to Point taken on the 'strict by Jim Newby
In that other thread, I suggested this could eventually be made a staff setting, as you might well want it one way for a vocal staff and another for an isntrumental staff.
As for the default, I don't know that we really have any basic for saying the "non-contrapuntal vocal" style of mutliple voice writing is more common that truly contrapuntal writing. As I have obsevred before, really, vocal music is the exception in that it often uses multiple voices even for rhythmically homophonic passages. That's why you see this happen all the time in vocal music. But it is correspondingly rare in instrumental music, because if the rhythms are identical for a passage, you simply would not use multiple voices in the first place.
And while I might agree that "what is easiest to read" doesn't change depending on instrument, I would say that's not really the point. it changes dependinding on *context*. In the context of mostly homophonic music - regardless of instrument -it is easiest to read if rests are merged. But in the case of more polyphonic music - again regardless of instrument - it is easier to read if each voice is complete unto itself. This isn't a difference between instruments; it's a difference in the nature of the music itself. It's just that vocal music tends to be the only music where anyone would consider using multiple voices even though the music is *not* polyphonic.
In reply to Point taken on the 'strict by Jim Newby
Another observation, for anyone not bored to death by now :-):
One of my principles in improving the layout algorithms for 2.0 has been, provide predictable defaults that cover the majority of cases, and easy & reliable ways of overriding them.
For me, an algorithm that "sometimes" merges rests but doesn't at other times fails the predictability portion of this principle. So I'm skeptical of any algorithm that attempts to sort this out automatically. Which is why I haven't already submitted a PR on my algorithm to merge rests "if there exist matching rests in voices 1 & 2 and no other elements in any other voice" - I fear it will seem random, and still will be the wrong answer a good percentage of the time. Plus, in the cases where this algorithm gets the answer wrong and merges rests it shouldn't (because the nature of the music demanded independent voices), there is no obvious recourse except to offset *both* the rests manually, and hoep you do it by the right amount to match the automatically-offset rests in other places where the rests could not be merged. It's fiddling and fragile - won't necessarily look good if we later change the default amount of offset, which is entirely possible.
On the other hand, if I let the algorithm continue to be simple as it is now - voices are offset if there are multiple voices in the measure, period - then we nail predictability. And if I make it so hiding the voice two rest automatically moves the voice 1 rest back into the center position, I've made it much easier and more reliable to override the default. One press of the "V" key and you get perfect positioning.
So right now, I'm leaning toward going that way. Keeping the default simple and predictable and useful for a large number of real world cases, but providing an easy and reliable one-click ("V") solution to override the default for the cases where you want them merged.
In reply to Once again, 1.3 *did not have by Marc Sabatella
Having sparked renewed conversation on this matter, and being a programmer myself, I am curious about an example of when it is not proper to combine rests when the other two situations you cite occur. I can not think of any, and if there are some, I would think it is a small percentage of the time. The process of hiding rests manually is very time consuming. I went through this process once I started using 2.0 on several scores, and it is very tedious -- namely selecting many rests, making them invisible, then going back and selecting the remaining visible rests and adjusting their vertical position. I appreciate the suggestion of putting the remaining visible rest back to the center of the staff once another rest has been hidden, but there is still much manual work involved. Since the programming logic needs to evaluate that there are rests of the same duration in all voices on a staff (and I say all here because I think that is the only situation that you can deal with), it is the same equivalent programming work to stop the vertical positioning adjustment of those rests in all voices as it would be to check that all the rests but one in a single voice have been hidden.
I suggest that the time when (if there indeed are any) the rests need to be separated is minimal and that should be when a person needs to manually make that adjustment. The notation software should default to making these rests shared. If you believe that is not the case, I would love to see a real world example to the contrary.
In reply to Having sparked renewed by Jim Newby
Actually, the conversation was restarted and continued in the other thread I referenced - do see that for more context.
Basically, it is most proper to combine rests only when there are exactly two voices and their rhythms are substantially similar. If there are more than two voices involved, it's not likely to be proper to combine rests in any given two of them. And even when only two voices are involved, it's not necessarily a great idea to combine rests if the rhythms are substantially different, especially if two musicians are reading off the same part (eg, orchestral divisi).
This is presumably why the major notation programs (Finale & Sibelius) do it the same way we do.
In reply to Actually, the conversation by Marc Sabatella
About visibility and rests, I would consider the current behavior of having a rest in voice 1 and a "gap" in voice 2, and having the rest not in the center of the staff a bug.
Regarding the visibility itself, it will be hard to revert... the invisible rest will be hidden below the other one. So I'm not sure it's a good idea.
In reply to About visibility and rests, by [DELETED] 5
Me too. Deleting the voice 2 rests should make the voice 1 rests center
In reply to About visibility and rests, by [DELETED] 5
I don't know how difficult it is to detect the gap in voices>1 compared to invisible rests in voices>1, but I can see adding a check for this for those who choose to delete the rests In other voices.
Regarding your comment "the invisible rest will be hidden below the other one", this is not true. Here's what it would look like:
The bottom rest was made invisible, so the top one dropped to take the center position. There is no overlap and it certainly seems like the better solution that deleting rests and making holes in voices. Regardless, even if one rest overlapped the other, that behavior is no different from MS 1.x or when two note heads overlap and we've had to learn to deal with that.
In reply to About visibility and rests, by [DELETED] 5
The case of a deleted rest woud look no different to the layout routines than the case where another voice has no note or rest because something on a previous beat is carried over. That is, in lasconic's example, if the quarter note on beat 3 of voice 2 were replaced by a half note. There would be nothing in voice 2 on beat 4, but it would be wrong not to center the voice 1 rest.
The current algorithm for deciding when to offset voices is exceedingly simple: we check the hasVoices flag for the measure/staff. That flag is set and cleared while adding and removing notes while editing, so it's "free" to check it during layout.
Trying to actually detect "holes" in another voice would be impossible except by a brute force examination of the contents of all voices for the measure each and every time we go to lay out a rest.
That's one reason why checking for the existence of an invisible rest in another voice appeals to me. We only have to loop through the voices of that one segment rather than the entire measure, so it can be done efficiently.
Thanks for your comments.
All I've found about notation convention for this case is the following (Gerou and Lusk, Essential Dictionary of Music Notation, 1996, p. 115): "In other situations, if both parts were resting, one rest in normal position could serve for both."
Perhaps I digress here, but while on the topic of shared rests, etc., I admit it is more flexible, while perhaps more manual work for adjusting, when rests in two voices are vertically separate. It makes it easy to pick them and hide/unhide them or move them.
But my digression is this. On a similar vein, when two elements (in my case, it is usually voices) occupy the same place, it is very hard to pick one and do something to it. Usually it is a note (same pitch and duration) common to 2 voices. I often have to pick one or the other, perhaps to add an articulation, start a slur, etc. I find that to do this reliably, I usually just click on the note (which selects voice 1 or 2, relatively at random), and then move the pitch of the note up or down with arrow keys, at which point I can see the two voices separately, do what I want to each voice separately, and then when I am done, I then move the pitch of the note back to where it is supposed to be.
Is there a way, or could a way be planned, that when clicking on a element where multiple voices share elements at the same position, that I could pick which voice I want to select? If there is an easy way to do this, I have not yet stumbled upon it.
In reply to Selection of elements that occupy the same position by Jim Newby
My own workaround is the same as yours at present, but your comment goes precisely to what I was saying about 'layers' of congruent elements - viz., the inability to click to select the desired one or to click through them successively until the desired one is reached ... or to 'send to back' or 'bring to front'.
In other words, I don't think you digressed at all. Perhaps you missed my earlier comment that I specifically addressed to you.
I can't seem to find a general pattern for these examples (maybe it was just down to the operator). I don't understand why 1 and 2 (both from the same score) are different - I found a few of these instances.
Anyway, as Marc says, it could depend on the context. I don't know what the best way to solve this would be, but so far, I would be inclined to let the user make manual adjustments.
We have added the capability discussed where hiding a voice 2 rest automatically causes a voice 1 rest to return to the center. It is not out of the question that at some future date, we might make this fully automatic, perhaps controllable by a staff property, but for now, it should be a help for these cases - just a single keystroke to get the centered rests.
In reply to We have added the capability by Marc Sabatella
How about adding one(!) staff property: Adjust rests per voice? If off -> behave like v1.3 and simply don't adjust rests, if on -> use the new algorithm? As far as i can see this would us give the best of both worlds, wouldn't it? :-)
In reply to How about adding one(!) staff by pencoe
Not really, no. Even in music where voices can *sometimes* be shared because they happen to match, there would still often be cases where there is a rest in one voice but not th other, or rests of different length that cannot be shared. Not offseting the rests in these cases would be a huge step backwards. Having to manually adjust all those rests as one previously had to in 1.3 would be far more work than simply hiding the rests in voice 2 when you want to merge. Even if the music happens to be such that it would literally be all rests that could be merged - and hence one of the very rare cases where 1.3 was actually more efficient - you could still simply select all rests in voice 2 (right click one, Select / More / Same voice) and mark them all invisible at once.
In reply to Not really, no. Even in by Marc Sabatella
Works for me, only minor issue is the 'invisible' rests still clutter up the score (in MuseScore, not in the printout), but I guess that is pretty much unavoidable, as letting them fall into center position like the voice 1 rests would make it pretty hard to 'unhide' them again, if need be.
In reply to Works for me, only minor by Jojo-Schmitz
Right, so that was a conscious choice, based on lasconic's and scheper's comments earlier. You can of course set the option to hide invisible elements if they bother you.
In reply to Right, so that was a by Marc Sabatella
I've gotten used to ignoring "grey" elements even when they interfere a bit as I know they won't be in the final output. Thanks for the fix, Marc, and I'm _so_ glad this finally got merged!
I started another discussion .