Occasionally does not register that you are holding a key down when detecting chatter.

[ossf3]

When using the program in games if a movement key (wasd) is detected as chatter and you are holding it down it causes the key to not register as being held down. This seems to only be a problem for games as it does not happen when holding keys down in a text box such as notepad.

[mcmonkey4eva]

This is a difficult problem to solve.

Fundamentally, what currently happens is:

• You physically press the key
• The key-pressed-down signal is sent to Windows
• KeyboardChatterBlocker sees the press and allows it through
• The key physically chatters (goes back up and then back down inside the switch)
• The key-released signal is sent to Windows (from the chatter)
• KeyboardChatterBlocker sees the release and allows it through
• The key-pressed-down signal is sent to Window (from the chatter)
• KeyboardChatterBlocker sees that this press came very quickly after the previous keypress, and as such denies it
• You eventually physically release the key
• The key-released signal is sent to Windows
• KeyboardChatterBlocker sees that this was the release from a denied press, and so denies the release as well

So, in short: Press (Allowed), Release (Allowed), Press (Denied), Release (Denied)
What you need to happen would be: Press (Allowed), Release (Denied), Press (Denied), Release (Allowed)

---

There would be two theoretically ways to go about this:
1: Somehow physically identify which actions are related to chatter and which aren't - which is basically impossible, the only reliable detection is by timing, keyboards just don't send enough meta-detail to the OS
2: Reversing the denial logic, such that rapid releases get denied, rather than rapid presses.

That '2' is an interesting option, and at first thought would work... but would then bring up a new problem: ... most key-releases are rapid. This would block a majority of key releases while typing - which would necessitate a followup solution: there'd have to be some form of auto-release logic that waits a specified time, and if the key wasn't re-pressed, sends a (fake) key release*. This has a lot of potential for side effects... including, of course, any buttons in a game that change behavior depending on how long it's pressed (eg if the timer is set to 100ms, and you press W, you can never move forward less than 100ms of movement at a time, which would could be disruptive when you need precision).

* I'm not sure if a fake key-release can be done in a reliable way. It can't at all using normally available methods, though the 'Interceptor' library claims to be able to control lower level signalling like that.

---

The current standing "good enough" workaround is using the Auto-Disable Programs tab as explained here: #11 (comment)

This simply disables the chatter block automatically when you have a game open... it's far from perfect, as obviously there are inputs inside a game that would need chatter blocked still (in-game chat boxes, or special abilities that would get double-activiated, ...) but generally works out well enough - or at least, makes sure you're no worse off than you were without KeyboardChatterBlocker running, lol.

[NickatelbNornkirn]

