Use key scancode instead of key character #124
Conversation
|
I can confirm your proof of concept works on macOS! At least on a standard-layout US MacBook. I use a Colemak layout by default, and the scale played as expected. |
|
This is great! Then I think we can merge this after tidying up the code. I'll get back to it soon. |
|
As mentioned in #136, this doesn't entirely fix the issue for users who have a physical keyboard with the layout hardcoded. (like my keyboard). I have a qwerty layer defined but it's far from ideal (with typing and all it's very confusing). Many other programs (I'm looking at you zynaddsubfx and renoise) also have this issue. |
|
|
||
| // bail, if a modifier is pressed alongside the key | ||
| if (event.ctrlKey || event.shiftKey || event.altKey || event.metaKey) { | ||
| if (event.ctrlKey || event.shiftKey || event.altKey || event.metaKey || event.repeat) { |
There was a problem hiding this comment.
I'm gonna add the change from this line to the repo and possibly refactor this line into a function
|
Some keyboards have an extra key to the left side of |
5 participants
Currently, scale workshop uses the property KeyboardEvents.which (deprecated name of KeyboardEvents.key), this makes key identification dependent of the user's keyboard layout.
However there is now a more appropriate property which is KeyboardEvent.code, which gives the physical position of the key.
Right now I have just added some keymapping code to synth.js as a quick proof of concept, so I can get guidance on how to actually implement the change.
I have some doubts about how MacOS handles the .code property however.
According to this, it may not give the actual physical key position, but I may be misunderstanding the statement.
If a MacOS user can check if my fork works with different keyboard layouts it would be very useful.
If it works on MacOS, I don't see a reason to keep the keyboard layout handling code/dropdown. Otherwise, it may still be needed as a special case.
EDIT:
#123
Bonus, I haven't implemented it yet but it should be easy to accommodate for differences in the ISO and ANSI layouts with this change.
#114
Also, actually, even if this works on MacOS, some layout handling code may still be needed because of odd keyboards that don't follow the standard ISO/ANSI shape. I think the right long term solution for this is to allow the user to remap any scancode to any position on the grid (or not necessarily a grid), but this will be for a later PR. #31