Possible to define a device-specific ChromaLedMap?

[DragRedSim]

My device (Asus G513QM; I supplied the Artemis mapping for this device) has a few "keys" with no equivalent mappings in the default ChromaLedMap values (eg. this device has four separate lights on the spacebar, and three on each of backspace, enter and right shift). Is it possible that an Artemis device configuration could supply its own mapping to handle these cases where one physical key is represented by multiple LEDs, and/or a key utilises an alternative key name to that of the Razer standard?

I understand that in most cases, these are handled by the CL2-5 layers, however this causes animations which use finer detail to appear to play out-of-order. For example, the following video displays an animation triggered in F1 Manager 2022 when loading a scene; it is applied on a key-by-key basis, rather than just CL2-5.

https://github.com/diogotr7/Artemis.Plugins/assets/5095074/b190d802-1b99-487d-8038-f682c357a529

As you may be able to tell, I have experimented with utilising the individual keys' values in the DataModel. However, it appears that when doing so, it is not updating fast enough; only if I am specifically watching a layer and its DataModel value does it update in real-time. This makes it difficult when I have four layers to watch...

https://github.com/diogotr7/Artemis.Plugins/assets/5095074/29d577eb-ca9d-4fd3-a374-775a61e7d0b3

[DragRedSim]

I've also raised this as a potential issue with an alternative method of working around in the main Artemis software, in the above-mentioned issue on the main Artemis repo. This would be more platform-agnostic, helping to fix other similar issues in other integrations, however it may not be feasible to apply there (due to concerns I raised there).

[diogotr7]

The data model approach you took is what i meant to be used in this situation. I'm unsure why you get a weird delay. How do you have the binding setup?

Maybe it's related to my recent attempt at not updating the data model if artemis thinks it's not being used. I can make a build with this function disabled so you can test if this fixes the delayed update issue.

[diogotr7]

If possible test the artifact from that commit, I want to know if you still experience this delay.

[DragRedSim]

The bindings are all set up as having all LEDs for a specific key mapped in their own layers (one per key), with a Solid brush with the value set to the colour reported as part of the Chroma -> Keyboard -> Keyboard (appropriate key) value.

The artifact created on the feature/property-in-use branch does fix the issue for all four affected keys at the same time. However, I can understand that this may not be the ideal solution to the problem, as it may add a large workload that was previously optimised away; only too much so, in my case.

[diogotr7]

i would say it's reasonable to disable this small optimization, but ideally this bug would be fixed. In my testing sometimes it updates properly with this optimization and sometimes it doesn't

[DragRedSim]

I think I might have started to track down the issue; for some reason it seems that the data model is losing its mappings of what is in use. I think I was able to trigger this by using another data model mapping at the same time (just to test, I mapped a few spare buttons to a gradient based on the PC volume). I consider it to be a potentially large optimisation based on the fact that it is attempting to set data model values for over 100 individual items every single frame; and there is a certain effect in the game in question which individually sets LEDs to different, changing values of brightness (to simulate the waving of a checquered flag).

[diogotr7]

Unless you actually notice a big difference with the performance i wouldn't worry about it. ~300 leds per frame (for all devices) really isn't that much for modern computers. Roughly this amount of data gets set for the brush anyway, the module doesn't add that much to process. I'm worried about this optimization in the context of Artemis with other plugins, that can actually save major resources with it.

[DragRedSim]

Realistically, I'm not going to suffer any noticable loss from an optimisation like this not being in force; I bring it up more as a matter of "we should find a way around this, if we can, for the benefit of everyone, instead of just throwing resources at the problem". I find that thinking with this mindset is better than leaving it to fix later - because later often becomes never in such situations.

In summary;

• the core issue is fixed, in that the functionality of cloning one Razer key to multiple Artemis LEDs is available, using the data model.
• the side issue of the data model losing its mappings when attempted to be optimised seems to be more of an upstream issue, since it is all utilising the frameworks provided by the data model template.
• the workaround for that side issue of not optimising the data model does work, but it is not ideal; it is only a workaround by bypassing what should be working, core functionality.

So I think the energies should now be directed at trying to figure that out in its state, since it is not exactly relevant to the original question, only tangentially in the solution.