Skip to content
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

[MU4 Issue] Num pad not responding for duration selection #12791

Closed
mccoydtromb opened this issue Aug 11, 2022 · 45 comments · Fixed by #15819
Closed

[MU4 Issue] Num pad not responding for duration selection #12791

mccoydtromb opened this issue Aug 11, 2022 · 45 comments · Fixed by #15819

Comments

@mccoydtromb
Copy link
Contributor

Describe the bug
Using num pad no longer works for selecting durations. I have checked Num Lock (makes numpad into arrows which navigate around buttons or notes). The problem started after I had been experimenting with using MuseScore with a MIDI keyboard. To remove the MIDI keyboard from the input slot I also clicked "Reset Preferences", so it may be due to that.
I tried re-adding the numbers as shortcuts, but that didn't do it.
Interesting point is that the numpad dot still selects dotted note, and + for ties and / for acciaccaturas still work.

Steps to reproduce the behavior:
I can only guess that Reset Preferences does this, but haven't been able to test from a starting point again.

Expected behavior
Use num pad numbers same as number row to select durations

Platform information

  • OS: Windows 10
  • MuseScore 4 Alpha
@HemantAntony
Copy link
Contributor

I forgot. Did you try reset to factory settings. You can find that in the Help menu

@mccoydtromb
Copy link
Contributor Author

Great idea. Just tried it, still no joy. Reinstall also didn't change anything.

@mccoydtromb
Copy link
Contributor Author

But it's not my keyboard, because it works in 3.6

@critchie
Copy link

critchie commented Aug 11, 2022

I noticed this a while back. For the Num Pad to work the shortcut must register as NumPad. For example, “Num+4”, and not just “4”. The shortcuts dialog is not picking up this distinction when editing the shortcut. As a work around I exported the shortcuts and manually added the NumPad shortcuts in the proper places and then imported them back into MuseScore. It worked but this is definitely not a long term solution and can be dangerous as it by passes the application’s validations.

I’d definitely like the num pad to work. I bought a separate num pad so I can place it on my left hand while I work the mouse with my right hand.

Here is my thread on the MuseScore forum:
https://musescore.org/en/node/333674

@henkdegroot
Copy link

henkdegroot commented Aug 11, 2022

Interesting, as in MS3 and MS4 the shortcut definition seems to be similar for these keys:

MS3:
image

MS4:
image

Obvious note the slight different on the NumPad text in MS3 vs Num in MS4.
However it does seem the "NumPad" keys are assigned to other functions, but still in MS3 they can be used to select the duration. Would definitely like this functionality to be standard in MS4.

EDIT: Just tested...and in MS4 (without any modifications) the duration selection is working for TAB staves.

@critchie
Copy link

Yeah… clearly something is different between the two versions. When I export the shortcuts and edit the XML to this:

<SC> <key>pad-note-8</key> <seq>4</seq> <seq>Num+4</seq> </SC>
Then import it back in the NumPad works.

@henkdegroot
Copy link

Well you should not have to define any shortcut. For a regular staff, the "keyboard" numbers and "numpad" numbers should be treated as the same key. If it was not required in MS3, then it should be possible to get the same behaviour in MS4.

@MarcSabatella
Copy link
Contributor

It was always very system-dependent in MU3 - worked out of the box on some systems, not on others. of the one where it didn't work out of the box, some could be fixed by manually setting the shortcut, others were not so lucky. Seems the same situation exists in MU4 except for the specifics of which systems are in which category. Not sure it's even technically possible to get it to always work correctly out of the box for all systems - different OS's, different keyboard layouts, different language settings, different device drivers, etc. But it's reasonable to hope that manually setting the shortcut will work "almost always".

@henkdegroot
Copy link

Understand what you are saying, but that does not explain the different behaviour between MS3 and MS4 on the SAME laptop and thus using the same OS. It might just be something missed when transferring the code to the new MS4 structure (at least that is my guess).

However, as mentioned by @critchie manual setting the "numpad" key in shortcuts is not even possible.

@MarcSabatella
Copy link
Contributor

Different versions of Qt, different ways of processing that input within MuseScore - I'm sure that explains the difference. I believe others have said they can set the numpad via the dialog, which is why it seems to me the situation is the same as MU3 - works on some systems, not on others. Maybe I imagined that? Anyhow, I don't have a numpad available to test with. I just want to add some clarifying info that this was always a problem in MU3 on some systems.

@critchie
Copy link

It seems to me the issue is in the Edit Shortcut dialog. When I press 4 on the NumPad, MuseScore must enter Num+4 and not just 4. It needs to look at the key event and use the proper key value from the Key enum. It has to distinguish between NumPad4 and D4.

When I edit the exported XML and manually add the Num+4 MuseScore handles the shortcuts properly. If I hit the NumPad 4 or the keyboard 4 the duration changes to an eighth note. So the application reacts properly once the shortcut is setup.

