RealAntithesis

Macros and remaps also stopped working for me a couple of weeks ago on my K95 RGB after I had to create a new Windows (10) user profile after it screwed up updating to build 1809. From that point on, macros and remaps didn't work, even after reinstalling. As per the previous post, the Corsair driver had an alert icon on it in Device Manager saying that no driver was installed. Today, I 'repaired' the install and remaps now started working. I'll find out later if it continues to work after a reboot...

It would be great if we can move the iCue Space to another monitor than just the primary (and for it to remember this across reboots). At the moment, I don't use this at all because it just takes up too much space out of my primary work area. I think this feature should receive higher priority too (but obviously behind stability and bug fixes).

In Lighting Effects, there should be a colour option for the current key colour. The colour would then be whatever colour the key happens to be when the effect is run. This way, we could, for example, have a pulsating colour gradient that is activated when the key is pressed, which transitions from the current key colour, to the new colour and back again. Currently, the gradient colours are fixed, which can result is some jarring colour transitions depending on the colour of the key at the time the lighting effect activates.

It would be great if profiles can inherit all the attributes (Actions and Lighting Effects) from another profile. My default profile has various macros, key remaps and lighting effects etc that I want to apply across the board. But setting up another profile for game specific actions results in everything in my default profile being deactivated (so all my lighting effects shut off leaving an unlit keyboard). I know profiles can be copied, but doing this multiple times across many profiles is just rework and doesn't take into account changes to the default that I want to apply generally. Inheritance would should be fairly simple: the current profile takes precedence where it conflicts with its parent (e.g. lighting and macros etc assigned to keys). If the current profile doesn't have anything assigned to a particular key, then the parent (inherited) profile applies for that key. This way, the current profile can have all the lighting effects and macros, key remaps etc of the default profile, except for those actions and lighting effects specific to the current application / profile. Makes sense to me.

My suggestions after using for 1 week on my k95 rgb: 1. Allow macros to contain all the different types of actions, including any actions in the Actions Library and Lighting effects. This will vastly improve the usefulness and power of macros. The interface is already there to do this - just add the other actions to the menu list and drag and drop from the Actions Library. Conceptually, this should be a fairly trivial thing to do in the code - assuming it's been built in a modular way (heck, I even did this scripting a hotkey mod for Skyrim, which is fairly limited at the best of times). 2. Add the ability to specify modifier keys and other key combinations to actions / macros. This will mean that keys are attached to macros, not the other way around (macros attached to keys). This will turn Cue into a more flexible macro editor that's centered more around what the user wants to do rather than being limited by the configuration of particular hardware (which may not have g keys for example). While I understand there are ways to accomplish the above, they are unnecessarily complex, non intuitive and prone to error.