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

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.

There won't be fixes for 1.2, so you'd better check with 2.0

as per schepers:
no crash nor corruption -> not critical
not in 2.0 -> fixed

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.

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.

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.

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?

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.

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.