Program allows to delete rests in voices 2, 3 and 4 and creates confusion

• Oct 31, 2012 - 13:10
S4 - Minor
by design

To reproduce:

1) Create new score, violin, enter four notes in voice 2
2) Delete the last three notes you entered. Result
3) Now delete the three rests. You'd say: "Impossible", but hey, they can be deleted. Result

Your score is now corrupt. Select the remaining note and try to make it a minim or a semibreve.

The variations on this are endless. Instead of deleting the last three notes in step 2), try deleting the first three and then the resulting rests.

I haven't tried 2.0 for a while, so perhaps it's not an issue there.

Attachment Size
delete-rest-1.png 3.12 KB
delete-rest-2.png 2.73 KB


This doesn't seem to affect 2.0. I can change the voice 2 note to anything I want, unlike 1.2.

Why do you say the score is corrupt, because you can't change the note duration? In 1.2, if you do "exchange voice 1-2" on the measure twice, the rests come back for voice 2 and you can modify the quarter note again.

Title Program allows to delete rests in voices 2, 3 and 4 and creates corruption (Musescore 1.2) Program allows to delete rests in voices 2, 3 and 4 and creates confusion
Status (old) fixed active

I called it corruption, since it causes corruption. The program gets confused and many weird and wonderful things happen, especially when you delete rests in two subsequent bars. I even got a crash, but now I can't reproduce the steps.

I'm a bit surprised how quickly an attempt is made to swipe a valid bug under the carpet. I downloaded a nightly build and can confirm that you can still delete rests where you shouldn't be able to. Unlike 1.2 it doesn't cause any corruption, instead it now causes confusion. Or how would you play these bars? Note, this is 4/4 time, not 3/4, not 2/4 not 1/4:

Attachment Size
delete-rest-3.png 4.63 KB

I gave my reasons for marking it fixed... nothing to do with 'swipe under the carpet'.
Being able to detele rests in voices other than the first is by design.
I'll leave it to you or the developers to mark this issue as such to avoid being accused again...

The ability to delete rests in voices other than 1 is a feature of MS. While it can cause confusion, its no less confusing than simply using voices in a multi-voice piece. You realize where and why rests can be deleted after a fashion. If they couldn't be deleted then the user is left to make sure they are _all_ made invisible and not overlapping valid note, esp in 1.2, and then other complaints will come in regarding all the extra rests.

Regarding corruption, I don't see it. Show how the score is corrupted before claiming it is.

Status (old) active closed

Here's how I'd justify the ability the ability to delete rests in voices other than 1: you need this if you wish to change your mind and remove the extra voices entirely and get back to a single voice only. So it's definitely intentional / correct / necessary that you can delete the contents of voices other than 1. Yes, that means it is the user's responsibility to make sure the contents of voices other than one are musically meaningful.

I suppose one could suggest an alternate implementation where you can't delete these rests individually, but where once you delete all notes, no default whole rest is displayed. That seems a good idea and could be worth suggesting as an enhancement request, but again, the current behavior where you can delete rests is not a bug - only the side effects of this on 1.2 constitute a bug as far as I can see.

As for those side effects, yes, I would agree the state you reach in 1.2 is a corrupt one, in that it becomes impossible to add notes to that voice in that measure. Subjectively speaking, I would also agree that it's not as "bad" a corruption as some, in that it affects only that one measure in that one staff, whereas some corruptions affect all staves, and indeed all measure after the point of corruption. And it's easier to recover from, in that swapping voices fixes the problem. So one could possibly quibble the severity of the issue, I suppose. But the nature of the corruption seems clear to me: you can no longer add notes to that voice in that measure.

Anyhow since the bad effect is already fixed for 2.0, and since the basic ability of deleting rests is intentional / good / necessary, I think closing the issue is proper. But if someone wanted to propose an alternate behavior for MuseScore that would allow you to remove the contents of voice 2 that didn't allow you to create underfull voices - along the lines of my suggestion that default rests not be displayed, but more fully thought out - that does seem a worthwhile suggestion.

On the other hand, given that existing scores *do* allow "holes" in voices other than one - and I believe MusicXML does as well - I'm not sure it's really worth implementing such a suggestion. But certainly worth investigating at some point.