This happened to me. My current workaround is disabling this program when gaming (where key chatters usually don't matter).

[ahparhizgar]

a third way may be delaying first release for a (usually short) period of time to see if a press occurs. if press occurs simply ignore both release and press. and if it didn't happen, register that release.
the delay may not be a good thing for gaming though.

1: Somehow physically identify which actions are related to chatter and which aren't - which is basically impossible, the only reliable detection is by timing, keyboards just don't send enough meta-detail to the OS
2: Reversing the denial logic, such that rapid releases get denied, rather than rapid presses.

[mcmonkey4eva]

There isn't a way to delay a release (actually forcing the thread to wait would also delay any followup presses/releases as well), other than to block it and then fake it after, which has the same * problem in my post above.

[SevaOnOsu]

having this same problem with measure_from: Release. I might be pressing the key too fast sometimes, even though my threshold is set to 30ms. 125hz keyboard might also be a factor. I think this might be fixed if the program checks if key is held down after the threshold, and if it is, presses the key down.

[xpader]

Looks like it's a difficult to solve.

Current soloution is fast to release a key, but can‘t handle long press when there is chatter happend.

Steps:

• Press a key
• KeyboardChatterBlocker let it pass
• Chatter, key release happend
• KeyboardChatterBlocker let release pass (This is not I want)
• Chatter, key press happend (This is not I want)
• KeyboardChatterBlocker denied it.
• (now the key status is released)
• After a while, I released the key
• Cause current status is released, release is denied.

The disadvantage of current soloution makes long press to a short single press, the advantage is real short single press is very fast.

Another solution steps:

• Press a key
• KeyboardChatterBlocker check this key doesn't have a timer, let it pass, and set a timer, and record current status is pressed for this key
• Chatter, key release happend
• KeyboardChatterBlocker check this key has a timer, denied, and record last status (not current) is release for this key
• Chatter, key press happend
• KeyboardChatterBlocker check this key has a timer, denied, and record last status (not current) is press for this key
• (now the key current status is pressed, last status is pressd)
• After a while timer is ended, check if the key current status == last status, do nothing, else send last status event

Two keypoint:

1. KeyboardChatterBlocker check does this key has a timer, if not let them pass, set a timer for this key, record current status, else denied it, record last status.
2. When timer is time up, check if the key current status == last status, do nothing, else send last status event.

The disadvantage of this soloution is most short single key release will have a delay in timer, and not just do pass or denied, it need delay to send key action, I don't know if this is easy to implement, but the advantage is long press and short press will work normally.

[Hebelios]

I am reviving this thread because it's a similar issue.
my left-shift chatters - so when I intentionally hold it down and it chitters during the press, it will interrupt and ignore the continued button press.

this makes the use of shift in conjunction with other keys incredibly difficult.
Maybe a solution can be found?

maybe a toggle-able option to ignore release when an immediate chatter-press is registered for certain keys?

[mcmonkey4eva]

For shift, maybe just disable the chatter block? under Configure Keys add your shift key and set the chatter delay to 0.

It will allow chatter through, which registers multiple key strokes, but in most contexts that's fine, as shift on its own usually doesn't do anything, it's just a held-or-not state usually, ie it's fine to leave chatter through to allow the held state to be accurate

[Buffeting]

Is it not a viable solution to add a minimum threshold?

On my keyboard, false "press-cancels" get logged as a 0ms chatter delay, while actual chatters get logged as 15/16ms. So adding an option to ignore 0ms delays, or adding a minimum threshold, would solve it, no?

I haven't done programming in a while but I will see if I can implement it and report back with the results if I succeed.

EDIT: Well the actual code took 5 mins to find and add, but something is missing (AxImp.exe) and I couldn't fix it, so I couldn't build. I don't have the time or patience to work on this sort of error, so if someone could please just add a simple 5ms minimum threshold in between the other checks in KeyBlocker.cs and build it, I would appreciate it a lot. (or add a customizable minimum threshold in the program, but that's more work)

if (timeNow <= timeLast + 5) //5ms minimum threshold for testing
{
KeysToLastPressTime[key] = timeNow;
return true;
}

[Emelydia]

I appear to have a similar issue, but it's happening with keys that aren't in my chatter blocking list.

I play Rocket League with KBM, and spacebar controls ball cam. But my spacebar chatters quite a bit (and it's effectively random in both frequency and timing - though for the latter it's almost always a multiple of 15-16ms), so I started using KCB for exclusively spacebar and things went well. I did feel like there was a slight increase in latency for keypresses with KCB running (and maybe a precursor to the next issue), as I had an increase in missflips and empty jumps, and powerslides would randomly be a fraction of a second longer than expected. Apart from that though, everything was fine.

But 2 days ago it started randomly just not registering QWEASD inputs. When pressing/holding a key, it would stop registering the input until I physically released the key and pressed it again. After trying several other things, disabling KCB solved the issue. My inputs were registering as normal again, and the missflips and empty jumps were completely gone. I can't really tell if the powerslides have returned to normal with the state that the servers are in currently.

[mcmonkey4eva]

If you have global threshold at 0 (ie disabled for all keys other than manually configured), it shouldn't be interrupting any other presses. A random change recently would not be caused by kcb though -- possibly a change in rocket league (or relevant anticheat or whatever) altered how keypresses are handled, such that they don't allow third party software between the keyboard driver and the game? (it is unfortunately relatively common for software like this to just not be compatible with games)

Latency change from kcb shouldn't be over 1ms, barring OS shenanigans (which is very possible, OS event handling is weird)

[pNm193]

• Musical instrument is what it sounds like to me. A stuck key/