Keywait has Delay?

[CAH9t]

Just try Pretty simple experiment (hit it real fast and note the delay between presses):

Code: Select all

LCtrl::
keywait,LCtrl
tooltip, % A_TimeSinceThisHotkey
return

Then compare it to

Code: Select all

LCtrl::
tooltip, % A_TimeSinceThisHotkey
return

I'm experiencing pretty heavy pings from keywait (average 100ms, real timings should be 20-50ms at quick pressing) and no ping at all (of course) in the second example. What I've tried to reduce that ping: no matter the key ; getkeystate alternative, "LCtrl down:: LCtrl up::" cunning alternative. Results and numbers are the same anyhow.

[Helgef]

I'm not sure I understand what you mean. Your examples behaves as I expect. Are you aware that keywait,LCtrl waits indefinitely for Lctrl to be released? You will not see the tooltip before you have released Lctrl.

[Exaskryz]

I don't think KeyWait has any inherent delay, but there may be a keyboard driver level delay. I get timings as low as 47 milliseconds with your first code block.

Try this.

Code: Select all

LCtrl::
Sleep 500
start:=A_TickCount
keywait,LCtrl
tooltip, % A_TickCount-start
return

I am getting back times of 0, but I've given myself plenty of time to release the key before it tried to capture a time and check for the key to be released.

Even if you use a Sleep 50 I'm able to get the KeyWait to process in <15ms and thus report as 0 ms in the tooltip.

[CAH9t]

I'm not sure I understand what you mean. Your examples behaves as I expect.

I'll try again . The code shows the realtime delay between the reaction of keywait on event "Lctrl released", which should be zero, but it's obvious that it's much more (time difference between real quick press\release i.e. 100ms (quick keypress with keywait reaction) minus actual time 20-50ms that should've been displayed). It's about life delays between presses of Lctrl (they should be as I said 20-50 per press) and delays that are produced by keywait command - which are significantly higher (two times, wow ) in my case (~100ms per press ) . But they should be 20-50ms . I don't know how to make it more explicit.

So what are your delays when you trying my example?

[CAH9t]

I don't think KeyWait has any inherent delay, but there may be a keyboard driver level delay. I get timings as low as 47 milliseconds with your first code block.

Hi, Exaskryz, "as low as" and "average" are the serious differences here, I've got as low as 32ms , but the average time is about plus\minus hundred ms.
And in ahk case you're gonna have to deal with averages.

I am getting back times of 0, but I've given myself plenty of time to release the key before it tried to capture a time and check for the key to be released.

Even if you use a Sleep 50 I'm able to get the KeyWait to process in <15ms and thus report as 0 ms in the tooltip.

An interesting experiment of yours. I think it proves that keywait has (after all) some inherent delay (kick-in time, you name it) . Just about those afore-mentioned 50ms. Or at least something produces that delay but I'm at loss what it is. Cause the code is as simple as it gets.

[Exaskryz]

My average is 77ms vs 47ms. So, take that as you will.

What I mean is that I am not physically able to click and release a key faster than 47 milliseconds. Maybe it's a limitation of the keyboard (digitally or physically; such as if the contact against the conductor or whatever it is under there doesn't release itself for at least 30ms).

I'm able to get it to work with LButton and get a 0 in your original code. Average of 31.

Code: Select all

~LButton::
keywait,LButton
tooltip, % A_TimeSinceThisHotkey
return

The fact that my touchpad on my laptop allows me to click an LButton fast enough to register as a 0 in KeyWait, but my keyboard does not allow me less than 47ms, tells me that KeyWait is functioning just fine and that it is the keyboard or keyboard driver with an inherent delay.

[Helgef]

The code shows the realtime delay between the reaction of keywait on event "Lctrl released", which should be zero

The code shows the time between the hotkey triggering and executing the tooltip line, in both cases. Do you see any difference with this code

Code: Select all

LCtrl::return
lctrl up::tooltip % A_TimeSincePriorHotkey

Cheers.

[CAH9t]

The code shows the time between the hotkey triggering and executing the tooltip line

the reaction of keywait on event "Lctrl released" should be zero and

triggering and executing

like you said should much quicker than 77ms average or so (as I said so many times - 20-50ms is the real (I repeat) real-life timing of quick press\release). If you'd type with 77ms average you'd be a very slow typist .

