We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexProgramming Questions & HelpSyntax Questions › Temporal resolution of key events
Page Index Toggle Pages: 1
Temporal resolution of key events (Read 813 times)
Temporal resolution of key events
Nov 9th, 2009, 2:28pm
 
I need to capture the timing of keypresses with as good of temporal resolution as possible.  I've been testing this with recording pairs of keypresses separated by specified time interval (e.g., 250 ms) and recording the timestamps of the KeyEvents inside the keyPressed() function.  Averaging across a large sample of these keypress pairs gives an average interval close to the original (e.g., 249 ms).  But, the errors (samples with intervals different than 250 ms) seem to be off by increments of 14-16 ms.  

Is keyPressed() tied to the draw loop?

And, what can I do to get better temporal resolution?    
Re: Temporal resolution of key events
Reply #1 - Nov 9th, 2009, 8:46pm
 
There is a function System.nanoTime() you can try. It reports nano seconds. I had some better resolution with this than the millis(). The function returns a long integer so:

Long time_now=System.nanoTime();

I've seen the 14-16ms increment you saw also. This may be due to a rather slow clock that dates back to the Intel 8088.
Re: Temporal resolution of key events
Reply #2 - Nov 10th, 2009, 2:24am
 
liudr is right. For historical reasons, Windows (if that's what you use) increments the system clock only every 15.6ms (IIRC). Bios feedback (keyboard handling) might (or not, I am not sure) be tied to this.
Re: Temporal resolution of key events
Reply #3 - Nov 10th, 2009, 8:48am
 
Thanks for the replies.

I originally used System.nanoTime() in the keyPressed() function, but found that this was tied to the draw loop.  This meant temporal resolution was stuck at the frameRate.  So, I switch to accessing the 'when' variable of the KeyEvent structure.  This is gives the 14-16ms increments (independent of frameRate).

My first test was to record timestamps of keypresses separated by a specified interval.  I just tried a different test: recording timestamps of typing 100 characters and looking across the distribution of timestamps for intervals.  Doing this results in intervals of approximately 7.5 ms.  I guess this confirms the 14-16ms increment of the system clock...

Thanks for the help.  Looks like I found the "as good as possible".
Page Index Toggle Pages: 1