Entering numbers and navigation are broken in TAB staff [AZERTY keyboard]

• Feb 16, 2018 - 09:27
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Few
Severity
S2 - Critical
Reproducibility
Randomly
Status
closed
Regression
Yes
Workaround
Yes
Project
MuseScore
Tags
3.0alpha
tablatures
notations
noteentry

GIT commit revision e274a41 / Windows7

1) Guitar Tablature template
2) Press "N"
3) Type 1 or 2 etc.

Result: nothing happens, any number

In addition, by hitting arrow keys to navigate to the right (despite the quarter note value is selected by default), the cursor jumps immediatly to the next measure (and see the shadow note)
Tab.jpg

It works by entering letters (since the default is numbers, you get 0 and 1 by typing a and b, and so on)

Comments

• Aug 22, 2018 - 17:38

I venture to raise this issue once more, which seems to be forgotten. And yet, it is really serious, the navigation is broken, the numbers input too, and therefore we can consider that TABs are unusable. And this, since six months :(
Thanks all.

Reply

• Aug 23, 2018 - 07:24

I don't know, but always the same failure and behaviour here with OS: Windows 7 SP 1 (6.1), Arch.: x86_64, MuseScore version (32-bit): 3.0.0, revision: be5ebbc
(and Windows 10, too with: OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (32-bit): 3.0.0, revision: eba4685)

I do exactly the same thing: Guitar Tablature template -> "N" -> I type "1" or 2 etc: nothing -> right arrow: jumps to the second measure.
Exactly same steps with 2.3.2 (eg): result as expected

Don't understand.

Reply

• Aug 23, 2018 - 09:23

I checked with the TAB staff template (not the Guitar + TAB template, with linked staves). No matter, the problem is not there.

Indeed, by using the mouse (default fret 0), I can't edit the fret by typing numbers: I do the same thing afterwards, with the 2.3.2, and it works, as always.

After doing Revert To Factory Settings and by trying various combinations (Keyboard layout: French/French, or Azerty) and Workspace, Basic or Advanced: nothing change.

Have you try, not with a self built version, but with a development build (from the download page), ie: be5ebbc ?

Reply

• Aug 23, 2018 - 20:16

Well, I'm always puzzled.
I can make it work now but by adding the Shift key: Shift + 1 for fret 1, Shift + 2 for fret 2.
Everything except convenient.
Systematically, I make Revert to Factory Settings. So, it can not be something that I would have "dragged" with me as antecedent, or shortcut conflicts.

And I always see that the change takes place on January 5th, as indicated in my first comment: https://musescore.org/en/node/269507#comment-820487

With the one that works (and with 2.3.2, and others), I just type 1, 2 and I get the expected result.

From the other, it does not work anymore, or I have to add the Shift key (which I just saw ) to the number entered.
I do not always know what I missed.

NB: on January 5, I observed (nothing more) this nightly - a big one, alas for checking - about "Layout for movements": https://github.com/musescore/MuseScore/commit/0b1aea952f9f870ef79f39899…
In debug mode, a shortcut "relayout" is not found.
Maybe related (but what would the Shift key do here, hardly understandable I fear), or definitely something else?
I cannot know :(

Reply

• Aug 24, 2018 - 16:06

Ok. It could be due to a change of Qt versions ?
@cadiz1 could you go in the bin directory of each nightly (the working one and the working one with Shift) and right click Qt5Core.dll > "Détails" > "Version du produit"

Reply

• Oct 26, 2018 - 23:50

Fixed where, how and when? And idea?

Here, nothing new. With the last nightly, always and definitily broken as explained since the first report :
OS: Windows 7 SP 1 (6.1), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: c86314d
(and same behavior with my two other computers)

So, I give up. I'm tired of saying the same things again.
3.0 is inusable for me for entering tabs. Return to 2.3.2 which works perfectly, with exactly the same(s) computer(s), the same process, the same manner to type fret numbers etc.

Reply

• Oct 27, 2018 - 05:42

Does my gif show correct entering numbers to tabs? Is it the scenario you mentioned in the issue description?

My machine is Windows 10, x64. I cannot help if I don't get the problem, unfortunately. I tried to reproduce the scenario from description step by step, record the gif, everything works as expected (no?), I marked the issue fixed. If something is still broken, let's continue investigation to have this fixed in the release.

Reply

• Oct 27, 2018 - 07:21

Tested with : OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: c6ecef5
(Guitar tablature template, and checked also after revert to factory settings)

Video.gif

Reply

• Oct 27, 2018 - 07:56

I suspect something related to keyboard layout. I use ASUS RoG laptop for testing with the keyboard like https://dlcdnimgs.asus.com/websites/global/products/OHAoWnnquTkyI5Cn/im….

Here is the video https://youtu.be/-AZBbomA3n4.
When you use right arrow without modifiers in text editors does cursor move symbol by symbol or word by word?
I'm asking because I see two separate issues which are always reproduced for you and never for me, unfortunately, these are "Right arrow in TABS moves cursor by measures, not by ticks" and "Unable to enter frets using numbers neither using numeric row nor using numpad".

Reply

• Oct 29, 2018 - 20:21

I reopen. The same faulty behavior is described as well by another French user (using Windows10 and AZERTY keyboard) and with current 3.0 dev. 78fbab1

Reply

• Nov 13, 2018 - 09:18
Regression No ⇒ Yes
Severity S3 - Major ⇒ S2 - Critical
Workaround No ⇒ Yes
Frequency ⇒ Few
Priority ⇒ P0 - Critical
Reproducibility ⇒ Randomly

Reply

• Nov 21, 2018 - 15:39

Well, it seems it is possible to reproduce this issue on Linux with AZERTY keyboard layout. The problem seems to be in keyboard layout itself: is seems that to insert numbers in AZERTY you have to press Shift+[number key] instead of just a number key (you can check this in any text editor, e.g. Notepad). Entering numbers in MuseScore in such way in fact works, including the tablature case. Theoretically we could also bind such a kind of input to physical number keys instead of the characters that are sent to MuseScore but this seems to be more a feature request.

Concerning cursor movement on arrow key, it also works well if something is entered. Adding rests also works though not really trivial to find: you have to use ";" key (https://musescore.org/en/node/52296#comment-244296).

So I believe the question is whether we should have a feature request for that tablature number input without Shift in AZERTY or it is not necessary to have in MuseScore.

Reply

• Nov 21, 2018 - 15:45
Status active ⇒ needs info

And will update the status, I believe this bug report can be closed if tablature input indeed works with Shift+[number] in AZERTY.

Reply

• Nov 21, 2018 - 16:50
Status needs info ⇒ active

"I believe this bug report can be closed if tablature input indeed works with Shift+[number] in AZERTY."

You do not think about it seriously, I hope?
Have you tried to enter a score in TAB staff with Shift + number each time? You will understand the pain quickly.
Personally, I will give up permanently the 3.0, and I will return immediately to the current 2.3.2 which works perfectly with AZERTY and Windows.

Then, thank you for your investigation. But the main question remains unresolved (see: https://musescore.org/en/node/269507#comment-820487).

And so, can you explain please why it works perfectly on January 4, 2018 with the mentioned nightly (see the first animation).

And why it is broken the next day, January 5, 2018, with another nightly (second animation). With the same symptoms and the same computers, and the same AZERTY keyboards?

1) Tested with: c00d333

Video1.gif

2) Tested with: 3ae66a6

Video2.gif

Reply

• Nov 21, 2018 - 17:13
Title Entering numbers and navigation are broken in TAB staff ⇒ Entering numbers and navigation are broken in TAB staff [AZERTY keyboard]

Reply

• Nov 21, 2018 - 17:17
Title Entering numbers and navigation are broken in TAB staff [AZERTY keyboard] ⇒ Entering numbers and navigation are broken in TAB staff

Well, tablature input does not work for me with AZERTY in 2.3.2 too. This makes it more difficult, I should probably try testing it on Windows. I will have a look at this and the given commit range, I do not know currently what could be the reason for this change.

Reply

• Nov 21, 2018 - 17:18
Title Entering numbers and navigation are broken in TAB staff ⇒ Entering numbers and navigation are broken in TAB staff [AZERTY keyboard]

Didn't refresh page again...

Reply

• Nov 21, 2018 - 19:48

Cadiz1, do I understand correctly, that in both cases (GIFs) you attached keyboard prints numbers in a text editor without holding Shift?

Are you using physical keyboard with azerty layout or this is the layout selected in OS?

Reply

• Nov 21, 2018 - 20:03

"you attached keyboard prints numbers in a text editor without holding Shift?"

In a text editor? Absolutely not, why would I do that?

"Are you using physical keyboard"

Of course, as always.

"with azerty layout or this is the layout selected in OS? "

My keyboard (s) are organised physically with AZERTY layout.

About the "layout selected in OS", I don't understand what you mean. I let always the default configuration, and this has always worked in MuseScore, but not since in the 3.0 et January 2018.

Reply

• Nov 21, 2018 - 20:41
  1. If you open text editor and press keys from the numbers row without holding Shift, do you see numbers or special symbols?
  2. We don't have physical keyboards with preset azerty layout in the market. It means we emulate azerty layout using Operating system settings. So, I tried to reproduce the issue with physical qwerty keyboard, but virtual azerty layout. As dmitrio95 said, it led to printing special symbols when I pressed numbers and printing numbers when I held Shift.

It is pretty hard to reproduce the issue without physical azerty keyboard, so please give us as much information as you have so we could reproduce the issue and fix it asap.

Could you please change keyboard layout in Windows' language settings to Qwerty English layout and try to reproduce the issue?

Reply

• Nov 21, 2018 - 20:47

I wonder whether there exist some keyboards that indeed have non-standard keycodes mapping just to achieve a particular keyboard layout. I don't know for sure but I believe it is most probable that this layout is chosen on OS level and is a default layout to French flavor of Windows.
A particular keyboard can have key labels corresponding to AZERTY layout but this doesn't necessarily mean that it is internally somehow different from other keyboards.

Reply

• Nov 21, 2018 - 21:00

@Anatoly. Please, I demonstrated through GIFs that something has changed in January 2018. And you continue asking me things that I do not understand well. Please, see this now with another guy who would use Windows and an Azerty keyboard.
It's starting to go beyond my strength for me, sorry.

Reply

• Nov 21, 2018 - 21:30

"Well, I'm always puzzled.
I can make it work now but by adding the Shift key: Shift + 1 for fret 1, Shift + 2 for fret 2."
Aha, so what I expected to hear, but had to dive into the history of this thread.

Reply

• Nov 21, 2018 - 21:39

Sorry, but again simple question to @cadiz1. When you see the issue in MuseScore, what is the result of typing the same keys but in a text editor?

I will check the AZERTY layout on Windows tomorrow.

UPD: few links on the same issue from different sources:
https://scratch.mit.edu/discuss/topic/73854/
https://forum.manjaro.org/t/type-numbers-with-caps-lock-using-azerty-ke…
http://www.wadjeteyegames.com/forum/index.php?topic=2123.0

"Numbers are not prioritized
Writing the numbers on a French keyboard requires using the shift key each time.
That means the AZERTY keyboard prioritizes things like the accented letters (such as é) and brackets - and even the ampersand (&) over numbers. "
from https://www.thelocal.fr/20160120/what-annoys-expats-the-most-about-the-…

"Note:
The number row is Inverted. To type numbers, you have to press Shift key."
http://xahlee.info/kbd/french_keyboard_layout.html

Reply

• Nov 21, 2018 - 21:49

According to my investigation with the links attached above, I would say that current behaviour is expected.

The actual question is why it works for you in MuseScore 2.3.2 and the version before January, 5, 2018. It looks like Qt Company did fix some bug related to AZERTY keyboards and now it works as expected.

Possible proof of my assumption. Numbers worked in Qt 5.6.3 but did stop in Qt 5.9.5:
https://bugreports.qt.io/browse/QTBUG-68538?attachmentOrder=asc

UPD: and one more https://bugreports.qt.io/browse/QTBUG-57938

The only way for us to fix it quickly is to try Qt 5.12.

Reply

• Nov 21, 2018 - 22:13

Actually there are a lot of ways to fix it quickly :) I would rather consider options that work regardless of Qt updates. We can do mapping by keycodes rather than symbols (at least for number keys) or even define specific shortcuts for AZERTY layout (we even already have a separate shortcuts.xml file for that layout).

Reply

• Nov 22, 2018 - 09:15

  • In a text editor (LibreOffice), I get - see GIF below.

  • With MuseScore versions 2.x (in TAB):
    First row: 12345 etc.
    First row + Shift: nothing

  • With MuseScore 3.0 dev (since January, 5)
    First row: nothing
    First row + Shift: 12345 etc.

    Video1.gif

Reply

• Nov 22, 2018 - 09:20

So libre office works the same as MuseScore 3.0, except the latter doesn't take the unshifted ones at all, as they don't make sense on that context
MuseScore 2.x behaves different because of a bug in the Qt version it uses (5.4), that got fixed in 5.9, as used in MuseScore 3.0 as of January

Reply

• Nov 22, 2018 - 09:26

@cadiz1 thank you. So, the reason is simple, Qt which we use to deal with keyboard events, graphics and other things fixed the bug in 5.9 version. So, the current behavior is correct and somehow by design. Because you enter symbol without holding Shift in a text editor, not numbers. You shouldn't expect to enter fret numbers when you actually enter special symbols.

We are working on a workaround to make azerty keyboard users happy :) Btw, there is a couple of workarounds right now:
1. Use qwerty en layout when using MuseScore (very widespread case, because even using Russian layout leads to not working shortcuts)
2. Use azerty layout shortcuts set (you can select one in the Wizard after resetting to factory settings). This shortcuts layout could be adapted to the current behavior but still.

