Sensing Chords By Length Between Letter Presses Rather Than Time Held

[Danc2050]

I may be misunderstanding, but it seems that a chord is determined to be a chord by measuring how long two or more keys were held at the same time?

    ; if at least two keys were held at the same time for long enough, let's save our candidate chord and exit
    if ( start && chord_candidate == "" && (tick_up - start > settings.input_delay) ) {
        chord_candidate := chord_buffer
        final_difference := difference
        ...
        return
    }

Instead of using this to identify/rule out a chord, what do you think about measuring the time in between key presses? So if I chord th to where output the, then the time in between the letter being pressed (t h) determine if it is a chord or not?

The reason I mention it is because sometimes I do type very fast (or fast to some, ~125WPM) and trigger a chord when (how...How...How... like so hahah) I do not mean to. I'd rather not have to choose between "type fast" and "chord slow" (set detection delay to high) or "chord fast" and "type slow" (set detection delay to low).

Anyways, just nitpicking here and thinking. Obviously this tech has a lot of features and is usable and has lots of potential too!

[psoukie]

Thank you for taking the time to think about this and dig through how it works. The following might be a bit technical but I am really interested in understanding your idea.

To illustrate what information flies by ZipChord as we type, I just quickly wrote a short test in the debug version of ZipChord, and all I did was write (not nearly as fast as you can) without any chords:

"That's amazing"

You can look at the attached raw input.txt for reference.

The test automation console is able to print this out in a more human-readable, summarizing the duration of either each isolated key, or of potential "chord" combinations where two or more keys overlapped for a period of time:

>show sample.in
 +th              47
  ha              16
  t               94
  's              31
  s               31
  a               93
  ma              15
  z               63
  i               78
  ng              78

(In the attached file, you can see the absolute times, so you can also see the time in between presses, the time of key being pressed down and the key being released.)

So even though I'm just typing, you can see in the raw text file I attached (and interpreted above) that I released the key T (which was pressed with Shift, hence the + sign) only 47 milliseconds after I pressed H, and the H also overlapped with A for 16 milliseconds. And more overlaps with apostrophe and S, M and A and N and G. The reality is, most people type in a way that the keypresses (as registered by the hardware and firmware of the keyboard) overlap, even while not chording.

ZipChord uses a few tricks to get the detection delay as short as possible: it normally does not allow chords in the middle of a word, so even though I was lazy lifting my fingers quickly enough at the end of "amazing" with a 78ms overlap of N and G, if I had a chord in the dictionary for N+G, it would not be triggered at a 70ms delay because I'm in the middle of typing a word.

The other trick is to reject "rolls" -- so even though T overlapped with H at the start of the word and could trigger a chord if the detection delay was short (47 ms here), ZipChord knows not to do that because the 'roll' continued with A which overlapped with the H.

Let me know if this helps and if you could rephrase the suggestion using the terminology of time stamps of key being pressed (KEY DOWN) and released (KEY UP), and potential free time between keys. You can also record your own example using the Debug feature on the About tab of the Developer version of ZipChord.

[Danc2050]

Thank you for further explaining how to test this and gain more insight into ZipChord. It seems this testing is a perfect time to have this conversation and make Zipchord performant since you have done all this testing work to tell you what is and is not performant.

I'm having a little difficulty using the debug system to get the same results you have. I downloaded the latest release version. I enabled debug in the about section. I get a single file (debug.txt) with an output like this (just showing the input):

Input
-----
0	~+t
109	~+t Up
312	~h
375	~i
406	~h Up
453	~s
469	~i Up
531	~s Up
547	~Space
609	~Space Up
641	~s
641	~i
719	~s Up
750	~i Up
1312	~a
1406	~a Up
1406	~m
1484	~m Up
1484	~a
1562	~a Up
1594	~z
1656	~i
1672	~z Up
1703	~n
1750	~i Up
1750	~g
1781	~n Up
1828	~g Up

I see the .in files created temporarily. So my question would be how to get the .in file like you have it there.

I also am interested in this test console, but when I click on that, nothing pops up. It could be some issue with my machine. I clicked off all my other AHK scripts just in case it was that. I'm wondering if I downloaded the wrong version perhaps.

[psoukie]

I think there's an issue where if you run the Debug from About tab, the console won't open afterwards. Try quitting ZipChord, opening it again and opening the console.

The debug feature is on purpose to make it easy for people to have just one file, so the .in .out and .cfg files get combined.

In the console, you would say "record input test" and it would save the typing into "test.in"

You could then list it using "show test.in" or "show raw test.in"

But the raw data you posted is pretty straightforward to read. It gives you a time stamp in milliseconds when a key is pressed and when it is released (if it says " Up"). So you can work out the overlaps. The console just prints it in a nicer form.

[Danc2050]

OK I'll try to look at the output later this weekend.

I was able to get the test console to appear upon exiting ZipChord and then starting it up again and immediately right-clicking on test console (other situations, couldn't get it to work).

I was able to use record input test, but after the test I pressed ctrl-X and it did not save any output to the file.

[psoukie]

Thank you, I didn't notice that the functionality got disrupted with the other changes I made. That's why I needed to create the testing automation :D Beta 2 fixes this issue. (On the other hand, Windows Defender is now thinking that both the new version -- and backwards also the previous -- now contain viruses, even though the detailed listing shows there is no virus in any of the files, it only somehow finds the zip file suspicious, so I am trying to solve that with them.)