Chording and discomfort

Copy as much as possible from Velotype.

Hi there,
I have also tried spacemacs. I like it though. It’s almost perfect but still young. BUT! Key-chord-mode is awesome. Have you tried it?

A compelling read. Bravo!

At first glance I feel this could interfere with some games, but for my programming this would be a major boon. Being able to enable/disable each of the features you describe is an appealing option.

This vaguely reminds me of how certain foreign language keyboard extensions work. I use the Microsoft IME on Windows and Anthy on Linux to access/compose Japanese characters. These are modal in nature and are sort of like the leader keys you described. I’m not exactly sure what to call this type of input technique, but it’s basically like an autocompletion service helps you compose kana, kanji, and compounds. Composing kana (formed by phonetic mono-/di-/tri-graphs) works very similarly to one-shots. To help with composing kanji/compounds, it maps sequences of kana to compounds (shorter strings of kanji) in any text input by cycling through them with the space bar and selecting with enter. It’s a similar solution to an exaggerated version of the same problem. Perhaps there’s some inspiration to be found in this.

1 Like

Could you possibly respond to my posting “groping towards emacs”. Sorry if I didn’t send this message to you in the proper way, i.e. I’m not sure how to send it privately.

Could you possibly respond to my posting “groping towards emacs”. Sorry if I didn’t send this message to you in the proper way, i.e. I’m not sure how to send it privately.

How can one enable oneshot modifiers in the current firmware? Preferably, with another binding to turn oneshots on and off?

It’d be really nice to have oneshots, but I wouldn’t want them to get stuck, and sometimes they could be counterproductive. So, maybe oneshots with a timeout of ~5 seconds, or oneshots with another key to turn them on and off. Fn-Any could maybe work for that.

In oneshot mode, it seems like it also might be a good idea to override the lighting for the currently-active keys, lighting them up to indicate that the next non-modifier key will be affected. Does anything like that exist?

2 Likes

The OneShot documentation has an example, whose gist is something along these lines:

#include "Keyboardio-OneShot.h"

// Use OSM(LeftShift) in your keymap

void setup() {
  Kaleidoscope.use(&OneShot);
  // ...
}

At the moment, you can’t turn them on and off: you either use them or you don’t. It used to have toggleability, but that made things overly complicated.

If they get stuck, that’s a bug which I would want to fix! As for being counterproductive: for the most part, you can use them as normal modifiers: if you hold them, they will act as a normal modifier as long as they are held (so you can hold an OSM(LeftShift), tap a, b, c and get ABC, as one would expect), and when released after such a hold, it will not activate the one-shot behaviour.

By default, they have a timeout of about 2.5 seconds. If you press a oneshot modifier, release it, you have 2.5 seconds to press anything else before it deactivates.

If you hold a oneshot modifier longer than 200ms, it will not trigger the oneshot behaviour when released.

Both of these timeouts are configurable:

void setup() {
  Kaleidoscope.use(&OneShot);

  OneShot.time_out = 5000;     // 5s timeout for the OneShot effect
  OneShot.hold_time_out = 150; // 150ms timeout for holding
}

Yep! Kaleidoscope-LED-ActiveModColor does just that. If a modifier is active, it will highlight it with whatever color you want (defaults to a white-ish color). It was created precisely for this case, to be used in tandem with OneShots.

8 Likes

I think I’ll have to try this again later… I got it to work, but it was difficult to type due to bugs. It’s possible and likely that I did something wrong though. The issues I ran into were…

  • If I press a mod key, press+release a regular key, then release the mod key, all within the hold_time_out period, the mod key remains enabled and continues to affect the next keypress. For example, when starting a sentence, I often end up with two letters capitalized instead of just one. This does not happen if the order is press-mod, press-key, release-mod, release-key. It’s much easier to trigger this with hold_time_out increased higher than default, like 500ms, but I still run into it sometimes at the default setting. It should probably cancel the oneshot effect on normal keypress, not release.
  • The Fn keys seem to get stuck sometimes, even when not configured as oneshots. Attempts to type then end up moving the mouse or otherwise not producing the intended letters. To trigger this, I can hit Fn+Shift then some other key. The effect does not seem to time out; it sticks until I press Fn again.
  • With OneShot enabled, keypresses frequently get eaten entirely, leading to lots of re-typing. I’m not entirely sure what causes this, but it seems to happen up to ~20 characters after I have used a modifier key. Usually one or two letters disappear out of the next dozen, and not usually sequentially. Like, “algernon” would come out as “algenn” or “lgnron”. Or, rying it just nw, if I press CTrlup, CTrl-down, then type “Algernon”< this is what happens: “algr algr algr”. (note: previous sentence was typed with oneshots active, without correcting afterward, to give an example of the kind of behavior I’m seeing)
  • I didn’t see a way to treat Fn keys the same as other modifiers, with OSM(). Instead I used OSL(1). This doesn’t cause the Fn keys to light up when active like other modifiers do.
  • Without the OSL(1) bit, Fn keys were treated as a regular keypress to cancel active oneshots, so some actions weren’t possible. For example, Ctrl-Alt-Arrow – tap Ctrl, tap Alt, then hold Fn and press an arrow. Touching Fn cancels Ctrl and Alt, so it comes out as a plain arrow.

BTW, what is the difference between USE_PLUGINS(foo) and Kaleidoscope.use(foo) ? Are they different ways to do the same thing, maybe with one deprecated? Is there a difference between “USE_PLUGINS(foo); USE_PLUGINS(bar);” and “USE_PLUGINS(foo, bar);”?

