Letter A not working for input notes in Danish localisation. Possible solution included.

[Oldcamel86]

Issue type

UX/Interaction bug (incorrect behaviour)

Bug description

Letter A not working in Musescore 4 when inputting notes (european keyboard), even on 4.2.0.233521125 Workaround should be: go to Edit / Preferences / Shortcuts, and define a custom shortcut for “got to top staff”. That will prevent it from being triggered by the phantom keycode your keyboard is sending. That’s already fixed for 4.2, BTW." The issue seems to persist on my Mac, danish keybord. The cursor jumps to the "Home" menu, and if I keep pressing "a" it circles between the home, pencil, notesheet tab and top of palette, that is, "a" acts in the same way as F6. I have tried on 2 macs, 3 different keyboards, did clean install with deletion of Musescore4-folder and library application support folder. The video below shows the problem, and also that the "a" key works as intended in other software - that is, problem must be on Musescore side, not the operating system. Video showing the error: https://screenpal.com/watch/cZV1DEVHHVl

SOLUTION seems to be to remove these lines from shortcuts.xml

    <SC>
        <key>nav-next-section</key>
        <seq>F6</seq>
        <seq>`</seq>
    </SC>

and

    <SC>
        <key>nav-prev-section</key>
        <seq>Shift+F6</seq>
        <seq>Shift+`</seq>
   </SC>

I don't know if these lines are specific for my installation, but looking in the shortcut dialogue of Musescore shows no shortcuts using ` or F6, which made me suspicious.

Steps to reproduce

1. Use a Danish keyboard and Danish localisation
2. Input notes using the letter key a

Screenshots/Screen recordings

https://screenpal.com/watch/cZV1DEVHHVl

MuseScore Version

4.2.233521125

Regression

I don't know

Operating system

Mac OS 14.2.1

Additional context

No response

[KARAN-CODE50]

@Oldcamel86 claim Can you please assign this issue to me ?

[Oldcamel86]

@KARAN-CODE50 I am not sure, I have the privileges to do so. I don't seem to be able to assign anyone? (I'm a newbie here)

[Oldcamel86]

Important addition: If I at a later time edit any shortcut from Musescore preferences, the "letter a" bug reappears!

[MarcSabatella]

This is very strange. It seems your keyboard must be sending two keycodes for the A key - one that gets interpreted as F6, and then the actual A. Other programs are apparently ignoring the first and responding to the second, but MuseScore responds to the first and ignores the second. Can you test using another program that actually does normally respond to F6 (or Fn+F6) to see if the problem is reproducible there?

Obviously, since other keyboards were triggering the phantom "Go to top staff" shortcut, this is dual-keycode thing is something actually designed into that model of keyboard, but it's not clear to me why. Are you sure you've consulted all possible documentation in your OS to be sure there is no setting to disable that special handling of that key?

[Oldcamel86]

Have you read my suggestion for the solution: The lines in the Musescore shortcuts.xml seems to be the reason:

   <SC>
        <key>nav-next-section</key>
        <seq>F6</seq>
        <seq>`</seq>
    </SC>

If you remove the line with the accent `, everything works as it should - also F6. BUT if you later on edit any shortcut in musescore, the bug reappears. It seems to me, that the Danish version does strange things, when you edit shortcuts.

I am absolutely sure that all other software on my computer responds normally to both F6 and "a" - no special handling of those.

[MarcSabatella]

