I’m starting to design a Kaleidoscope plugin, and I’m concerned about how well it might work for very fast typists (which I am not — I probably manage no more than 40 words per minute). My primary curiosity is about keypress overlap (when one key is pressed before the previous one is released), and in particular how often (if ever) a very fast typist might have more than two keys pressed simultaneously (but momentarily) in the course of normal typing — not counting modifier keys being held.
I’m also curious about the length of time that keyswitches are typically closed (on) during a normal “tap” (as opposed to being held) — again, during the normal course of typing, not other types of input activities, like game-playing.
Does anyone know where I can find data on this topic? Even better — is anyone here interested in helping to gather that data? (I believe this could be done in a number of ways, but the best might be yet another Kaleidoscope plugin, using the serial interface)
Kaleidoscope-KeyLogger could be used for this. It does not timestamp stuff, but you can timestamp on the host when reading, and that shouldn’t make much difference. It logs both key presses and releases, along with coordinates, and from that, you can build some stats about how many keys are pressed at the same time, how often, and what’s the average length of a tap.
This is going to vary a lot from person to person, because tap length depends on not only typing speed, but force too. There are heavy typists (myself included) who bottom out all the time, thus making the tap longer. There are light typists who don’t, and they only press the keys lightly, until they actuate. Their speed may very well be the same.
I do not have much data yet, but from what I can see from my own usage, my taps are in the ~50-100ms range, and when typing fast, I sometimes have more than three keys active. That happens rarely though, it is usually just two or so. But again, this is just about an hour worth of data.
I experienced the same. That’s why the idea to put modifiers as dual use keys on the home row doesn’t work out. No matter how hard I trained to improve my accuracy, I always ended up with several keys being active at the same time, causing strange undesired short cuts being emitted.
As we are talking about timing. @algernon: Have you ever measured the time it takes to process keystrokes when using different plugins or combinations of them. Are there combinations that limit typing speed due to excessive processing or is the atmega always fast enough?
I’m a bit surprised at the “more than three keys active” simultaneously; I had been making an invalid assumption. The problem is a little bit harder than I thought, but I’m pretty sure I still have an algorithm in my head that will just about eliminate the overlap problem with dual-purpose keys that both DualUse and SpaceCadet have, and I think will make it possible to use home row keys as modifiers as well (@noseglasses seems to have correctly guessed what I was planning =).
The exact plugin that I have in mind will be more similar to SpaceCadet than DualUse, but it’s sufficiently different from both that I want to try writing it from scratch. I’m pretty sure I’ll need help to do it right, but I’m going to write up a description of the algorithm and data structures first in a new GitHub repo, then everyone who’s interested can take a look and point out how wrong I was. =P
When you’re typing, and you have multiple keys active at a time, do the key releases reliably occur in the same order as the the key presses?
If so, I’m pretty sure I’ve got an algorithm that will work well. If the order of releases isn’t reliable, I’ve got an alternative algorithm in mind that would work, but would have a very small trade-off, and wouldn’t require any different data structures, so it could be easily user-configurable in the sketch.
From what I see in my logs, yes, releases will occur in the same order as the presses.
On the other hand, there may be cases where this isn’t true. For example, if I bottom out a key, start releasing it, another finger barely actuates another at nearly the same time, the second might release sooner. Mind you, from what I can gather, this should be sufficiently rare. I tried to consciously make it happen, and failed. But theoretically, it is possible.
I got it working a bit quicker than expected: I’m calling it Kaleidoscope-Qukeys, as an homage to “qubits” from quantum computing. The description in the readme was written before the code, so I’m sure it needs updating. Also, it depends on a change not yet incorporated in Kaleidoscope: #255, and one just merged in KeyboardioHID.
So far, yes. But I’m not a fast typist, and that’s putting it mildly. I have tried most of the test-cases I can think of, and it works like I hoped it would. I don’t think I’ve tried overflowing the queue yet… =)
Once it’s a little easier to build, I should ask for a volunteer who can type at least 100 wpm on a Model01 to try it out with a few keys configured to be shift as an alternate on commonly-used letter keys and see if it works well.
It was actually Kaleidoscope #255 that hadn’t been merged yet. But it is now, and there’s a new version of Arduino-Boards that has all the necessary changes, so we are definitely at “easier to build” already.
That’s very gratifying to hear; thanks for testing it out! Can you tell me which keys you configured? (I completely failed to describe how to give proper coordinates in any of the documentation…)
I should note that I haven’t made it easy to configure the timeout yet; it’s currently set at 500ms, but I was hoping to play with it and make it as short as possible while keeping the typing error rate close to zero. (It’s a balancing act between typing errors and using modifiers with external pointing devices, though it occurs to me that one could tap a key that does nothing (Key_NoKey) to force it to the alternate state. That’s probably not worthwhile in practice, though.)
When I was using Karabiner to get dual use “SHFT/e” behaviour, it was possible to tweak things so that the modifier didn’t fire unless there was more than N milliseconds of overlap. That would mean, that if we have the following sequence of events:
D/U down, letter down, D/U up, letter up
Then the firmware would wait a few milliseconds before sending the “letter down” even (or until the dual use key up event, whichever is sooner).
I found that once I got the delay tuned right, it was pretty much undetectable and massively improved my typing accuracy. It’s kind of a more sophisticated debouncing (no, autocorrect, not “denouncing”) algorithm (it would probably be possible to have a universal “de-overlap” plugin that would do this sort of thing for all the keys rather than special casing for dual use).