This is pretty cool. Do you think it would be difficult to extend this so it would light up every active key instead of just modifiers? It would look cool to have keys light up while they’re pressed. I’ve got the rainbow wave effect by default, but active modifiers light up brighter and white, which is a neat effect. Would be even better if it happened on each keystroke though, instead of just mod keys.

1 Like

I think I fixed this - at least partially - recently, but will try to reproduce it to see what’s up. This is not the desired behaviour, so there is something fishy going on - will see what I can do about that. Thanks for the detailed explanation, this will make it a lot easier to debug the problem!

OneShots have this feature where if you tap them twice in a sequence, they remain active until a third tap, and won’t be cancelled by other keys. What you describe sounds like you are hitting this, but it should not happen without OneShots.

Will look into it, perhaps it is easier to trigger on the factory layout than on my own.

Ow. This sounds bad. How fast do you type?

Yeah, ActiveModColor only lights up modifiers, not layer keys. There is Kaleidoscope-LED-ActiveLayerColor which does something similar, but it lights up the entire keyboard, not just the key. Perhaps I should amend ActiveModColor to also light up active layer keys…

Good catch! OneShot has an exception for other one-shot keys, so pressing another one-shot key will not cancel the existing one. Sounds like a similar exception should be made for normal modifiers & layer keys too.

They are the same thing now, and USE_PLUGINS is kind of deprecated. In the beginning, USE_PLUGINS was a wrapper around Kaleidoscope.use() that added a trailing NULL, but we do not need that anymore (yay), so USE_PLUGINS is useless. It was kept so that we don’t have to update the whole world yet again.

The difference between Kaleidoscope.use(&foo); Kaleidoscope.use(&bar); and Kaleidoscope.use(&foo, &bar); is that the latter is a tiny bit faster, and compiles down to less code. Functionality-wise, there is no difference.

I think you want something like LED-Stalker, but not as a separate mode, rather as an overlay over the active mode. I think tweaking LED-Stalker would be easier. If you can prepare a change that makes it possible to use it not just as a mode, but similar to how ActiveModColor works, I’d merge that :wink:

Btw, if you want fun effects, try LED-Stalker with the BlazingTrail variant, or the LED-AlphaSquare plugin with the AlphaSquareEffect mode (this one is part of the factory firmware, too!).

1 Like

I have reproduced the issue, and fixed it on Kaleidoscope-OneShot master. I’ll update the Arduino-Boards repo soonish too. The issue was that we cleared a flag too early. With your explanation, it was pretty easy to figure out where things go wrong once I reproduced the issue.

Very nice catch! I’ve been using oneshots daily, for quite a while, and didn’t spot this bug. Having users is awesome =)

6 Likes

Thanks for OneShot! it has been so easy to learn and such a nice change. A couple things I’ve noticed:

EscapeOneShot doesn’t seem to cancel a mod key that has been double tapped. Turning on LED-ActiveModColor made this obvious to me. Is that desired?

I continue having issues with my keypresses being too soft to fully engage the mod keys. Interestingly, if I watch the keys, the LED lights up with my light presses, but doesn’t remain on when I lift my finger. So the keyboard is receiving a signal, but I guess not enough of one to count? Or something? It confirms the “too soft” theory, anyway.

1 Like

The switches are digital. If you’re seeing the light change, it means that the keypress is detected. I’d bet on something around timeouts?

1 Like

I assume it’s a configurable option if I go digging. :slight_smile:

The idea of Escape-OneShot was to cancel the one-shot state only, ahead of a timeout, so cancelling a sticky key is not something I originally planned for it to support. It does feel reasonable to be able to cancel stickies too, it’s a one-line change.

I’ll play with it and see how it feels before making the change. Thanks for the suggestion!

If the keys light up, then the keyboard sees them, and they should register properly. If the light doesn’t stay on when you lift your finger, then the problem isn’t your light touch. Sounds much more like a timing thing.

OneShot uses two timeouts, one to detect when a one-shot key is held, and another to time out an unused one-shot press. The former is 0.2 seconds by default, so if you press a one-shot key for longer than that, it will see it as if you were holding the key, and will not activate the oneshot behaviour.

Can you try adding OneShot.hold_time_out = 1000; to the setup() method in your sketch? This will increase the hold timeout to a full second.

My suspicion is that while your touch may be light, it is also longer than mine, which is what OneShot was calibrated for.

If this helps, and I hope it will, then the next step will be to figure out a better default for OneShot.hold_time_out.

hmm. Will the keylogger record duration of presses? Or is there another method for doing that? I don’t think they are longer than the strokes that work, but they definitely don’t depress the keys as much.

My wacom tablet came with a utility that would tune timeouts, etc, based on input. It would have you do certain actions 10x, and then make recommendations for the settings of certain constants based on your gestures. If there turn out to be several parameters that could do with personalization, a tool like that would be a useful thing.

1 Like

No, it doesn’t, but a small python script can help there, that adds timestamps on receipt.

Most - if not all - of these settings can be tweaked through Focus (and those that aren’t, should be), the possibility to build a tool that would help, is there. Eventually, we’ll even get there!

4 Likes

This is all so awesome. :slight_smile: you folks have built something wonderful, and it’s just beginning.

2 Likes

I feel the need to point out that a large percentage of our docs have been written by…you. So you’re officially allowed to say “we have built something wonderful, and it’s just beginning.”

13 Likes