I did see your comment about the shortcuts file, that is what confirms that the extra keycode your keyboard is sending is being interpreted as either F6 or backtick. And your followup here seems to indicate the problem might really be with the backtick. I wonder, is configured as a "dead key" on your computer? What is you remove only the F6 lines - does the problem persist? What if you remove those lines but then also try to assign F6 or backtick to another command? How about if you replace the backtick character itself with the HTML entity `? And same question about whether the backtick actually continues to work as it is supposed to (an alias for F6, to navigate the UI) if you make that change?

I ask these questions because I don't have that keyboard to test with, and I assume no one else on the development team does either. I created the original fix that was confirmed to work for most people based on the "Go to top staff" command just by some trial and error and asking questions of the people who were experiencing the problem, since I had no way to test for myself. I'm trying to do the same here. I'd like to implement a fix that doesn't break anything else, but again, since I can't reproduce any of this for myself, I will rely on people who can to help in diagnosing the problem.

What's still not clear is what that extra keycode actually is or why it is being sent in the first place - what is it about Danish Mac keyboards that is unique in this way, and what the intended purpose of the extra keycode is meant to be. If I understood more about the nature and of the extra keycode, I could be more confident about a fix.

Can you post a picture of your keyboard so I can better see which specific layout it has? It will be good to check it against https://support.apple.com/en-us/102743 to better understand the specifics in terms of being able to learn which keycodes are sent by which keys.

[Oldcamel86]

I'll do my best to answer your questions. I show everything in this video: https://screenpal.com/watch/cZVjFwVH74f I have attached a picture of a Danish keyboard here: Danish keyboard.pdf The problem is only related to the accent ´, which is in fact a "dead key" in Denmark. We only use it for é or similar. The problem persist, if I exchange backtic with &#96 in the shortcuts.xml. The backtick does not in any way function as alias for F6, since it is a dead key. I am not even able to assign it as a shortcut in preferences for the same reason. As I show in the video, the keyboard does not send any extra keycodes, and why Musescore interprets it in this way I can't say. In Musescore 3 both F6 and letter "a" works as they are supposed to.

Thank you for seeing into this - I have been frustrated over the number of bugs in version 4, but I think you're getting there: the recent version is very good in many ways.

[MarcSabatella]

Thanks for the info!

I certainly believe that keyboard works as designed by Apple. But again, it is very clear that an extra keycode is being seen, even if your web browser is ignoring or filtering it out so that your web-based keycode monitor doesn't see it. Or perhaps that website itself is ignoring or filtering it out. Again, if the keycode weren't being seen by MuseScore, we wouldn't be seeing this behavior - and only on Danish Mac keyboards. This doesn't happen on any other keyboard in the world as far as we can tell, so there has to be something unique about this design that is causing MuseScore to see the extra keycode. I hope you can agree that something is very different about your keyboard, and that something is being seen by MuseScore an extra keycode even if other apps don't see that difference in the same way.

So, I still need to get to the bottom of what this difference is and where it is coming from and why, if I want to come up with a reliable solution I can be confident about. Without that understanding we can only attach more Band-aid's and cross our fingers and hope for the best. That's what we did last time and worked for some people but apparently not for others. This time I want to be sure we really understand and solve it for good.

So we still need to better understand the nature of what makes "A" behave differently on Danish Mac keyboards compared to all others, but I'm not sure how to go about that. Do you have a way to submit support queries to Apple? That could give us the most authoritative answer. I'd also like to know what happens if you switch to a different keyboard layout using whatever settings macOS provides for this. Also, do you have any non-Apple keyboards you could connected and test? If the computer has a touch screen and virtual keyboard, how about that? I'm trying to understand if the special behavior is inherent in the keyboard itself or in the processing done by macOS.

Also, you say F6 has no function in macOS, and while that may be true of the OS itself, it's not necessarily true of all macOS apps. I'm still interested to know what the "A" key does in an application that does respond to F6. It's a standard key used for accessibilty as in MuseScore, so there should be other cross-platform apps that respond to it in the same way. But even among those applications not designed to use these cross-platform accessibility shortcuts, there should be some that use F6 for some purpose, or that allow you to define it yourself. Again, keep in mind that it's probably going to be Fn+F6. Once you find an app that does respond to F6, I still want to know what happens in that app if you press "A". But based on what you've described, I think the phantom keycode is more related to the backtick than to F6.

[Oldcamel86]

Sorry for the delayed answer - busy on work. I shall post several answers, as I do the testing. Regarding F6: I succeeded in assigning a shortcut to F6 in Mac OS "move focus to window toolbar". Tested, that this works in Finder Windows, Safari and MS Word. I also tested, that "a" and ´ worked normal in MS Word. I Musescore 4 i did a reset of preferences and restarted. Then F6 does not work at all, "a" does what F6 should have done, ´ does nothing. (And just for the record: I am quite aware of the use of the Fn-button, I actually switched this off, so I could deal with the "clean" F-buttons)

[Oldcamel86]

I have tried switching to US keyboard layout. This results in: a working as it should. F6 working as it should. The key located where you see ` works as F6 - but on a Danish keyboard, the key below a is marked "<". I would like to point you in the direction of the difference between scan codes from the keyboard and the sign interpreted by the OS. I am no expert, but from making a font I know, that this is crucial across different languages and OS'es. See https://kbdlayout.info/kbdda/scancodes - there is a nice "creating a shortcut" helper here too. Also I hope you can finde use of this video, where I show the behaviour using US and DK keyboard layout: https://screenpal.com/watch/cZVI67VJhpJ I must say, that I don't think your theory of the letter "a" sending 2 different keycodes at the same time, is valid. And I don't think there is any chance that Apple will consider this an error on their side, since only Musescore shows any strange behaviour. I do think that the use of backtick as a shortcut leads to problems, since this sign is located different in different languages.

