There are enough branches to merge right now that it’s probably going to be messy no matter what I do… especially for tint-related stuff, since that entire part of the code probably needs a rewrite to handle the variety of multi-channel lights being produced lately.
More thoughts on it are here.
I think it may need multiple different tint algorithms which can be inserted into fsm-ramping.c at compile time, depending on the hardware type. It may also need multiple different 3C+3H handlers (tint-ramping.c), selected at compile time. The idea is to make the interface as consistent and convenient as possible, while still working on many different types of lights.
Like, on a cool+warm+red 3-channel light, perhaps 3C would rotate between 3 different tint modes:
- 011: warm+cool tint ramping + auto-tint modes
- 100: red only
- 111: red+warm+cool ramping, in a circle
There are 8 total combinations, but only 3 seem like they would be useful on this particular light… so I’d probably have a tiny array somewhere with those 3 values, and 3C would rotate through the array.
I hope that makes sense.
The channel bitmask approach is just an idea for now, but I think it might help facilitate a wider variety of hardware with a variety of different needs. Like, a light with white, red, and UV would have modes 001, 010, and 100… because it’s not useful to have 2 or more active at the same time. Or a light with flood and throw LEDs might have 01, 10, and 11 – flood only, throw only, and ramping between.
Edit: In practice, the flood+throw interface would probably be:
- 3C: toggle between flood-only and throw-only (01 and 10)
- 3H: switch to ramp mode (11), wait a moment, then start ramping
Something similar could be used on the LT1S:
- 3C: Rotate to next tint mode (white ramping, red only, red+white ramping)
- 3H: Ramp tint. If in red mode, switch to white mode, wait a moment, and start ramping tint.
But since these are different, it would need some compile-time magic to select appropriate interface code.