After a long time I started working on my firmware sketch again. Finally I found the time to try out Qukeys. There are some minor difficulties I ran into that I hope some other experienced Qukeys users might help me with.
I want to put modifiers on the homerow, say shift on F and J (QWERTY). With the standard settings taken from the example for timeout (200) and release delay (20) this does not work as expected. When I intent to type capital F and G, in most cases the letters end up lower case. Is there a general problem when combining keys that are both Qukeys or are there maybe better values for timeout and release delay that I could use?
Another problem that I am facing is that I have a Qukey that shifts to a higher layer where the same key is supposed to be non-transparent. It seems as in such a scenario, the shifted-to layer gets stuck. Is that a known limitation or am I doing something wrong? I found an old thread that seems to be related.
[Edit: In the first version of this post I wrote F and G. I actually meant F and J, which means that I place the Qukey shift on both forefingers.]
Regarding the timeout settings — When you try to type F, are you seeing just one letter (f) when you do it, or are you getting both (gf)? I’ll see if I can come up with a solution, or at least an explanation. Am I right that your habit with modifier chording is to release both keys simultaneously?
Thanks for the quick reply. I tried #505 and #502. They both independently seem to fix the shiftToLayer-problem. That’s great news.
Don’t worry about Papageno. Due to a lack of time I had to abandon the work on its Kaleidoscope-integration last summer. Back then I could not find a way to get it working without changes to Kaleidoscopes hid report handling. In the meantime there were quite some changes to the firmware and lately I have followed discussions about alternative strategies for hid reporting. I am happily using a ErgoDox EZ with Papageno integration. With QMK it was comparably easy to get things working. I hadn’t expected it to be that complex with Kaleidoscope whose architecture I favor.
In the meantime I am looking for a keymap that gives me all that I need without Papageno and Qukeys seem promising.
Regarding your questions about my typing habits. Those are difficult to answer. I will use a MIDI sequencer software to analyze my typing. Based on those bar-diagrams I might be able to answer your questions.
Re: Papageno and HID report handling – it’s conceivable that the problem is the mid-cycle reporting problem. If so, I’ve also submitted a few PRs to give plugins to safely send reports mid-cycle without dropping information from keys that haven’t yet been processed. If that proposal gets adopted by Kaleidoscope, do you think Papageno might become practical?
Right now I am lacking time to really concentrate on Kaleidoscope/Papageno. That’s why I cannot really answer your question. I submitted a PR #311 last year that was meant to add what I needed. But maybe there is a smarter, less intrusive solution. I hope I can get back to this soon and then I will think it over.
Aha! Unless you’re somehow failing to engage the G fully (which seems highly unlikely), that’s a bug, so it should be fixable. The only other way you should get just f is if you hold G long enough for it to time out (i.e. 200ms), then release it before pressing F. Also highly unlikey.
I will try to fix it today. Can you provide a link to your current sketch?
I do…but as I’m just finishing the third of my three “essential” Kaleidoglyph plugins, I still haven’t got around to using my Model01 as my primary keyboard, so I do very little actual typing on it.
Also, I’m certain that I type very, very slow compared to you. Top speed (unsustainable) for me is maybe as high as 40wpm, and I’m habitually very deliberate about releasing modifiers after the keys they modify.
I did some more typing experiments. Sometimes I get only one lower case key, sometimes both. That’s why I would like to record as precise as possible what I am actually doing. Last year I successfully used my keyboard-simulator to track down errors in the Papageno-integration. This could also help with Qukeys if it is actually a bug. But for this to work I need precise measured data of cases where something actually goes wrong.
I will start a new topic, asking for ideas about how to measure key sequences. As long as I am not sure what’s going on, let’s treat it as a timing issue, thus no need for you to start fixing it.
I am not a very fast typist as well maybe around 60wpm and I am probably quite sloppy. But I don’t mind doing some training to get accustomed to something new.
I’m not as adept as I ought to be with debuggers, so I generally puzzle things out in my head while looking through the code (more or less, I run an emulator in my brain). So I’ll probably start looking at it anyway, but I’ll wait for more information on the trigger if nothing occurs to me right away.
The main thing that should help make Qukeys work reliably is always releasing the modifier after the modified key. I did my best to make it work for “simultaneous” releases, but there’s only so far that will go.
This bug is probably a corner case involving the release grace period, which didn’t even occur to me would be useful because of my own habits.
If I type the two Qukeys for shift (assigned to the two forefingers in homerow, F and J on QWERTY) in a sequence press F (that’s supposed to be the modifier), press J, release F, release J the keyboard outputs nothing. This appears to be, as far as I can reproduce it, independent of timing. No matter if I do it fast or slow, no key is output. On the other hand everything works as expected if the key whose character is supposed to be capitalized is not a Qukey.
I had to comment out FunctionalColor from your sketch because I was getting linker errors, and I’m using my fixes for the Qukeys layer-shift bugs (#505) instead of the master branch of Kaleidoscope, so I may have an important difference in my version of your sketch, but I’m suspecting this could be a configuration issue.
If I’m fast enough, I can get both letters, but if I’m a bit slower with both keys, I get just the modifiers. When I turned up the timeout value to 1s, like so:
Qukeys.setTimeout(1000);
…I could more easily control the timing, because the qukey wouldn’t fall into the alternate state prematurely, and I got all the expected behaviours.
The Qukeys timeout is mainly there so that you can use a Qukey as a modifier in combination with another input device (i.e. modified mouse clicks). It’s not meant to be the factor that decides which state the Qukey falls into – ideally, that’s only determined by the order of key press and release events. So it’s generally okay to set it to a pretty high number if you don’t mind waiting a bit to use those modifiers with a mouse (or whatever).
I recommend trying out higher timeout values and see if that helps. Maybe FunctionalColor slows down the scan cycle by enough to have an effect, though I doubt that. It’s also possible that it has some interaction with Qukeys, but that also seems unlikely.
Increasing timeout to 1000 ms already helps a lot. Now as I know in which order I need to release the keys to generate uppercase letters, I will train a bit. Let’s see if this is more successful than the attempt I made two years ago with Dual Use keys on QMK where I finally gave up.
I finally moved shift back to the thumb keys as you suggested. The other modifiers on the remaining fingers of homerow are less problematic as I tend to enter chorded shortcuts much slower and less sloppy than I usually type. Only in rare cases I accidentally enter a shortcut and suddenly something unexpected happens (like the editor trying to close a window with unsafed work ) but I am getting more and more accustomed to this setup and find it pretty convenient. It feels much better than what I had when I tried the same with QMK and DualUse keys.
Qukeys are really great. Thank you @merlin for all the work you put into their development and maintenance!
) but I am getting more and more accustomed to this setup and find it pretty convenient. It feels much better than what I had when I tried the same with QMK and DualUse keys.