Add commands: Shift-Q "Decrease duration dotted" and Shift-W "Increase duration dotted"

The way I'm implementing is to unify the command cmdHalfDuration() and cmdDoubleDuration() into a generalized command cmdIncDecDuration(int nSteps, bool stepDotted) which maps to the key commands according to:

"double-duration" ->            [this]{ cmdIncDecDuration(-1, false);
"half-duration"   ->            [this]{ cmdIncDecDuration(1, false);
"inc-duration-dotted" ->        [this]{ cmdIncDecDuration(-1, true);
"dec-duration-dotted" ->        [this]{ cmdIncDecDuration(1, true);

This way I simply the codebase a bit by reusing code.

I'm making an alternate version of TDuration::shift() call shiftRetainDots(int nSteps, bool stepDotted = false) which retains the dots, unlike shift() which doesn't return dots. This will simultaneous fix what I perceive as a bug in current 2.0.3 behavior in that Q/W doesn't obey the current state of the dots when halving/doubling.

there is also another bug with previous (2.0.3) implementation: if selected a whole note tied to another whole note, then upon halving the duration, it reduces the whole note in half into a whole note, but incorrectly leaves the tie in place. And similarly for other cases where tie is present. But doesn't happen for all combinations of steps. I might fix this while I'm doing this...

Here is how repeatedly pressing Shift-W works in my implementation when starting with quarter note:

press Shift+W:

press Shift+W:

press Shift+W:

press Shift+W:

press Shift+W:

press Shift+W:

press Shift+W:

press Shift+W:

and in reverse (pressing Shift-Q repeatedly) starting from that longa:

press Shift+Q

press Shift+Q

press Shift+Q
(note I had to press shift+Q twice here...I'll look into...seems to be related to preexisting bug I mentioned a couple comments above)

press Shift+Q

press Shift+Q

press Shift+Q

press Shift+Q

press Shift+Q

press Shift+Q

press Shift+Q

press Shift+Q

press Shift+Q

and so on.

One thing I noticed with both Q and Shift Q when tied over is that that they don't remove the no-longer tied over notes...I believe that the code should remove them, though... (EDIT: I found function Score::changeCRlen(ChordRest* cr, const Fraction& dstF, bool fillWithRest) which does exactly that...I'm going to use that function instead of the other one which doesn't fill with rests! Actually that function doesn't quite do that when tied over)

also I noticed another preexisting glitch in 3.0 and 2.1: it seems that a "measure rest" is being interpreted as a quarter note for purposes of Q & W, but I think it should be interpreted as the duration of a measure.

I went and implemented: https://github.com/musescore/MuseScore/pull/3013

There were still some preexisting glitches with regular Q & W that I'm not fixing here.

I think this will fix #122081: Request for command to change duration (including adding dot) retroactively in note input mode

regarding #8 comment, that behavior is still present with regular Q, so I decided to not bother changing that. I would want to make a separate feature request if wanted to fix that behavior for both Q and Shift Q simultaneously, since they share similar code.

the code for my Shift version uses much of the same code for the regular Q/W.

I'd have to recompile to be sure, but what I recall happening was that for a dotted whole note in 6/4, pressing Shift+W would increase into a dotted whole note tied over to a half note in the next measure, while pressing Shift+Q would decrease into a whole note. But I'm not sure I tested that behavior.

I just tried out master on Arch linux...I notice no hooks were displaying on a notes which are clearly smaller than quarter notes:

But it doesn't seem to be from my commit...this glitch is present in the commit before my PR's commit: https://github.com/musescore/MuseScore/commit/ddfad4999416ed60e4c1c0ce2…

I've been testing on master, I noticed an issue when pressing W (with or without shift) on a note in a 2nd voice will cause unnecessary 2nd voice rest in the subsequent measure, but this issue is also present on 2.0.3, which means my code is NOT responsible. Reproduction steps in 2.0.3:

1. create quarter note in 2nd voice:

2. select it an press "w".
The result is the creation of an unnecessary whole in the 2nd voice of the 2nd measure:

Similarly, if use shift "W" in latest master, I can get similar types of unnecessary rests appear in the next measure. So basically the original code didn't actually handle voices properly, it seems.

Should I go ahead and file this and look into?

@mike320, excellent observation, thanks. I can observe that behavior in 2.0.3 as well, but not just when beat 3 was a quarter rest, but also when beat 3 was a quarter note. So really that means the bug is not in the original Q/W code, but rather the bug lies with the manner in which musescore adds rests when a chord-rest in a voice has its duration changed.

I'll going to tackle:
#183471: increasing duration of note in any voice shouldn't produce unnecessary rest in next measure
#183276: disable durations smaller than 128th when use "Q" or Shift + "Q" in 2.1-dev

There is also the question about what to do when pressing Q or shift Q after pressing W or shift W causes a tie to form. Should the tie be broken when pressing Q or shift Q?

(fyi my internet is down temporarily, and I'm using someone else's phone to type so I can write out complete issue.)

@lasonic, do you want me to try doing a PR of this commit against 2.1, since I might figure out the correct merge.

What is bothersome to me is that although it "ignores" the tie if it is just tied over to the immediate next measure, it doesn't ignore the fact that it is tied if user has incremented from a *double whole* to a *longa* and then presses Q to go back down to a *double whole*.

Now I believe I know why the behavior is so strange. It is because the code is following the duration that is currently selected in the note input toolbar. I believe the code would work correctly if it instead followed the total duration of the currently selected note, taking into account what duration notes are tied after it.

ok, thanks. Yes I'm aware that the note may be part of a chord that is not completely tied over, but I was thinking of just looking at the selected note and seeing it was tied over. But anyway, sounds like the tied issue is something that we are not going to worry about. That is less of a headache.

Shift Q/W seems to be working on the latest 2.1 branch with this commit.

@mike320, I'm also testing 9ca7d0b right now...but I'm able to use Shift-Q and Shift-W.

I am noting that I am unable to produce a dotted 128th note by applying a dot to a regular 128th note. I am only able to produce the dotted 128th note by starting from a dotted 64th note and pressing Q.

the problem occurs when the dotted 128th is created from the dotted 64th, which results in:

The problem is that that first rest is a 128th rest but really needs to be a 256th rest. I'm guessing that the 2.1 code is preventing the 256th rest from being created.

I also note that a similar problem occurs when trying to create a dotted 128th from a regular 64th by pressing shift+Q:

So it seems since 256th rests aren't being created, the solution is to disable the ability to create a dotted 128th note via Q or Shift-Q.

I'm testing in the 2.1 branch...I've tested extending the if condition in https://github.com/musescore/MuseScore/commit/e35af69355e1de4ec60526449… to also return INVALID duration if:
(newValue == int(DurationType::V_128TH) && (newDots > 0)))

And then I find that I'm no longer able to produce the dotted 128th either from:
1. Pressing Q on a dotted 64th
2. Pressing Shift+Q on a regular 64th

I'll submit this PR for 2.1

Also I will need to prevent the creation of a double-dotted 64th note (which could be created by pressing Q on a double-dotted 32nd note), since that would have resulting in a 256th rest which can't be represented in 2.1, as can see in the following erroneous result:

(that first rest should be a 256th, but 2.1 can't represent that)

I've prevented these cases (described in comments #40-#44) in this 2.1-only PR: https://github.com/musescore/MuseScore/pull/3101

Seems like I can produce triple-dotted notes in 2.1 by making a measure end with a 128th note, then changing that 128th into a quarter note:

So now with that triple-dotted eight note, I can press Q twice and produce erroneous result:

Which is problematic because that tripple-dotted 32nd needs to match up with a 256th rest, which can't exist.

Are there any other corner cases I need to worry about, such as quad-dotted 16th notes??? Maybe I'll go test for that also...

So those issues could hypothetically happen in 3.0-dev, which is limited to 1024th notes and quad-dots, so I've locially extended my 2.1-only fix and made a corresponding 3.0-only fix: https://github.com/musescore/MuseScore/pull/3102
and Shift-W commands to decrease
Folks there is one minor issue I noticed: my shift+Q jumps down to the next smallest non-dotted note when it is applied to a double-dotted, triple-dotted, or quad-dotted note. So that means that a quad-dotted half note:

will become a plain half-note if press shift+Q on it:

Similarly a tripple-dotted half note would become plain half.
Similarly a double-dotted half note would become plain half.

I don't think this is bad, actually. But it just means that the name of my feature isn't quite accurate, because according to my feature title, those should have all become single-dotted half notes. So I could change the name of my feature to say:

1. Shift+W to increase duration to next larger dotted or undotted duration.
2. Shift+Q to decrease duration of undotted duration to next smaller dotted duration.
3. Shift+Q to decrease duration of [single,double,triple,quad]-dotted duration to next smaller undotted duration.

Or I could re-implement so behavior adheres to my original title. But I don't want to reimplement because I actually like how it behaves on case 3, to be honest, and because I don't want to screw things up.

I made a PR for the simplest test cases of Q, W, Shift-Q, Shift-W: https://github.com/musescore/MuseScore/pull/3104

I'm also making a decision (after a bit of thought) to simplify the text description of the command (which affects how it appears in Edit->Preferences->Shortcuts), and renamed the title of this feature request accordingly. I'm renaming because (a) it was too wordy, so might be confusing to new users, and because (b) it did not exactly reflect the behavior that I implemented for cases when applied to notes with more than one dot.

For reference, if currently-selected duration has one or more dots, the behavior is the following:
1. Shift+W will increase to next larger undotted duration
2. Shift+Q will decrease to next smaller undotted duration

Well that's a good point that Shift+Q/W will already go to nearest undotted when applied to a double-trip-or-quad--dotted chordrest. So, maybe I should have it always go to the nearest dot. To be honest, I didn't really consider what should happen to a double-trip-or-quad--dotted chordrest when I first made it. But none of this is a good reason to change the behaviour of Q/W.

I'm also wondering if people would want a Ctrl-Shift Q/W which would step to next nearest Double-Dotted, Single-Dotted, or Undotted chordrest? It should be fairly straightforward now that I know what to look out for.

have Q/W on a dotted note double/halve its duration.

Actually that is why my implementation (which has been merged into 2.1 and master) does for regular Q/W. That is what I think it should do anyway. I was actually unaware that 2.0.3 did not do that. I actually consider the 2.0.3 behavior for pressing Q/W on a dotted note to be a bug, since the Shortcut is labeled "Half duration" and "Double duration", but 2.0.3 does not actually Half or Double the dotted note's duration. So when I implemented my modification, I subconsciously fixed that "bug".

Anway, the question I'm still debating with myself is what should happen when pressing Shift+Q on a double-dotted note, for example: