K100 missing lighting feature - 'parent keys'

[volny]

On the whole, the featureset that comes with iCue is wonderfully powerful. But there's a feature absent that seems so obvious to me that I can't believe it's not already there.

 

I don't know how you'd call this, so I'm calling it 'parent keys'. The idea is that you can assign a lighting layer to a whole group of keys, but which will only be activated by some other key(s). I can think of a number of use cases. Here are two:

 

PARENT KEY: numlock

CHILD KEYS: numpad 1-9

BEHAVIOUR: numpad keys are blue. When numlock is pressed once, all numpad keys turn to yellow. When numlock is pressed again, all numpad keys turn blue again. Crucially, pressing numpad keys themselves doesn't affect this lighting layer. Only the parent key (numlock) can control it.

PURPOSE: always be certain of your numlock status without having to look for the tiny indicator light.

 

 

 

 

 

PARENT KEY:CTRL

CHILD KEYS (GROUP A): D, S, O, P, A, H, F5, F7

CHILD KEYS (GROUP B): All other alphanumeric keys, all other F keys

BEHAVIOUR: Assigned to launch when a particular program is active. When CTRL is held down, CTRL goes pink, as do all the program's most useful Ctrl-based hotkeys (ie. Ctrl-D, Ctrl, S....Ctrl-F7). All the other keys fade to black. Crucially, this lighting layer is only activated by CTRL (not by the alphanumeric keys or F keys...that would be mental).

PURPOSE: instantly see relevant keys highlighted when you press a modifier, while irrelevant keys fade away. Instantly revert to normal once you release that modifier.

 

 

I've managed to achieve something like this second example with a workaround, but it's fiddly to set up and not ideal. The workaround is to assign a gradient with a short startup delay (ie. it starts at 0% opacity and only starts getting bright after ~0.3 secs) to the child keys. So when I quickly TAP the child keys in normal usage, this lighting layer doesn't become visible. When I HOLD the modifier key, the lighting layer eventually does become visible. HOLDING a child key also makes the lighting layer become visible, so I had to ensure that I excluded any child keys that I'm likely to hold (eg. other modifiers, backspace, arrows, etc.). Even though it's an imperfect solution, I can confirm that it's a genuinely useful and cool-looking way to use the keyboard lighting!

[volny]

I put together a short example video:

 

 

CONTEXT: I use Autohotkey scripts to turn Capslock into a modifier, with various hotkeys. Quite a lot of hotkeys; they get hard to remember:

Caps+U/H/J/K: temporary arrow keys (enables moving typing caret while typing without lifting hands off alphabet keys)

Caps+Y/I: Same as above, but for HOME & END

Caps+-: produces a long dash ⸻

Caps+SPACE: produces an extra-long space character ("EM Quad Space")

Caps+Shift+SPACE: produces an extra-short space character ("Hair Space" - good for evening things up)

Caps+Ctrl+SPACE: produces a special space called a "punctuation space" (it doesn't act weird in right-aligned text in programs like Photoshop the way regular spaces do)

Caps+UP: autocapitalises first letter of each word in selection

Caps+DOWN: converts selection to lower case

Caps+A/E/C/L/N/O/S/Z/X: inserts Polish letter Ą/Ę/Ć/Ł/Ń/Ó/Ś/Ż/Ź

 

How do I remember all those hotkeys (and the new ones I'm sure to add in the future)? With difficulty. But not any more. Now when I hold down CAPS, I can see which keys are mapped to hotkeys. The Polish-letter ones are treated as a separate group; they glow red, and fade out quicker, making it easier to see all the other miscellaneous ones.

 

Now if I just created these lighting layers the usual way, it'd be chaos. Every time I pressed ANY key, most of the keyboard would suddenly go black while AECLNOSZX pointlessly popped red and UIHJKYI/-/Space/Up/Down popped green.

 

So I used the workaround described above. I set a long (~20 sec) lighting pattern ("Gradient") to most of the keys to make them go black, red, or green. But this pattern only starts fading in after ~0.3sec. So in regular tapping of keys, the lighting layer stays dormant, and it only kicks in if I HOLD any of the keys (and even then, gradually).

 

There are drawbacks to this metod though:

 

-the effect is slower than ideal, to allow for the ~0.3sec delay.

-If I hold UP, -, or J for any reason, I get the same effect as in the GIF.

-Certain keys that I frequently hold (eg. SHIFT, BCKSPC) must be excluded from the lighting layer, which limits its effectiveness and its flexibility.

-Setting up the Gradient effect is fiddly and time-consuming. You have to get the timing right, and make sure that the colors match up each step of the way.

 

It would be great if there was an extra option for certain lighting effects that let the effect trigger only when the parent key was pressed and/or released. Not only would it make effects like the one in the GIF more effective, but it would allow other ones that are currently (to my understanding) impossible. Such as the Numlock example from my first post, where pressing it once makes all the numbers change color, and pressing it again makes them change back (I don't think the current system would let you do it without them all changing color anytime whenever the numbers themselves were pressed).

[c-attack]

You can do this now, but it involves utilizing the profile switch function to set the numpad lighting (or wherever) as the sub-set lighting element.

 

 

1) Create your normal profile ("Profile A") as you want it in the default state, actions, lighting, etc.

 

2) Go the drop menu as use copy profile to create "Copy of Profile A". In Copy of... go to the numpad and change the color to what you want it to be on shift.

 

3) This part is slightly different depending on whether you are in CUE or CUE 4, but it works the same. Create a new Action/Key Assignment and designate it for "profile switching".

 

4) Add the other profile to the list, check "loop the list", and then go to the Advanced Tab. Make sure "retain original key output" is selected, then go back to the main panel.

 

5) There is a copy function that assigns the Profile Switch Action to all other profiles in the special loop profile list. Click it and the switch should be recreated in the other profile.

 

 

Now when you press Numlock it should take you to "Copy of Profile A" (can be renamed) and there the numpad is blue or whatever color. When you press it again it takes you back to the original with original lighting. This works well for toggle keys like numlock, Caps lock, etc. You also can set this up for "shift on hold" where you profile shift while holding down a key. That may have some use for creating large numbers of trigger macros to G and F keys.

Edited April 2, 2021 by c-attack
usual typos

[volny]

Aha!

 

Thanks very much for the kind explanation. It works like a treat :)

[c-attack]

I should add to this that it is possible to set less complicated color shifts within the normal lighting effects panel. For example, if you want your arrow keys to turn green any time one is held, you can create a "solid" custom effect with a start: on press and stop: on release. This takes place entirely in the lighting effects panel for one profile. However, the catch is the trigger key must be part of the lighting group. So we could have done this with the numlock example above, and numlock would turn the entire keypad blue. However, that also makes ALL the keys in numpad triggers for this. So then I press numlock, it goes blue, but then 7 turns it off again. For this reason it does not work for your purposes but this lighting effect on trigger mechanism may be useful and easier to set up for less complex actions and definitely for single trigger keys.

 

An example of that is caps lock. Any one can set a static color change "on press" and stop "on press" to make Caps Lock turn green when it has been activated. We don't need/want the entire keyboard to turn green and just the caps lock key will work. If you did want the entire keyboard to shift to green but only when caps lock is pressed and not any other key, then we are back to needing to use the profile shift described earlier.

Edited April 5, 2021 by c-attack

[cnschu]

Hi there,

 

it is a great solution so long a syou are not controlling anything else with icue.

Sadly the profiles are system wide, and so multiple profiles would also result in multiple profiles for your fans and other peripherals.

 

so the "parent key" idea is still a great idea.

 

yours sincerly

Christian

[c-attack]

That’s why you use “copy profile” to duplicate the original profile and not create it from scratch. All of the other settings are duplicated as well. It also allows you to tweak those other devices to add additional lighting distinction or leave them in the original state.