Sometimes we would like to know the highest active layer, which is available in
the `highestLayer` private variable, and via `.top()` too. We do not want to
make `highestLayer` public, because we want to be the only ones changing it. And
while `top()` gets us roughly the same information, it does so at a cost. For a
lot of purposes, the cached `highestLayer` would be perfectly adequate.
The new `Layer.highest()` accessor does just this.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Now that we only care about the highest active layer, make sure we only do work
if that changed between two cycles. This way, `onActivate()` will take care of
the initial setup, `update()` will be an almost no-op for most of the time, and
`refreshAt()` will take care of refreshing keys other plugins may have changed.
This makes us about twice as fast as we were, on average.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
The underlying `LED-PaletteTheme` plugin stopped supporting transparent colors,
and as a consequence, so did we. Update the README accordingly.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Supporting transparency is very, very expensive in terms of speed, while the
benefits are marginal at best. Drop support for it for now.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Instead of using `Kaleidoscope-Ranges` and custom helper functions with magic
constants to decide whether we need to highlight a key, refresh it, or leave it
alone, use an if-else chain and inner ifs for activity.
Leverages the new `OneShot.isOneShotKey(key)` and `OneShot.isActive(key)`
methods.
The net result is slightly cleaner code (though it can still be improved), and
about 0.2ms saved, along with some PROGMEM space.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
There were a number of issues with the model we had before, namely that plugins
that changed LED colors outside of LED modes had no way to signal "go back to
whatever color this key was". To this end, the `LEDMode.refreshAt` method is
introduced, which these plugins can call to tell the mode to update a given key.
As part of this, the API was redesigned, with code that is common between all
LED modes moving to the base class, among other things, much better names, and a
flow of control that is easier to follow.
In the new setup, there are four methods a LED mode can implement:
- `setup()` to do boot-time initialization (registering hooks, etc).
- `onActivate()` called every time the mode is activated.
- `update()` called each cycle.
- `refreshAt()` may be called by other plugins to refresh a particular key.
All of these are protected methods, to be called via `LEDControl` only.
Much of the new API design was done by @cdisselkoen, huge thanks for his work!
Fixes#9.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
We want to highlight keys as specified by the layer, not as their current role,
otherwise we may be missing keys we should highlight.
Thanks to @cdisselkoen for the report and the reproduction steps! Fixes#3.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
For every key we press, we keep a map of its state each cycle (for 8 cycles).
When the key is released, we color it white if we had more than two state
changes (ie, chatter), otherwise we turn it blue (all is well).
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Gergely Nagy
Gergely Nagy
Gergely Nagy
Jesse Vincent
Jesse Vincent