Temporarily disable modifiers while executing macros?

General
1

I have an odd situation that I’m not sure how to solve, at least not efficiently. Specifically I want it so when I press the left control on the keyboard, it enables a different layer which replaces the 1, 2 and 3 keys with macro 1, 2 and 3 respectively, but otherwise passes everything else through normally. I also/still want the left control to register as pressed too so I can still use the left control key in key combinations.

Now that part is relatively easy to set up. I add two mappings for the left control key; one for the pass-through and one to enable the layer with the macros on it.

That works mostly as expected but with one unintended consequence… when the macros execute, they are executing with the left control key registering as still being held down (because it is!), meaning for instance if my macro types the the word ‘welcome’ the computer actually receives command-w and instantly closes the window with the focus.

Now the only way I can think to address this is to still map the left control key to trigger the layer, but not map it through. Then using expressions, if that layer is active and one of those three macro keys are not pressed, set a register, then add a mapping for that register to trigger the left control key.

There may be some timing issues there however depending on if you process the expressions before or after you process the mappings. If expressions are processed first, this will work. If mapping are processed first, then I would have to use three more registers to trigger the macros rather than the mappings as that way I could control the order of things.

Now in a perfect world, there would be a setting saying "when executing macros, temporarily disable/release any currently-pressed modifiers (any pressed keys actually) then reset them after the macro is finished executing (or reset things when all keys are released.) This way the macros would execute unencumbered but the keyboard would otherwise function as expected.

Normally I would look into the firmware and try implementing this myself, but the firmware I’m using is your classic Bluetooth ‘beta’ one which you haven’t released the source code for (yet?) so I’m kind of stuck.

Can you think of a different way to solve this?

3

You can make an expression like this:

1 recall
0x000700e0 prev_input_state_binary not /* left control */
0x000700e0 input_state_binary mul
bitwise_or
0x000700e0 prev_input_state_binary  /* left control */
0x000700e0 input_state_binary not mul not mul
0x0007001e input_state_binary not mul /* 1 */
0x0007001f input_state_binary not mul /* 2 */
0x00070020 input_state_binary not mul /* 3 */
1 store

And map register 1 to control instead of the passthrough control->control mapping (on both layers).

This will release control when the macro-triggering keys are pressed.

4

This is great! I like that you’re only considering the rising and falling edges rather than simply checking the current state.

That said, since that register is only ever set on the rising edge, once it’s released via pressing one of the macro keys, you have to release the control key and press it again to turn it back on.

As such, I just submitted a new issue/proposal that would help avoid that. It hopefully should be pretty easy to implement. Hope you like it! (If you do, please also put it in your Bluetooth classic version. Alternately, if you share that code, I would be happy to implement it for you in both places.)