@mccoydtromb
Copy link
Contributor Author

Interesting, because I've been using the Numpad for all my testing of nightlies, but suddenly not happening in the alpha.

@Roman251
Copy link

I have the same problem. A piece of information that may be irrelevant: when I try to add new shortcut and try to use (for testing) Ctrl + Numpad keys it shows in MU4 as "Ctrl+Pause". That being said, it has the same behavior in MU3 and numpad works correctly there (Win 10)

@daeavelwyn
Copy link

Hi guys,

Same issue here with MuseSCore 4 (OS: Windows 10 Version 1809, Arch.: x86_64, MuseScore version (64-bit): 4.0.0-2844400529, revision: github-musescore-musescore-abc123456)

Neither default shorcut nor manually change shortcuts work on my side.

@Tantacrul Tantacrul added the P1 Priority: High label Aug 31, 2022
@Tantacrul Tantacrul added this to To do in Keyboard navigation and shortcuts via automation Aug 31, 2022
@Tantacrul Tantacrul added this to To do in 4.x SHORTLIST via automation Aug 31, 2022
@sikamber
Copy link

sikamber commented Sep 2, 2022

I have the same issue (in alpha 2, windows 10, newly installed). I am not able to fix it in the options menu (when I press "4" on the numpad, it just sets the shortcut to "4", but when working in the score, pressing "4" on the numpad does not trigger the shortcut).

So it seems that at least for me, the shortcut menu and the main program interprets the same keypress in two different ways. I am using a logitec "LogiLink" external keypad with default windows drivers, if that matters.

Exporting the shortcut file and manually editing it (like Critchie described) worked.

(EDIT: clarified that I'm using windows)

@sammik
Copy link
Contributor

sammik commented Sep 7, 2022

For me numpad works (latest nightly OS: Ubuntu 22.04.1 LTS, Arch.: x86_64, MuseScore version (64-bit): 4.0.0-2990798632, revision: github-musescore-musescore-5d26e7f)

@daeavelwyn
Copy link

Hi folks,

I first removed all my previous preferences (documents, appdata in local and roaming)

I just tested once more with OS: Windows 10 Version 1809, Arch.: x86_64, MuseScore version (64-bit): 4.0.0-3005078110, revision: github-musescore-musescore-abc123456 and got the same issue. French AZERTY keyboard

The numpad just doesn't work and the numbers on the alphanumeric part of the keyboard work (shift + number) except the number 6...). I also tried ctrl+number and it seems to work except for the 6.... So I tried with another keyboard but got the same result.

I've tried to remove 'kind of' dupplicate entries I found in the default shortcut map (example : 6 is use also for tab) but it still doesn't work.

Any tests I could do to help solving this ?

@napochanIsMe
Copy link

I see similar problems with MU4-alpha2 with ties not working as in MU3 and with shortcuts, both as downloaded and after attempting to edit the shortcuts. I tried editing in the app and offline with an XML editor and neither approach worked. Clicking the tie command in the tool bar works as expected.
System info: Win11, v10.0.22621, 64-bit

@MarcSabatella
Copy link
Contributor

MarcSabatella commented Nov 17, 2022

The tie command has changed to “T” :-)

@napochanIsMe
Copy link

The tie command has changed to “T” :-)

Thanks Marc. I just need some retraining to learn the new shortcut!

@trevorspecht
Copy link

Using a Mac and Apple computer keyboard, I too am not able to use the numeric keypad to enter note durations. Even if I go to settings/shortcuts and use the keypad to alter the shortcut for a note duration, it still won't recognize the keypad for note durations, only the number row across the top of the keyboard.

OS: macOS 12.6, Arch.: x86_64, MuseScore version (64-bit): 4.0.0-223472200, revision: github-musescore-musescore-5485621

@Eism
Copy link
Contributor

Eism commented Jan 10, 2023

Actually, I don't see the difference between, for example, pad-note-8 and pad-note-8-TAB in the code. Both shortcuts call padNote method.

So can we do the following

  1. remove all pad-note-N-TAB from the shortcuts file
  2. treat number input and NumPad+number as equivalent

Did I understand the problem correctly?

@henkdegroot
Copy link

Not a developer, so just replying from a user perspective here.

I believe the pad-note-8-TAB entry is triggered when using the numbers while working with a Tablature staff. As numbers in this case are selecting a fret mark. Whille SHIFT+number selects the Note Duration. At the same time, pressing the number in the NumPad section of the keyboard is also selecting the note duration.

While in a non-Tablature staff, the pad-note-8 entry is triggered and in this case a number (either being in the located in the NumPad section or at the top keyboard row) selects the note duration.

So if your point 1 correct, I don't know. Point 2 would depend on the staff type.

@MarcSabatella, as you also have developer experience, can you share your input please?

@MarcSabatella
Copy link
Contributor

I have development experience yes, but relatively limited experience with tablature, and none of my keyboard have numpads, nor do I know much about the internals of how keyboard processing works in MU4. So I'm not sure there is anything meaningful I could contribute here.

