Trying to use the keyboard to control instruments on Linux doesn't work as intended (from searching the Discord server, at least one user complained of a similar issue on MacOS OS X).
In my case, with a standard qwerty layout, "7" is the first key, and "r" is the last key of the octave. (so, the keys for playing the instrument are shifted backwards: 7, 8, 9, 0, -, =, <backspace>, <tab>, q, w, e, r). I am unsure whether those are universal for Linux or specific to my system/keyboard.

From my understanding, this bug comes from these two lines:

GLFW Documentation: (emphasis mine)

The scancode is unique for every key, regardless of whether it has a key token. Scancodes are platform-specific but consistent over time, so keys will have different scancodes depending on the platform but they are safe to save to disk. You can query the scancode for any named key on the current platform with glfwGetKeyScancode.

Indeed, running xev reports the following:

KeyPress event, serial 34, synthetic NO, window 0x4400001,
    root 0x53f, subw 0x0, time 144219998, (1,376), root:(2090,422),
    state 0x0, keycode 16 (keysym 0x37, 7), same_screen YES,
    XLookupString gives 1 bytes: (37) "7"
    XmbLookupString gives 1 bytes: (37) "7"
    XFilterEvent returns: False

[snipped for brevity]

KeyPress event, serial 34, synthetic NO, window 0x4400001,
    root 0x53f, subw 0x0, time 144099122, (-74,368), root:(2015,414),
    state 0x0, keycode 27 (keysym 0x72, r), same_screen YES,
    XLookupString gives 1 bytes: (72) "r"
    XmbLookupString gives 1 bytes: (72) "r"
    XFilterEvent returns: False

That is, the code 16 corresponds to the key for "7" on a standard QWERTY keyboard, and 27 corresponds to "r" - which aligns with observations.

Thank you for the explanation

This should be fixed in 1676b4c (1.19.2-1.1.0 and 1.19.3-1.1.0 on curseforge), but I can't test it on other platforms, so let me know if it doesn't work