Issue: Exported profiles with many modes can grow in size rapidly. A 24-mode K70 RGB profile can be around 1.1MB with only simple backlighting.
Suggested fix:
In the xml export, every mode has a duplicate list of entries for the key action mappings even if there are few or no changes from the default mode. If the default mode was treated as a global mode from where all other modes inherit their action maps, then only mode-specific differences would need to be stored. For the lighting maps, if we were able to create "global groups" in the default mode that all other modes could inherit, this would avoid needing to store duplicates of that group as well and only store mode-specific overrides similar to how the action mappings could be handled.
Alternate suggested fix:
Each mode stored in the exported file has an "assignments" group that determines the keystroke binding the following is an example for the "1" key:
<assigment key="1" action="{4a9f32a7-28e1-4987-9b09-31f1940d01a3}"/>
I can only assume this lengthy action code has some important need, but the problem this causes is when these bindings are duplicated across multiple modes with little or no changes. If this binding table could be globally applied with mode-specific overrides it could significantly cut down on the file size in profiles with many modes. Or perhaps assign those action codes some shorter-named symbols/variables so that when they need to be repetitively referenced the shorter names can be used instead. There might be a few ways to go about it but I don't know the mechanics of your software.
Granted this isn't a big problem issue, but I've seen some people experimenting with 30+ modes - and if we want to go crazy with modes that branch out for more variations we could be looking at 5-10MB easily. Still not that big of a deal in the era of multi-terabyte drives, 8 gigs of RAM as 'standard' and 20+mbit internet connections - but something to keep in mind going forward.
//////
Issue: Exporting and re-importing or duplicating a profile within CUE causes any changes to the default mode's action mappings to apply to all other modes, even when manually set otherwise. I ran into this issue when testing a profile I was planning on sharing, as I wanted to be sure it would import properly again (also important to be sure I could make a backup copy).
Reproduction steps:
1) In a fresh profile, add any number of extra modes. Two or three is enough to demonstrate the issue.
2) In the default mode (the first mode auto-created) set the following to any number of action mappings:
----Set key to jump directly to a specific mode that you added in the first step.
------Ex: "1" key set to jump to mode named "One" - "2" jumps to mode "Two" etc.
----Be sure to uncheck "apply setting to same button/key in current profile" when adding each action binding
------This step is critical, otherwise all modes will get copies of the mode-switching keys
3) In the each of the modes that the default profile now links to, add the following action binding:
----Set scroll lock to jump directly to the default mode
----Also be sure to uncheck "apply to all" again to avoid over-riding the normal scroll-lock functionality in the default mode
----You could use some other key as the return button, such as the application key - just keep it consistent so its easy to use
4) You should now have a working "menu" where the default mode is able to jump to any number of sub-modes and each of those sub-modes are able to return to the menu via scroll lock. Color-coordinating these can make it easier to navigate, but the idea is simple enough.
5) Duplicate the profile or export/import as duplicate, then check the action bindings for any of the submodes in the new copy. You will notice that the bindings in the default mode have overridden all other modes, not the behavior originally set in the profile. However, any unchanged action mappings in the default mode will not override the other modes, so the sub-modes retain their scroll-lock return setting.
Workaround:
Avoid applying any mappings in the default mode you do not wish automatically override any other mode. In my example, I was able to use the default mode as a sub-mode and use an added mode as the menu. However, the scroll-lock return was still applied to all other modes including the menu mode, so while in the menu scroll-lock just tells it to go to itself which is not normally allowed behavior. This effectively breaks the potential use of that key for its default behavior in the menu mode.
Exporting+importing or duplicating the profile causes the issue, so the problem might actually happen when the profile is created upon import. Attached is my example setup, but upon importing it you should see the error already. You can still reproduce the issue by manually restoring the default action bindings for the 1-3 keys in each of the red, green, and blue modes to restore the original menu behavior. Then just duplicate or export/import it again and look at your new copy. Loopback test.prf
