-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Repeat last chord after inputting a rest #18951
Conversation
3e99d32
to
d86934f
Compare
I've spotted something I don't think is right. When in Note Input mode, if I repeat a chord, it becomes 'stuck' in some way. In this example, when I rollover a new chord, pressing R will paste the duration of the original. I would expect that when rolling over a new chord, pressing 'R' would repeat it instead of inheriting the duration of the previously repeated chord. It causes all kinds of problems when you experiment with different durations. I haven't even got to notes with articulations yet. |
Yeah, just noticed it can mess up articulation settings too. For example, this: ![]() I've also succeeded in getting it to remove articulations too. @oktophonie - I think we need to watch this one closely 😄 |
@Tantacrul In any case, this PR does not change anything about the behavior when a chord is selected; it simply changes it to treat a rest as if it were the previous chord when R key is pressed. |
@bakajikara - the behaviour isn't right because the logic is impossible to figure out and it keeps producing undesirable results. This is an instance where it's logical on paper but produces results we can't release. R should repeat both the pitch and the duration. Re the articulation problem. Understood. It's a separate issue. |
@Tantacrul 2023-08-14_21-09-47.mp4We are so used to this input method that I think changing it would require consideration. |
I think that should be solved by manually specifying the duration first. If the user doesn't specify a duration, then it defaults to the original duration. If that doesn't work, then we'll need to think of something else. The current behaviour is just too confusing because you keep getting results you don't expect. The problem at the moment is that we do this too bluntly. We measure the duration we've landed on, and then use that duration by default, which doesn't make sense. Even in your example, it's clear that we've set up a way to specify a different duration to the one you've landed on - so my proposed fix is simply an extension of that behaviour. For example, we moved away from this with copy and paste. It used to only paste pitch (causing endless confusion) whereas now it pastes pitch and rhythm, which is just obviously better. |
fa1f8d3
to
525a11a
Compare
What stops this from getting merged? |
Backport of musescore#18951 plus fixing some a clazy warnings
Why did you close it? |
Backport of musescore#18951 plus fixing some a clazy warnings
Backport of musescore#18951 plus fixing some a clazy warnings
Sorry for closing it after you had been keeping an eye on it. This PR is quite old, and while trying to fix build issues on my local—likely caused by a change in the Qt version—I ended up messing things up. Additionally, a simple implementation of this PR wasn’t enough to achieve what Tantacrul suggested. On top of that, I wasn’t sure how to handle it with the recently introduced note input method (Input by duration). So, I decided to close the PR. |
Backport of musescore#18951 plus fixing some a clazy warnings
Resolves: #16644