Experimentally, it seems the relationship between FastLED.setBrightness() and power consumption is quite linear—i.e., setBrightness(128) will use pretty much half the wattage (and therefore current, at constant voltage) as setBrightness(255). Is this what you expect, @Mark_Kriegsman and @Daniel_Garcia ? Does this match anyone else’s observations?
Starting serious work on the jacket now and it looks like it’s going to be in the order of 650 LEDs, and therefore a theoretical maximum of 40A draw. That’s, uh, ten of our favourite Limefuel battery packs. It would be nice if I could just dial it down to setBrightness(96) and get away with four 
It should be pretty much linear. Setbrightness does not do a logarithmic brightness scaling, just a linear one (and it is intended for things like scaling back power usage, vs. effects). I use a setBrightness(64) to keep my power draw low (but also to keep the leds from blowing out people’s retinas while still giving myself 0-255 dynamics in my effects programming.
(Also, think about how the leds work - they’re constantly cycling pwm - at a brightness of 255, they are on for 255 out of 255/256 cycles. At a brightness of 128, they are on for 128 out of 255 cycles. So, yeah, half the time spent on, half the power draw
I have much more concern for my current draw than people’s retinas ;-). But good to know.
The “density” of different effects are different, so I might experiment with assigning each effect a maximum brightness which will keep it under my maximum allowed current draw and allowing adjustments up to that “ceiling”.
@Mark_Kriegsman has been working on code that adds a “pre-pass” phase to show that does a guestimate of the power draw of the current frame then calls setBrightness appropriately to keep you under a given max
I’m trying to wrap that code into useful shape. I’ve used it now once on a large 12v project and on a couple small 5v ones, and I find myself liking the idea of setting a maximum power level even more than a raw brightness scale.
On the other hand, I do have literally a couple of dozen microcontroller hardware projects I need to actually assemble, test, and package in short order, so software may wait a couple of weeks.
@Robert_Atkins I’ve also built jackets with that many LEDs, & my last one ran ~30 hours on a 10k USB battery through optimized patterns. So my advice is that sometimes less is more! Design for fewer LEDs on simultaneously with both good use of “blackspace”, linger on pure red/green/blue for a bit longer than purple, diffuse LEDS to cover a wider area, etc. Rainbow swirls are epic, white light is beautiful, but both are battery killers
OK, it’s true, I’m jealous of the folks who can run video on theirs! But they’re practically tethered to an outlet 
Good luck on the jacket!
Thanks!
I’m worried much less about run time (as long as it goes “all night”—6-8 hours—I’ll consider it a win) than instantaneous power draw.
I met a dude last year (maybe you?) who had an epic LED trenchcoat powered off a couple of macho RC car batteries strapped into his boots. Aside from that being an exciting amount of lithium very close to important body parts, when he put the whole thing into “flashing white” mode he managed to draw a crowd of 30-50 in short order :-). He was running canned animations off a commercial controller box, but that’s the kind of trick I want to pull with something realtime generated and sound reactive. Without triggering a “vent with flame” event :-O.
@Mark_Kriegsman Definitely interested in using this if you get it done before the Burn
wasn’t me! wish I’d seen him. But hey, he’s smart: flashing is another way to save your battery
but yeah, talking about sound-reactive, here’s an example of the kind of techniques I’m talking about: lots of people do “equalizer bars” visualizations. But the visualization can look just as cool with the single max-height bar moving up and down your jacket (and maybe moving through a palette) vs. all the bars being filled. Etc!
(and you still have all those pixels to do something spectacular every once in a while!)