@radgroza Here you go.
Use this toggle to enable global brightness in controllers that support is (ADA102 and SK9822). It changes how color scaling works and uses global brightness before scaling down color values. This enables more accurate color control on low brightness settings.
Value 1 means faster bit operations but only uses 6 extra brightness levels (powers of 2).
Value 2 means slightly slower math operations but it uses all 31 brightness levels.
Hello! Looking into parallel output for NeoPixels. I see the wiki page here: https://github.com/FastLED/FastLED/wiki/Parallel-Output
So there are two methods: the "Parallel output" method and the OctoWS2811 method. It sounds like the parallel method is an improvement over the OctoWS2811 method, but I can't quite tell from the wording. I have a Teensy 3.2. I can use any set of pins, and I am driving 3 lines of 50 LEDs each. Which method should I use?
@SteveYager_twitter I'll point you to this wiki which has a collection of some of the stuff you're asking about.
After that please feel free to post questions to the FastLED Reddit group and we'll try to help.
You might find this sketch useful too for creating a timed animation:
Hue is the only element that needs to be scaled. Try
fastledhue = (inputhue * 182) / 256;
That should scale hue appropriately into the range 0..255
Also make sure to explicitly use the “spectrum” conversion functions that FastLED provides, not the “rainbow” ones which are the default. External HSV sources will almost certainly assume “spectrum” distribution of hues, so make sure to use
CRGB rgb = hsv2rgb_spectrum( hsv)
Lastly, these questions are best asked and answered over on the /r/FastLED subreddit. We don’t use Gitter too much these days. Good luck with your project!
Ah sorry yes. If they’re giving you 0..100 then this should convert them to 0..255
scaledval = ( inputval * 653) / 256;
This conversion is the same as * 2.55, but uses only integer multiplication and binary bit shifts — its significantly faster than using floating point numbers, especially on lower-end microcontrollers. It’s mostly just a habit for me for this kind of high-volume conversion: it’s computed for every pixel for every frame, and thus worth streamlining.