Achordion adds a delay before my keyboard RGB LEDs activate on different layers

[kris-anderson]

First of all, thank you for your hard work is putting all of these tools together and making them public. Achordion is significantly making my transition to my ZSA Voyager with home row mods much easier.

Achordion itself is working great. I have only positive things to say about how it is working from a typing experience.

The issue I'm running into is a vanity issue. I have a number of layers on my keyboard, and I assigned each one custom RGB LED values to help me remember what layer I'm on and the little clusters I've created for each layer.

When I compile the stock firmware for my board, the layers activate at what feels like my tapping term which I have set to 200ms. When I hold down a layer key for that 200ms, the LEDs on my board light up for that layer after the typing term length of 200ms.

But when I compile that firmware and include Achordion, I get a different experience. If I hold down most layer keys and don't press anything else, it takes what feels like 1-2 seconds before the LEDs for that layer activate. If I hold down a layer key and immediately press a key on that layer, I get the correct outputted key, and the LEDs immediately change color. That's a long way to say there are no delays with Achordion itself, but rather with the RGB LEDs themselves activating. The LEDs activate as soon as I press a key on that layer, or 1-2 seconds later, whichever comes first.

That may be expected? Even if it is, there is one other strange thing related to this though. If I hold down my r, v, or a keys for layers, I get this 1-2 second delay until the LEDs activate. But if I hold the : key, the LEDs activate in the normal 200ms I was getting without Achordion.

Why is that, and is there anything I can do to "fix" this?

Here is a link to my keyboard layout:
https://configure.zsa.io/voyager/layouts/EMbxA/latest/0

Here is a link to my source files with Achordion being added:
https://github.com/kris-anderson/oryx-with-custom-qmk/tree/main/EMbxA

[getreuer]

Thanks for trying out Achordion and for the report!

Yes, unfortunately such a delay is expected. When a key with "layer switch on hold" (layer-tap) behavior is pressed, Achordion buffers the event until it settles whether the key is being tapped vs. held. Once settled, the event handling resumes, and the layer switch and LED light change occurs. With default settings, this can be up to 1200 ms from QMK core's + Achordion's timeouts, matching you observation that the LEDs take 1–2 seconds to respond.

There are similar delayed effects when typing or using HRMs one handed with an external mouse. See How does Achordion affect delay.

Achordion's timeout defaults to 1000 ms, which is quite long. You could reduce this to, say, 300 ms to reduce the lag while still having decent protection from accidental mod triggers:

uint16_t achordion_timeout(uint16_t tap_hold_keycode) {
  return 300;  // 300 ms.
}

To be more fine grained about it, you could set different timeouts for layer-tap keys vs. mod-tap keys. Or finer yet, different timeouts for specific keys:

uint16_t achordion_timeout(uint16_t tap_hold_keycode) {
  switch (tap_hold_keycode) {
    case QK_LAYER_TAP ... QK_LAYER_TAP_MAX:
      return 300;  // Shorter timeout for layer-tap keys.
    default:
      return 1000;  // Longer timeout for mod-tap keys.
  }
}

Another option is to disable Achordion for layer-tap keys. Do this by returning 0 from achordion_timeout():

uint16_t achordion_timeout(uint16_t tap_hold_keycode) {
  switch (tap_hold_keycode) {
    case QK_LAYER_TAP ... QK_LAYER_TAP_MAX:
      return 0;  // Disable Achordion for layer-tap keys.
    default:
      return 1000;  // Timeout for mod-tap keys.
  }
}