The code shows the time between the hotkey triggering and executing the tooltip line, in both cases. Do you see any difference with this code

Code: Select all

LCtrl::return
lctrl up::tooltip % A_TimeSincePriorHotkey

Course I see no difference, my friend. As I said before I've tried many different and cunning alternatives which includes LCtrl down:: LCtrl up:: combos. It's all the same difference, so that's why I'm here.

Try this (it would be the same result with my alternative, but I decided to use yours, to make you convinced). And Type "papa" really fast

Code: Select all

p::return
p up:: sendInput, p

If you won't type "apap" ( I tried and typed apap as many times as you wish, only when I type very slowly I get "papa") , It would be interesting.

ps. Guys and Ladies, who still here with me you are free to try it too. It may very well erase much of the discussion and improve your understanding of what I'm trying here to say.

[Exaskryz]

If you'd type with 77ms average you'd be a very slow typist .

I don't think so. Average word length is 5(.1) letters. That means it would take 385 ms to type 5 words. Add in a space or punctuation mark for a sixth character = 462 ms if my mental math is right. That means you are typing at at least 2 words per second which is at least 120 words per minute which is considered fast. Apparently the average is 33 wpm, which I'm sure includes elderly and those unfamiliar with computers. However, from Wikipedia:

An average professional typist reaches 50 to 80 wpm, while some positions can require 80 to 95 wpm (usually the minimum required for dispatch positions and other typing jobs), and some advanced typists work at speeds above 120 wpm.[5][6]

[Helgef]

Course I see no difference, my friend.

So it has nothing to do with KeyWait.

And Type "papa" really fast

Code: Select all

p::return
p up:: sendInput, p

Of course you mess up normal typing with that, a is produced on key a down, and p on p up. Try

Code: Select all

p::return
p up:: sendInput, p
a::return
a up:: sendInput, a

You will not notice that script being on when you type just a and p.

When you are typing, eg words, you are pressing and releasing keys simultaneously, you do not have to wait for a key to be released before typing the next. Typing abab... fast isn't done by {a down}{a up}{b down}{b up}..., you do {a down}{b down}{a up}{b up}..., try and see

Code: Select all

#installkeybdhook
keyhistory

[CAH9t]

So it has nothing to do with KeyWait.

Man, Read my first post.

no matter the key ; getkeystate alternative, "LCtrl down:: LCtrl up::" cunning alternative

So it has to something to do with keywait also (and the others) whether you call it or not. It has everything to do with fundamentals that are behind keywait, getkeystate and LCtrl up:: that's why I want some help\advice from big guys. The problem is in the release-event-checking in ahk so it's global.

Of course you mess up normal typing with that

I'm not messing anything. It's just funny (I don't know ha-ha or peculiar) that you've encountered the problem by yourself and still arguing that it exists. The people type just like that p down p up, a down a up, just very quick, they're the basics of typing without typos, please, don't argue it, that's an axiom, no offence. And because ahk is still waiting for the release of p while I've already upped it, you type "a" first cause it has no delay caused by the subj.

You may try my test all you want via keywait (the example first post) or getkeystate + while loop, whatever the method you gonna get the same "apap".

Code: Select all

p::return
p up:: sendInput, p
a::return
a up:: sendInput, a

= Is just slowing down two hotkeys. If you want your "workaround" work real-life you should hotkey all the keyboard. It's an OMG-class workaround.

Are you still arguing that ahk do not catch key-release event simultaneously and there is some delay about 50ms? Cause you have all the proves in the world. We may work on the solution not self-deception.

Dear Helgef, please, be constructive, I'm not trying to put down keywait or ahk or something else. It's just basic thing that needs to be solved or developed.

[Capn Odin]

I am sorry CAH9t but from following this thread, you seem to be in the wrong, you appear to misunderstand what is happening. What is your reasoning behind dismissing Helgef's explanation ?

[Helgef]

Dear CAH9t, I'm suspecting we may have hit the language barrier, I feel that we do not understand each other. Hopefully someone else will understand you and provide help with your issue. Sorry if I wasted your time, I had only good intentions.
Good luck

---

Spoiler

The people type just like that p down p up, a down a up, just very quick,

Maybe

[Exaskryz]

So it has to something to do with keywait also (and the others) whether you call it or not.

Unfortunately, you can't blame it on keywait. Helgef has provided an example where KeyWait is not involved and still you have issues with it. So there is something else, which I suspect it is your keyboard driver, that is causing the problem.

I have also given an example where KeyWait works to your expectations, but you ignored that. It was with the mouse instead of keyboard. That is why I suspect the keyboard driver is "the problem".

So it has to something to do with keywait also (and the others) whether you call it or not. It has everything to do with fundamentals that are behind keywait, getkeystate and LCtrl up:: that's why I want some help\advice from big guys. The problem is in the release-event-checking in ahk so it's global.

Can you provide an example where using something other than AHK allows you to achieve what you are looking for?

[Noesis]

CAH9t, I'll attempt to explain it to you in a different way. It appears in your first & second posts you seem to mistakenly think you have two scripts measuring the same thing. To put it bluntly you don't.

The first script is measuring the time between the key being pressed and then subsequently released, and it is due to keywait because that is keywait's purpose, it stops the execution of the later commands, until the key is released (it's not due to some kind of lag with keywait's implementation, it's what that command is meant to do).