Further on: if I switch the OS input language to US English, the error disappears immediately. I guess this would imply, that any developer with a mac can add Danish as input language to test the behaviour. Attached file shows keys pressed on Mac OS using DK and US keyboard input (also seen in video)

[Oldcamel86]

A reliable solution could be to make sure, that the shortcut preferences, that is shortcuts.xml, was language specific instead of relying solely on US keyboard layout.

[Oldcamel86]

I have tried one more thing: I am running Windows 10 using Parallels Virtual Machine. And strangely enough, there is no error in Musescore running Windows - on the same keyboard and in fact, the same Mac. I noticed, that the shortcuts.xml-file is NOT exactly the same, but if I use the windows-file on my mac, the "a"-problem persists. But there are differences between Windows- and Mac keyboard layout, though not regarding a, ´ or F6. shorcutfiles.zip . I attach both files here.

[MarcSabatella]

Thanks for the info! In the past there were separate shortcut files provided and it's conceivable we could go that way again in the future, but I wouldn't be in a good position to make that call - I'd really only be able to make a quick fix like I did before.

Thanks especially for the info on setting language - it does suggest anyone with a Mac might be able to test this via the language settings. Since I don't have access to a Mac, I'm unfortunately still not really in a good position here. Hoepfully someone else who does can pursue this further

Again, though, there is no possible way that your "a" isn't doing something different from what every other system does. Whether it's literally two separate codes, or something else that the libraries upon which Musescore relies (Qt, mostly, for this sort of thing) interprets as a different code, obviously, something is being sent that is unexpected and somehow triggering the F6 action. If there was nothing unique about what your keyboard is doing on your system, the problem would exist for everyone, not just people using Danish layout on macOS.

So getting to the bottom of that would still be ideal.

[henkdegroot]

Maybe it is an issue in Qt https://bugreports.qt.io/plugins/servlet/mobile#issue/QTBUG-85660

[Oldcamel86]

To be absolutely sure, that the issue has nothing to do with my specific setup of my Macs (who share a lot of settings), I did a test on a completely different mac (another Apple ID user) on a fresh installation of Musescore. The issue persists.

[MarcSabatella]

Yes, indeed, I completely expect that whatever is going on would hold for all macOS systems with Danish keyboard layout. And also, to be clear: at no time did I or anyone else ever suggest it was an "error" on Apple's side. Just something that is working differently and that we need to understand better what is different about this configuration before we can solve the problem with confidence.

The Qt bug report mentioned by @henkdegroot definitely looks relevant here even though it involves a different Qt component. It may well suggest a workaround MuseScore could put in place. Thanks for the info!

[sfreyer]

