On Sun, Sep 28, 2014 at 12:43 PM, Andrew Sutherland
<[email protected]> wrote:
> As a thought exercise, here's a structure that I think could make sense but
> still could be a bit of a hassle to use:
> - Boolean white LED: [{ color: 'white', levels: 2 }]
> - White LED that can pulse/fade: [{ color: 'white', levels: 64 }]
> - Tri-color LED that can pulse/fade: [{ color: 'red', levels: 64 }, { color:
> 'green', levels: 64 }, { color: 'blue', levels: 64 }]
> - MIDI sampler controllers tend to just have red-green with limited levels:
> [{ color: 'red', levels: 4 }, { color: 'green', levels: 4 }]
> - Firefox-special orange-only LED: [{ color: 'orange', levels: 8 }]

Yeah, this seems better than what I was proposing. Though maybe use
rgb hex values rather than human readable values to enable code to do
math on it.

> Probably the ideal API to hide more complicated cases would be to let the
> patterns be more CSS transition-like where we set the startpoint and the
> endpoint, let it be repeat-able, and just broadly inform via the API the
> color channels that are available and whether it's "boolean" or "smooth"
> fade-capable.  This would also open the door to a very fancy device
> performing color-space normalization (which could result in non-linear use
> of the quantization levels).

Isn't that essentially what you're doing above? Except that you rather
than just "boolean" and "smooth" you provide the number of levels.

I think we need more information about capabilities of LEDs on modern
hardware. I also think we should be somewhat careful about over
engineering this since this isn't really a critical part of the
system, so not something we should spend too much time on.

/ Jonas
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to