Your second script doesn't really measure anything, it immediately displays the time since the key was pressed, after the key is pressed. It stays at zero when held because the hotkey is forever resetting the A_TimeSinceThisHotkey variable. Every time it finishes displaying the tooltip, the hotkey has finished, if the key is still down, the hotkey restarts, so the variable is reset, and the tooltip displayed again.

[boiler]

The people type just like that p down p up, a down a up, just very quick, they're the basics of typing without typos, please, don't argue it, that's an axiom, no offence. And because ahk is still waiting for the release of p while I've already upped it, you type "a" first cause it has no delay caused by the subj.

This is not only not an axiom, it is absolutely false. Although it is possible to type that way, it would make touch typing much slower and very tedious if it had to be done that way. You can even see it in slow-motion videos of people typing. Helgef has proven it to you in several ways, and you refuse to listen or even entertain his demonstrations, apparently.

Similarly, multiple people have taken the time to thoughtfully respond, and you dismiss them. It appears you did not come here for help but rather to prove yourself right. I suggest that if you come to a forum looking for help, you have an open mind and accept the help that is offered rather than being unwilling to look past your preconceived notions.

[CAH9t]

First of all, thank you all involved.
Second. Please, one last time, read it thoughtfully or don't read at all.

From what I see in your response, We're not talking right now. Me in your eyes sorta bad guy trying to badmouth ahk. I'm sorry if it sounded like that. I've been using ahk for quite a time and I've never asked for help or someone to do my job for me because I do it myself, each and every time. That's who I am. Believe me I'm not tend to cry 'wolf' when there isn't one.

Now I've hit the brick wall with the ahk reaction-time on key-release event. As simple as that. What is it there you can't understand? I've given you all the proof in the world and most of you taken it lightly or else I wouldn't get all your "bad guy" response. The code I gave you is primitive you simply cannot change something there. Yet we're off-topcing like there is no tomorrow.

I'm posting it one last time. Last time. In case someone here still has an open mind and volition to think first react second.
The only thing you can do is pass the proving test here, try it and post your results - test passed or not passed (All due respect Helgef neglected to do and Exaskryz did, thank you bro). I already know that I'm a jerk, thank you , you don't have to hint it twice.

Code: Select all

; This is the series of tests to test the reaction-time of ahk on release-key event (keyboard key). The problem is in the release-event-checking in ahk. In my version of tests ahk is unable to catch in time that the first key pressed is released, before I typed the second so it results in a typo ("apap")

; 1st test try to type papa with your fastest type speed ( If your output is "apap", please report it). 
p::return
p up:: sendInput, p

/*
; 2nd test try to type "papa" with your fastest type speed. Don't forget to comment the other tests. ( If your output is "apap", please report it). 
SC019::   ; it's important for the experiment, that SC019 in my layout is a scancode for "p" key. 
keywait, %A_ThisHotkey%
sendInput, {%A_ThisHotkey%}
return

; 3rd test try to type "papa" with your fastest type speed. Don't forget to comment the other tests. ( If your output is "apap", please report it). 
SC019::   ; it's important for the experiment, that SC019 in my layout is a scancode for "p" key. 
while GetKeystate(A_ThisHotkey,"P")
{
}
sendInput, {%A_ThisHotkey%}
return
*/