This issue has frustrated me on my Norwegian keyboard as well. Finding this thread and realising there is a shortcuts.xml led me to try to move

    <SC>
        <key>note-a</key>
        <seq>A</seq>
    </SC>

as the first shortcut in the named file. Problem apparently solved.

[jeetee]

This issue has frustrated me on my Norwegian keyboard as well. Finding this thread and realising there is a shortcuts.xml led me to try to move [...] as the first shortcut in the named file. Problem apparently solved.

Does it remain solved if you then subsequently edit a different shortcut via the UI, thus forcing MS to update the shortcut.xml file?

[sfreyer]

The shortcut.xml-file is apparently written in a determined (or random) order. I tried changing another shortcut in the settings. Back to square one. Moving the note-a to the top again made MS4.2.1 work as expected. I can live with this as a workaround. I do enter more A's than changing shortcuts…

This information may be used to debug the faulty operation.

[bkunda]

@Eism has recently made some changes to address issues like this. @Oldcamel86 @sfreyer Could this please be retested in 4.3.1 and master to see whether the specific issue raised here has been resolved? Thanks!

[Oldcamel86]

@bkunda I have just installed 4.3.1, and I am sorry to say: The problem still exists.

[sfreyer]

@bkunda Same issue. My solution to move the entry to the top in shortcuts.xml is still working. ... <Shortcuts> <SC> <key>note-a</key> <seq>A</seq> </SC>

[cbjeukendrup]

If you haven't done so already, it would be good to try the master nightly builds too (https://musescore.org/en/nightly-builds), because those contain even more changes to shortcut handling

[Jojo-Schmitz]

´The questions are:

1. Why are those shortcurs for nav-next-section and nav-prev-section not listed in Edit > Preferences > Shortcuts?
2. Why in addition to F6/Shift+F6 do they need "`" and "Shìft+`", as (almost) none of the other nav-* shortcuts have alternatives? Esp. as they apparently do cause some very basic shortcut failures for some of us.

On non-English keyboards these don't make sense, "`" requires Shift, unshifted it'd give "´"

They are apparently meant to be used for keyboard navigation in menus and dialog, but only Ctrl+`" (!) works (as F6, not as Shift+F6)

[MarcSabatella]

I think the answer to 1) is, these are not normal shortcuts, but part of the accessibility / UI navigation scheme, along with Tab to move between controls within a section. So it’s probably not meant to be customizable.

I think the answer to 2) is, that’s to make the navigation simpler for blind users since F6 can be a bit hard to find, and the backtick is adjacent to Tab, at least on US QWERTY.

[Jojo-Schmitz]

Still Shift+backtick doesn't make sense, it'd be ~ (tilde) on US QWERTY (BTW: that key above Tab would be ^ and ° in a German QWERTZ, but changing shortcuts.xml to use those doesn't work at all, forward and backtick probably don't work for the same reason: they are dead keys)

Whatever: moving all those navigation shortcuts to the bottom of shortcuts.xml might solve the issue too

[Oldcamel86]

Hi everybody. Is there any progress on this issue? I've just begun using Musescore with a new class of students, and every mac user has this issue.

[cbjeukendrup]

Have you by chance already tried whether this is fixed in MuseScore 4.4, which has been released today? MuseScore 4.4 uses Qt 6.2 instead of 5.15, which may have improved things; or rather, it caused some issues with the letter A even on non-Danish keyboard layouts, and we fixed those issues, so maybe that has also fixed it for Danish.

[Oldcamel86]

I just tried 4.4 at one of my students today. It did not work. And worse: the problem now seems to have spread to include drum notation: now “a” does not work here either! I wish you would change the problematic shortcut for good. This would be an annoyance for those who have to learn a new shortcut, but it would make a major difference all over the world, where non-US keyboards are used.

[cbjeukendrup]

I think I found a "real" solution: https://github.com/musescore/MuseScore/pull/24368. You can try it out using the instructions from How to download test builds from pull requests.