rolling qmk modifiers revisited

saturday, 10 october 2020

with Covid-19 time on my hands, i thought i would revisit rolling modifiers. since implementing my own mod_roll() library to handle rolling modifiers in place of the QMK mod_T() macros (SFT_T, ALT_T, CTL_T, GUI_T) due to issues arising from rapid finger rolls, the QMK library has since been updated to address this. Enter..

ignore_mod_tap_interrupt

by simply adding..

#define IGNORE_MOD_TAP_INTERRUPT

to the config.h file, rolling modifiers are now handled quite proficiently by the SFT_T, ALT_T, CTL_T and GUI_T macros.

Some adjustment of TAPPING_TERM may be required to tighten up its responsiveness so that a roll ending on a modifier sends the characters versus being interpreted as a modifier chord. mod_roll() is more forgiving of this, but in practice, this should not be an issue, occurring only during the most rapid rolls of the modifiers – which were done to test the macro responsiveness, the letter sequences, of which, are highly unlikely.

Results are quite predictable and modifiers keyed in rapid sequence, regardless of originating hand side, register as their assigned characters. If this functionality had existed at the time i migrated to home row modifiers during the refinement of my keyboard layouts, i probably would have left it at that.

mod_roll()

does provide one major advantage for my typing style and that is the rolling shift, whereby, the opposite hand shift key can be released before the next key press is completed and still register as a Shift modifier.

It is a subtle distinction but one that feels more rhythmic to me, versus, holding the Shift key until after the completion of the next letter. This relates to the manner in which i write which is more in fits and starts and a lot of contemplation between. And can be appreciated on the BEAKL Zi layout for example, when starting a new sentence with The by keying a rolling athe sequence.

Of course, this also means that an inadvertent opposing hand roll may capitalize an unintended letter. YMMV. Certainly, on traditional keyboards one develops a pinkie finger rhythm for shifting characters without a second thought. And one should be able to easily adapt to the more stringent IGNORE_MOD_TAP_INTERRUPT approach. It is more a matter of typing style than anything and, as emphasized elsewhere, there is no substitute for good touch typing technique.

Aside from the mod_roll() library itself, there is a bit more work to incorporate it into the keymap.c file to define the modifiers and alpha columns (internal to the function itself). Since the original iterations of BEAKL Zi and corner case cleanup of the mod_roll() function, macros have been defined to simplify the source code for the non-modifier keys in the process_record_user() function..

switch (keycode) { ... #define CASE_ROLL(s, k, c) case k: \ mod_roll(record, s, NOSHIFT, 0, k, c); \ return false #define CASE_LKEY(c, k) CASE_ROLL(LEFT, k, c) #define CASE_RKEY(c, k) CASE_ROLL(RIGHT, k, c) CASE_LKEY(0, KC_Z); CASE_LKEY(1, KC_Y); CASE_LKEY(2, KC_O); CASE_LKEY(3, KC_U); CASE_RKEY(5, KC_G); CASE_RKEY(6, KC_D); CASE_RKEY(7, KC_N); CASE_RKEY(8, KC_M); CASE_RKEY(9, KC_X); CASE_RKEY(5, KC_C); CASE_LKEY(0, KC_J); CASE_LKEY(1, KC_MINS); CASE_LKEY(2, KC_QUOT); CASE_LKEY(3, KC_K); CASE_RKEY(5, KC_B); CASE_RKEY(6, KC_P); CASE_RKEY(7, KC_L); CASE_RKEY(8, KC_F); CASE_RKEY(9, KC_V);

The above key assignments, of course, relate specifically to the BEAKL Zi layout. Refer to the dotfiles for the BEAKL Zi source files and their implementation of mod_roll().

»»  an oasis

comment ?