Status (old) closed active

Well, perhaps some other people have an opinion here:

I thought it was like this:
If you delete a note, you get a rest. You can never delete a rest, unless it's in voice 2, 3 or 4 and the rest you're removing is the only rest that is contained in this bar in this voice.

If you don't like to see/show/print a rest, you can make it hidden.

@schepers: I'll see whether I can find some hard facts to justify calling it "corruption".

@Marc Sabatella: You got in there first with your comment ;-)

My suggestion is:
Do not allow deletion of rests, unless it's the last rest in the voice. This is to allow you to change your mind an remove the voice altogether, or go back to single voice.


You asked for corruption, well, here it is.

The problem lies in the internals of MuseScore. Each chord/rest has a tick position and a length. The length of the chords/rests in a bar need to add up, otherwise havoc is created. But deleting rests, creates exactly this. That's what Marc refers to as "underful voices".

Open the attached score. Delete the three rests in bar 1. Now change the remaining note to a whole note. Observe the mess created in bar two.

Please let me know if you need more proof to justify the use of the word "corruption".

Attachment Size
Untitled.mscz 1.53 KB

Yes, it has interesting side effects, but this is not corruption (yet). That term is reserved for when scores become damaged, bars get mixed up. Save this one and reload it and there is no corruption that I can see.

Look, this is about 1.2, and there won't be any fixes for 1.2, so let's not waste our time here.
I have given you a simple and reproducible example of some real corruption. The score gets damaged, as the ticks in the bar don't add up any more. A subsequent operation causes destruction:

In the picture you can see that the program tried to put 3/4 of the whole note into the next bar, since the first bar was underful. If you don't accept this as corruption, then I seriously ask myself why you are defending something that is obviously broken. Anyway, as I said, this is 1.2.

2.0 doesn't have the corruption issue, I still think, what's going on is bad.

Attachment Size
delete-rest-4.png 3.78 KB

Well, you can "seriously ask yourself why" but I won't because this is not causing corruption. While it is stealing from the next bar, things still add up afterwards in both measures. Do you understand how people here use the word corruption?

I don't think there is a single definition of "corruption" that everyone would agree on. As I noted previously, it creates a state where operations that should have a given effect (trying to add a note to a measure) do not have that effect - they appear to add the note to the next measure. That's some kind of corruption in my book, even though it is possible to recover from that corruption. Again, one can quibble if it's as bad of a corruption as other types, but it's moot, since this is already fixed.

So instead, I'd suggest focus on the behavior itself - the ability to delete rests. *Currently*, this behavior is as intended, because it provides the only way of removing the contents of a voice. So it's not a bug, it's a feature - it's the only method of achieving the goal of removing the contents of a voice. We can't remove this feature unless we replace it with a different feature that also allows one to achieve this goal. So what I see here is a feature request - the addition of a brand new feature that allows one to eliminate the contents of a voice but does not allow deletion of individual rests. And then, presumably, the addition of this new feature would then allow the current feature to be retired.

It's an open question in my mind as to whether this new feature would be a better or worse way of achieving the goal than the current feature. As I stated previously, the current feature has the advantage of working with existing scores and also (as far as I understand it, which is not very well) mapping naturally to/from MusicXML. Right now, I don't really any particular advantage to the proposed new feature. I mean, it clearly would achieve the goal as well as the current feature, so it wouldn't be harmful that I can see - except in as much as it might break compatibility with older scores and/or with MusicXML. So if we are to take that risk, there had better be some corresponding benefit - evidence that in fact this could be implemented *without* breaking compatibility. Otherwise, we risk breaking compatibility (and spending unnecessary effort in doing so) for no gain.

So my question is, what is the gain? What is the advantage of replacing the existing feature with the proposed new feature, and can we demonstrate it is worth the risk?

Status (old) active by design

The ability to delete rests in voices 2,3 and 4 is there to provide clarity for those of us working with polyphonic keyboard music. Voices very often switch from one stave to the other and having dozens of superfluous rests around make the end result confusing.