Reply

• Nov 22, 2018 - 10:33
Status active ⇒ PR created

I created a PR that tries to resolve the issue with numeric shortcuts in AZERTY by altering AZERTY-specific shortcuts: https://github.com/musescore/MuseScore/pull/4197

In order to use this you would probably have to restart MuseScore from factory settings and ensure that the correct layout is chosen in startup wizard (either "French French" or "AZERTY"). It should be possible also to load the specific shortcuts file from preferences screen though the first way is probably simpler.

Reply

• Nov 22, 2018 - 13:26
Status fixed ⇒ PR created

@dmitrio95, thanks to take care of our French AZERTY keyboard, I have read your PR and your modified shortcuts_AZERTY.xml, something have question to me:
You have use accentued capitals letters for the numeral line of the keyboard, but we don't have keys for them.
May be, tell me if I am wrong, you would use insteed the lower case accentued letters, as their code are different.
- É should be é
- È should be è
- Ç should be ç
- À should be à

Thanks a lot

Reply

• Nov 22, 2018 - 15:17

@JLWaltener, thanks for reviewing! Concerning those letters, I did not put them into shortcuts.xml manually but rather assigned some of the shortcuts inside MuseScore and applied the produced changes to shortcuts_AZERTY.xml file. It is Qt framework that produced those letters from my keystrokes, it seems to always use uppercase letters for this purpose, so I believe it will restore shortcuts correctly from these letters (and it did so in my tests). So I believe it would be better to try this shortcuts set first. If something still doesn't work feel free to reopen this issue so we could investigate this further.

Reply