Much like the old one did, it seems to be when you click out or back into a window while holding a key. Could the node clear its output when the in a window out of the window test happens, or would that be problematic?
hey catweasel,
which sink nodes are you using (like seen in the table here: keyboard-mouse-and-touch-news ?
I noticed it because I was radio matching the keys and they’d stopped working, when I came to look the keyboard had Lwin, or control keys stuck on.
Should I use a key states before the radio match?
ehr, nono. i am not ready to say what you should do really.
sooo. i guess that it is a problem to hold a key when switching between a renderer window and a patch window? for now just trying to make sense of it…
when translating events into some sort of states we obviously loose some information. sometimes events happen so fast that we don’t have any frame in between those two events and some state of the keyboard is never observerd from within a vvvv patch. but this should not be the problem here. i just want to say that events and states in between are different worlds…
when “disconnecting” from an event source (mouse & keyboard (window) only being only “connected” to the device when renderer is active) obviously we don’t get any events any more (like a key up, or a mousebutton up), which makes perfectly sense on an event level, but when translated into states it may lead to stuck key states. well we might need some disconnect mechanism, which may be used by some sink nodes, like KeyStates (Keyboard Split), that may reset their state on time.
anyway. if you could just send the patch to further inspect what nodes you are using it can be of value.
No patch needed, the keyboard node on its own with a renderer will do it, click a renderer, press a key, click in the patch, key is held.
thanks cat! we are working on a solution.
fixed in upcoming alphas
note that the fixed behaviour is only available in the new nodes mentioned over here: keyboard-mouse-and-touch-news