Strange bug in the MidiKeyboardComponent

Pressing any key on the PC keyboard triggers another key that remains active until the mouse is clicked on it, as can be seen in this gif, in which I press note 72 (key A), and note 89 as well activates

this application only contains that component, and I did it expressly to make sure other code wasn’t influencing it.

The strange thing is that the bug sometimes disappears, and when it does, it does so in the application where the bug appeared initially. It also disappears without knowing the reason, so I waited for it to reappear again to capture it and report it.

From what I have been able to investigate, the note that is active for no reason corresponds to the mapped octave (6) x 12 + 17. That is, 89

That 17 corresponds to the last index of “keypresses”, since I have seen that it currently has a size of 18.

for some reason the last reference (17) of keyPresses is “currently down”. so activate the corresponding note

I’ve tried to trace more, but I can’t follow it. Has this happened to anyone else?

the bug disappears when restarting the computer and appears at another unexpected moment, maybe it could be related to memory

I checked that the list contains an additional key since there are 17 keys, not 18. I think the bug is in the string, it seems that the null character is added, for some reason sometimes that was interpreted as a press key.

I’ve searched and it looks like the loop should be from a temporary string instead of a char array, or better use std::string_view

for (char c : std::string{“awsedftgyhujkolp;”})

I think this was happening to me since the last update

1 Like

this bug appeared again with the last update. please fix this. As I said an additional 18th key note is being created with the null value.

I wasn’t able to reproduce the problem where an extra note gets pressed, but adding a keybinding for keycode zero is likely unintentional so I’ve pushed a fix for that:

If the issue still persists, please try to work out what steps trigger the issue so that we can reproduce and debug the problem.

1 Like

I can’t reproduce it when I want, only in certain sessions, until I restart the pc. But from what I have been able to verify that when this null code was removed the problem disappeared. So the problem is solved.

The fact that the bug persists during a session seems to indicate that it is because of the state of the memory when finally the key is called with GetAsyncKeyState with the value 0, which as far as I have seen this code does not exist, and for some reason sometimes returns true. Since that code corresponded to index 17, the 18th note from C in the current octave was played.