Colormap plugin is “variant”?


(Shriramana Sharma) #1

The GitHub page of the ColorMap plugin labels it:

Colormap extension for Kaleidoscope, EEPROM storage variant

… but I don’t see any other variant. Am I missing something?


(Gergely Nagy) #2

No, you’re not missing anything. There used to be two versions of the Colormap plugin, but only one remains now. The description is an artifact of old times, which I forgot to remove when deciding to only keep one.


(Shriramana Sharma) #3

So what did that other version do can you tell?


(Gergely Nagy) #4

There was only one other variant (which happened to be the original),) which stored the colormap in PROGMEM instead of EEPROM. That was the only difference in the beginning. Then the current version was made to use LEDPaletteTheme, so control of the palette was moved outside of the plugin.

You can find remnants of the other variant on the obsolete/progmem-variant branch (or named something along those lines…)


(Shriramana Sharma) #5

Was there a particular reason for preferring EEPROM than PROGMEM?


(Gergely Nagy) #6

A couple:

  • Using EEPROM makes it possible to update the colors without having to recompile and reflash the keymap.
  • I needed PROGMEM space, and the colormap was eating a fairly large chunk of it.
  • It was easier to optimize the colormap storage in EEPROM than it was for PROGMEM. With EEPROM, it was easy to use only four bits per key, while the PROGMEM variant used eight. So storing it in EEPROM resulted in a more compact map.

Initially, Colormap supported up to 256 colors and a dynamically sized palette, it was limited to a 16-byte palette later on, to save space. At that point, it was easier to make the EEPROM variant more compact. I’m sure you’ll be interested in why, and the answer is pretty simple: for PROGMEM, I wanted an API that is easy to use, something that resembles the keymap definition itself (see this old example). While it would have been possible to write a macro that turns that into a structure that places two key colors into a single byte, I found that to be cumbersome. And since I wanted to save PROGMEM space anyway, and wanted to make the Colormap configurable via Focus anyway, I dropped the PROGMEM variant.


How much memory does my M01 have?
(Shriramana Sharma) #7

OK so I looked through all that old and the corresponding current code.

As advertised in the README, this plugin seems to be largely what I’m looking for but I am looking for an example which will tell me how exactly to specify the colours! Neither the Colormap example nor the LED palette theme example teaches me how to specify the colours!

From the code I see that a file by name colormap.map is expected, but where to create/store this file and how?

Is this plugin meant only for use from Chrysalis (which I have not used yet as it is said to be under beta)?

Runtime configurability is nice to hear but if I really don’t care much for it (as I mostly look at the screen and not my keyboard and just looking for colours as guides to the right keys) and I just want something that “simply works”, then what is my option (other than to write my own plugin/fork)?

Thanks!


(Gergely Nagy) #8

That’s not a file, but a Focus command. My Sketch has a few tools that may serve as examples. You can also play with it without any “special” tool, by using the extras/kaleidoscope-focus.py tool in Focus. Once your sketch is set up correctly (with the appropriate Focus hooks enabled), you connect to the serial port with that tool, type palette 255 255 255 to set the first color to white. You can list up to 16 colors there, simply R G B triplets one after another. Similarly, colormap.map IDX1 IDX2... will set the color of the LED at the first, second, etc positions. You can repeat indexes for every key on a layer, for the maximum layers you configure Colormap to use.

Yes, this is a tad cumbersome at the moment. :frowning:

Pretty much fork or write your own at the moment. Or use Colormap and a few helper scripts on the host side (see my tools above).