Request new mode or command that allows rests to be re-pitched

• Apr 1, 2016 - 02:49
Type
Functional
Severity
S5 - Suggestion
Status
active
Project

As reported at https://musescore.org/en/node/101031#comment-468656 :

The user wanted to lay down the rhythm using rests first, then use the piano keyboard to repitch the unassigned rests. Although the repitch mode button right next to the Note Input icon works on notes already existing in a bar, it does not allow you to change a rest to a note.


Comments

This is by designed. You aren't supposed to enter rests first then turn them into notes - you are suppsoed to enter *notes*, then turn them into different notes. It's a convenient time saver that the function skips rests, because in the normal use case, you would want rests to remain rests.

I suppose someone could write a plugin to convert rests to ntoes or something, but that's not the purpsoe of repitch mode.

Why not? I always thought of rests as not something entirely different from a note—they're just a note of silence (or a note with a pitch of 0). So if you're in repitch mode and you don't want to change the pitch of a rest, press 0 when you come to it. But I would not expect rests to be excluded from being re-pitched with all the other notes.

Title Rests can't be re-pitched Request for new mode that allows rests to be re-pitched

Remember, the intended use for repitch mode is to take an existing melody and change the pitch of notes within it, such as to allow you to quickly create a harmony part. In this use case, you'd want rests skipped - you would normally harmonize only the melody notes. It's a nice time-saving optimization that rests are skipped, since you would virtually *never* want to change a rest to a note in this case. Just like it's a nice optimziation that lyric entry skips rests. In ormal use, this is a greta time saver. I don't think we should penalize the majority of users just because one person might want to co-opt repitch mode to do something entirely different from what it was intended to do. Especially since the solution is trivially simple - don't use rests as placeholders, use notes.

As a brand new feature that allows one to use rests as placeholders then convert them to notes, sure, I guess I can see this as a valid feature, as long as there is no way a normal user using the normal repitch mdoe would ever be inconvenienced by it. Again, in the intended use case, rests are *supposed* to be skipped, allowing you to focus on just the notes.

Title Request for new mode that allows rests to be re-pitched Request for repitch mode to include rests, or new mode that allows rests to be re-pitched

I understand your "intended use case" differs from the other guy's, but I'm not convinced it's the overriding "intended use case." Whatever; this isn't urgent.

Feel free to propose another use case, but the one I described really is the intended one. And since there is such an obvious soluation to the other one (simply enter notes instead of rests in the first place), I don't see "I made a mistake and entered rests when it I should have entered notes" as a convincing argument for a new feature. There would have to be a legitimate use case that *isn't* just correcting user error. Maybe there is such a use case, but so far, no one has proposed one, and I'm having difficulty imagining one.

Title Request for repitch mode to include rests, or new mode that allows rests to be re-pitched Request new mode that allows rests to be re-pitched

And please, do *not* ask for everyone else to be inconvienced. We should *not* make repitch mode less useful for everyone else just because of some hypothetical use case for which maybe one might want to "repitch" a rest. So this really is a request for a *new* mdoe, or at least, a new command to use within repitch mode that would allow the cursor to advance to a rest instead of a note.