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.
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?
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.
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.
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
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!).
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 =)
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.
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.
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!
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.â