So, that's it. If you spend a little measure of your time on those tests, instead of whipping my posterior, We will proudly know if it is my case only (which as you can see, I can guarantee) when ahk is too slow on the uptake or it is a global problem that needs ahk-team into discussion.

ps.

Dear CAH9t, I'm suspecting we may have hit the language barrier

Dear Helgef, we were on different pages from the get-go (as in first page and the last one). That's me who is to blame, because I should've stopped trying to explain myself right there, instead of trying to explain simple things redundantly thousand times. I respect your expertise and trying to help. I just thought that if Exaskryz got the drift simultaneously I could've fill you in eventually.

[CAH9t]

77ms average

Friend, you're way quicker than that real-life, trust me. And I presume you're hitting one button very frequent-like so it should be way way quicker than 77ms average. Thank you, again. Till later.

[Capn Odin]

I have not tried your test, and I don't intent to as I feel that I won't have enough control of my typing to infer anything.

As I understood your lestest post the only thing I can think of is that your problem is with the way ahk simulates threads, meaning that if a Hotkey is started while in another one the latest is executed first. You can try using Critical or SetBatchLines.

Edit: scratch that, I dought it has anything too do with this as you are only using one hotkey at a time.

[Noesis]

Ok so I tried your test, and I got papa for all of them. Perhaps like has been stated previously the reason you get apap is due to you not having completely released the p key before pressing the a key ?

If so, this wouldn't indicate lag with keywait, it indicates lag with your finger releasing the key, and to be honest it's normally not a big deal and is to be expected, as typing with some keys only working on the up stroke, and others on the down stroke is only going to increase the likelihood of making mistakes, especially in this day and age where mechanical typewriters are obsolete and one normally doesn't have to worry about releasing a key before hitting the next.

However you seem to be fixated with key down -> up times and I think it is kind of misplaced. With regard to typing fast, It makes very little difference how long a key is actually down for, what makes the difference between a slower vs faster typist is the difference in time between any two consecutive keys being pressed down, so in actuality a fast typist would have almost zero time where there isn't actually a key currently being pressed down. My point is pressing a key down and up fast makes very little difference to typing speed, What should be happening is you have moved a finger to the next key to be typed by the time that other key is released, with virtually no time in between the key being released and the next key being down. Sometimes what happens is the key isn't all the way up before the next it down this is one possible reason to why you consistently get apap instead of papa, I'm not sure if you realise it or not, but if you do you haven't said so, and seem to be a bit too focused on the keys traveltime, which make me think you're only looking at one part of the entire equation so to speak.

Anyway, Like I said I did you're test and I got papa, and then I modified your test and did it again (using the second keywait example after adding a hotkey to view the script's keyhistory) until I eventually didn't get papa (i.e. I just kept typing it with an enter at the end until I got something else).

Fyi: keyhistory reported there were instances of the "p" key's traveltime being 0.02s (20ms) with the script running, and they were also consistent with the "a" keys traveltime within each word, the individual words did vary but fatigue does that after typing the same thing 20 or 30 times.

The time I got the error (paap was the error), it was not due to keywait, it was due to the send, keyhistory showed the ignored/suspended P key (the physical key press) was up 0.02s before the A key was pressed down and the sending of the p keystroke happened 0.00s after the a was pressed down. Then the a key was released

I should point out this delayed send is inconsistent, sometimes it's delayed (I never saw it delayed more than 0.02s) But most the time it's not delayed at all (or at least not on the 100th of a second scale displayed in keyhistory).

Incidentally there was another record immediately prior to the one which produced error above, which other than the times being different, was identical to the one I just described, in that keyhistory showed the final P key was physically up but the A key was pressed before it had sent the p's, but for some reason this didn't produce an erroneous output (and possibly should have), the word still displayed as papa, so... I guess there are factors involved other than just ahk, but that shouldn't really be a surprise.

This of course doesn't actually explain why you get apap all the time, perhaps you should do your own tests and review the keyhistory to find out exactly why you do. But on my machine there is definitely not a lag with keywait, and there is occasionally a very mild infrequent one with sending keys.