@cbjeukendrup
Copy link
Contributor

What Henk said matches exactly my understanding. On TAB staves, the number keys are already used for entering free numbers, so users will need to set a different shortcut for duration selection while entering notes on TAB staves.
Because of this, there are two actions that call the same code, but their "shortcut context" is different, so that the shortcut for the TAB variant will only work on TAB staves, and the shortcut for the normal variant can be used otherwise.

@shoogle
Copy link
Contributor

shoogle commented Jan 11, 2023

@cbjeukendrup, ah yes, you're right. It's specifically in note input mode on a tab staff, the number keys are used to enter fret numbers, so then shift+number is used to change to a different duration instead of just the number keys, hence the need for "Set duration" and "Set duration (TAB)" actions.

@Eism
Copy link
Contributor

Eism commented Jan 11, 2023

Okay, let's apply the solution that Marc suggests for now.
The solution I suggested doesn't work for Tabulature staff and needs a lot of changes.

@Eism
Copy link
Contributor

Eism commented Jan 11, 2023

Could somebody test the build from this PR #15819?

(need first reset the preferences if you changed the shortcuts file)

Eism added a commit to Eism/MuseScore that referenced this issue Jan 11, 2023
Eism added a commit to Eism/MuseScore that referenced this issue Jan 11, 2023
Eism added a commit to Eism/MuseScore that referenced this issue Jan 11, 2023
Eism added a commit to Eism/MuseScore that referenced this issue Jan 11, 2023
@vpereverzev vpereverzev moved this from To do to On test in [MU4.0.1 PATCH-RELEASE] Jan 11, 2023
@MarcSabatella
Copy link
Contributor

MarcSabatella commented Jan 11, 2023

FWIW, I'm not sure what I actually suggested :-), but I gather the solution being pursued is to hard-code the duplicates into the defaults file, which is fine.

However, I do have an additional suggestion to consider for the futue. I know it's a controversial topic as to whether MuseScore should allow end users to define multiple shortcuts for the same command. Without revisiting that, I would like to point out that it is reasonable to expect one could redefine "0" or Enter or whatever to be the shortcut for some command, and have that automatically apply to both versions of these keys. After all, we don't have to separately specify LeftCtrl+K and RightCtrl+K as separate shortcuts for chord symbols, it just works. The fact that 0 and Numpad0 are seen as different keys internally probably doesn't matter to the average user - they likely expect them to always behave identically. At least, that's what I might naively think as someone who hasn't used a keyboard with a numpad in years.

So, what if we added code to detect an attempt to assign one, and then just automatically went ahead and assigned the other as well? Maybe not a huge priority for 4.0.1, but it might help reduce confusion and surprise in general in the future.

@cbjeukendrup
Copy link
Contributor

@MarcSabatella (and @Eism ) I'm thinking that we should maybe make an exception for the Numpad specifically; I propose the following:

When the user presses a key on the numpad...

  • if the numpad version of the key is explicitly bound to some action, perform that action
  • if no action is associated with the numpad version of the key, ignore the numpad flag and perform the action that is associated with the non-numpad version of the key (if there is such action).

@MarcSabatella
Copy link
Contributor

That sounds logical to me, although again, not having used a numpad in many years, I don't have a good sense of what users expect. I'm just happy to see this being addressed, as it's easily the #1 problem reported most often by users.

@cbjeukendrup cbjeukendrup moved this from On test to In progress in [MU4.0.1 PATCH-RELEASE] Jan 11, 2023
@cbjeukendrup cbjeukendrup moved this from In progress to On test in [MU4.0.1 PATCH-RELEASE] Jan 11, 2023
Keyboard navigation and shortcuts automation moved this from To do to Done Jan 12, 2023
@vpereverzev vpereverzev moved this from On test to Fixed and ported in [MU4.0.1 PATCH-RELEASE] Jan 12, 2023
@oMrSmith
Copy link

oMrSmith commented Jan 16, 2023

What has caused more trouble? The shortcut system that MuseScore has now, or the shortcut system of MU3.6, which allowed multiple shortcuts for one command.

Infact there are still multiple shortcuts for one command in MU4:
What ist more: That seems to be the fix for the numpad issue...

image

... But now the user can't change them. I don't think this is good.

@Lumi618
Copy link

Lumi618 commented Jan 17, 2023

I just updated to 4.0.1, and I still can't use the numpad to select note durations. I have made sure that num lock is on, and looked in the preferences to change the note duration definitions, but still cannot get them to work. Is there something else I need to do to fix this?

@MarcSabatella
Copy link
Contributor

@Lumi618 you will need to reset your shortcuts, either in edit / preferences / shortcuts, or via help / revert to factor settings.

octopols pushed a commit to octopols/MuseScore that referenced this issue Jan 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 Priority: High
Projects
Development

Successfully merging a pull request may close this issue.