-
Notifications
You must be signed in to change notification settings - Fork 101
Silently accepting mismatched color tuples. #34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
No, we should not. Seems like having that be caught and return an error would be super helpful. |
The possible combinations can be summarized as:
We need to decide what the behavior should be for the |
its a bit hard to distinguish a 32 bit int from a 24 bit int with the 8 upper bit 0. |
so I guess you just want to reject a value with the upper nibble set for an RGB |
never mind -- clearly I'm confused about how the ints are used. |
Discussed in weekly -- plan forward: If 3-tuple sent to RGBW -- set RGB values. |
Yep. In table form:
|
Thanks! -- hopefully this is accomplished by #37 Let me know if I missed something. |
Closing. Fixed by #37. Thanks @jerryneedell. Possible future solution - make things super simple here, just support a 3 or 4 tuple. Move all the logic and other things to some external helper that can take various inputs/flags/etc and return the required 3 or 4 tuple. |
Should we be silently accepting color tuples that don't match pixel order?
Give an RGB a 4 tuple, no errors:
Give a RGBW a 3 tuple, no errors:
In both cases, all zeros get sent out instead. See here:
https://github.com/adafruit/Adafruit_CircuitPython_NeoPixel/blob/master/neopixel.py#L145
The text was updated successfully, but these errors were encountered: