STROKE stops responding on hotkey-events

[corrision]

hi. can i start by saying your work is outstanding. i use your modules every time without fail.

my only issue is sometimes the midicat and stroke which i have assigned to keyboard commands and Behringer xtouch, lose their connection and i have to reassign.

with the midi cat just a case of reselecting the midi driver, but with stroke i need to reassign each key

not a massive issue, but think im supposed to mention it ;) i can get by re-assigning :)

i have a feeling it is something to do with behringer ???

keep up the good work !

[stoermelder]

Hello. Re-selecting MIDI device drivers is a known issue which affects all modules using MIDI. I’m afraid I can’t do anything about that and needs to be fixed in Rack or the used driver-backend (rtmidi) https://github.com/VCVRack/Rack/issues/1661

Can you explain the problem with STROKE a bit better? Are the keyboard slots empty or how does it behave?

[corrision]

no worries, i figured as much.

so with stroke, i have a few slots filled assigned to my qwerty keyboard. (some zoom, a couple of triggers, a cable colour and a cable opacity)

after a while, and seemingly randomly, they keys stop being assigned and i have to re-learn all of them Stroke still displays the assigned keys after it looses connection

i must say though, im not moaning, far from it, i love the modules !

[stoermelder]

To be honest I don't know what to do right now. I never heard that someone experienced this behavior nor can I imagine what happens. Technically there is no "connection" between the module and assigned keys: the module listens on every key-event and if some pressed keys match a slot it executes the action or creates a trigger or something. That been said you should notice that the event system of Rack depends heavily on the mouse pointer position: If you hover your mouse over a module which responds to the "R" key for example and you mapped some slot of STROKE also to the "R" key the event will be handled by the module your mouse is hovering over and not by STROKE. This is by design and STROKE makes no attempt to break this system.

I'm closing this right now. If you are able to provide some more insights what could be happening I will gladly re-open the issue.

[xandramax]

Here's a patch (BrokenStroke.vcv) which, on my end, consistently loads in a state wherein Stroke displays two mapped keys but does not respond when either of them is pressed. I'm curious to find out whether this patch also misbehaves for you.

I've also attached a second patch (HalfBrokenStroke.vcv) which was made by opening the first one, remapping the first key only, then saving. This one consistently loads such that the first mapped key responds but the second key doesn't.

Unfortunately I haven't yet been able to determine what causes Stroke to enter this state.

StrokeBugExamplePatches.zip

[stoermelder]

Thanks, that was helpful. Two issues fixed:

1. "Num Lock" is a key modifier in glfw like Shift, Ctrl and Alt. I did not know that. This caused "loosing" all mappings after toggling Num Lock.
2. Numpad keys return a different key code.

[Petervos2018]

I think the last update f9c65e4 broke something, I used to be able to start/stop with the space-bar connected to run from clocked, but this does not work any more, went back to af7eab and all is well again. W10, if you need a patch, just let me know. Greets Peter. PS as it turns out "nothing" works any more I also had numbers 1 to 4 (on the num-pad) assigned to functions and they do nothing at all.

And, yes I can break the old version by turning off numlock then all the numbers on the num-pad don't work and even the space-bar does not do its thing.

Personally I always have numlock turned ON.

I don't think you are going to fix this, :(

[stoermelder]

Well, while I fixed the num-lock/numpad issue it may broke some patches, depending on your num-lock state and numpad usage. Presets of STROKE are now corrected on load.

[Petervos2018]

560ab02 works 👍 , thanks