While the ability to create a table of LED pixel mappings exists,

While the ability to create a table of LED pixel mappings exists, it gets messy, memory management becomes a pain, and group actions (fill_rainbow and such) become a mess. So I’m once again on a quest for a way to finagle non-contiguous RGBSets.

I’m going to be looking through the code of that system to try to figure out if there is a way to do it, but I’m not hopeful as I suspect it may be using a pointer to a position in the main array rather than an array of pointers to positions in the main array (which the latter I could potentially re-write the individual addresses pointed to, but in the former everything is pointer+n. T^T)

Obviously though I’d like to avoid replicating prior work or chasing a hopeless endeavor, so I’m looking for alternate solutions that don’t make things a kludgy nightmare.

I need to be able to:
Dynamically form and delete sets/groupings that provide the ability to work with non-contiguous and occasionally-inconsistently-ordered (swaps between incrementing and decrementing) LEDs from the main RGBArray. Preferrably in such a way that I can use fill functions.

So, for example, I may at one point need to create a “strip” that is comprised of LEDs from the main strip (in order): 6 7 8 9 10 11 17 16 15 14 13 12 23 22 21 20 19 18 0 1 2 3 4 5; and then later change it to two that are comprised of 6 7 8 9 10 11 18 19 20 21 22 23 and 5 4 3 2 1 0 17 16 15 14 13 12 respectively. Changing based on control input.

Failing at that, I may need to figure out how to manually perform fill functions one LED at a time or start throwing in a lot of memory use and cycle use with a scrap array and addressed shuffling. T^T