You will also find that guitarists appreciate this facility as they are working with multiple voices on a single stave.

This does mean that the MuseScore user has to develop a certain discipline about the way (s)he creates scores, in that if you wish to delete rests from a voice then there must be enough information in one of the other voices so that it makes rhythmic sense, but then musicianship is all about having a disciplined approach.

If you don't like it then there is nothing to stop you forking a repo and coding a version with this facility for your own personal use. It is counterproductive, however, to inflict it on the majority of users who prefer the behaviour the way it is, which is why it has been coded that way.

But here again, I would claim the current feature (the ability to delete rests) is but one possible way to achieve the goal (printed music that does not show the rests). The other, of course, is to simply mark the rests invisible. And that's no harder in 2.0 than deleting - a single keystroke either way. So I'd still say it comes down to two different ways of achieving the same goals. Hiding a rest is perhaps less ideal in some cases because it may look more cluttered on screen, although that's also less of an issue in 2.0 than 1.2 because of the automatic vertical offsets.

So I see now *four* advantages for the current method of achieving these goals:

1) familiar to existing users
2) compatibility with existing scores
3) compatibility with MusicXML
4) somewhat less cluttered on screen than hiding rests in cases where you want the voice to appear underfull

So far, I haven't seen a single advantage posted to the other approach, but I'm open to the possibility there might be some. The one I can see myself is consistency. The only difference between voice 1 and other voices would be that voice one displays a default whole rest when empty, whereas other voices would simply display nothing. Consistency is an advantage to the user, and it would likely be simpler in the code - except that we'd need special casing to try to handle existing scores and MusicXML.

Perhaps when deleting a rest it should mark it invisible instead of deleting. The rest should be automatically placed out of the way so it doesn't interfere visually with the music. This is about the only other way I can see this working, but having many grey rests cluttering up the measures will/could be visually distracting. Disabling "show invisibles" is one answer but I find I always turn it back on so it ends up being left on.

Just for clarity, I work this way all the time. When I need a note in voice 2 or 3 in the middle of a measure, I will hide the rests for those voices and position them out of the way (above/below the other notes). This way I can always add/delete other notes to the other voices as the rests still exist. I wasn't aware until recently of how to get the rests back for these voices.

Boy, we're already at comment #19 here. Well, the thread started with the observation that deleting rests causes corruption in 1.2. Now that we are looking at 2.0 where no corruption is caused any more, it's a different story.

I appreciate what the ChurchOrganist said. If deleting those rests is desired and people have discipline so their score doesn't get confused, then I have no problem with leaving the behaviour as it is.

P.S.: to Marc:
Generally, I think the behaviour of all voices should be the same, so deleting a note gives a rest, deleting a rest is not possible, with one exception: Deleting a rest that fills the whole measure in voices 2, 3, 4 to remove this voice altogether. I don't quite follow your comment about removing features. No one wants to remove the feature of deleting rests in voices 2, 3, 4. My suggestion was merely to make this feature more restrictive: Only allow it if that removes all content of the voice in the bar.

Yes, but some consider it a feature that you can remove rests even when other notes are still behind. It's an alternative to hiding rests as a way of deliberately creating music that doesn't account for all beats in a measure in some voice, which *is* a musically valid thing to want to do in some cases. So, the feature you are proposing removing is the ability to delete *individual* rests within a secondary voice. Or, if you prefer, you are proposing taking an existing feature and limiting its usefulness, which is really just another way of saying the same thing. Either way, you are proposing that something that currently works and is used to good effect by existing users should no longer work.

I'd be OK with requiring people to hide rests rather than delete them - it's what I do, anyhow. But I am still nervous about the compatibility issues. And in any case, I still wonder, what is the *advantage* of this removing/limiting this useful feature? Yes, there is the advantage of consistency, but I don't think it's enough to outweigh the disadvantages that have already been laid out - requiring users to change their behavior, potential compatibility issues with existing scores and with MuisicXML, and a more cluttered on screen appearance it your score uses a lot of these rests. There had better be some *other* advantage aside from consistency in order to convince me the advantages outweigh the disadvantages. Again, I'm open to the possibility, but I'm becoming increasingly skeptical.