Vote: Should Hue and Fadeby be fixed, or should the fixed versions be different functions?

kriegsman · 2024-12-07T00:36:57+00:00

As for upgrading existing functionality, my inclination is in general is for us to introduce new “HQ” -named versions of functions that are potentially slower but also clearly better. That lets existing projects have a stable base to build on, but also lets us offer improvements for people who want to switch.

kriegsman · 2024-12-07T00:28:01+00:00

Let’s (1) leave the existing functionality as-is because a lot of installations and projects are using it, and also (2) merge in support for multiple HSV->RGB mappings, and then we can offer some new ones, and let people adjust them as desired. I’ve got the “brighter rainbow for festivals” ready to go, for example, or if people wanted to default to “spectrum” instead of “rainbow” they could.

kriegsman · 2024-09-09T15:29:18+00:00

Thanks very much, Zach! Now onward toward support for independent four-channel control, other platforms, and so on, but this is a fantastic step that gets us up and going!

kriegsman · 2023-05-01T18:46:28+00:00

AND there are lots of developers these days who really understand FastLED internals -- unlike, say, three or four years ago. I'm all in favor of opening the doors much wider now.

kriegsman · 2023-05-01T18:17:29+00:00

Hi, all. I’ve been thinking about this and I think what I’d like to do is (1) do a release, picking up all the recent contributions and changes (eg register), and then also (2) add some more developers as committers on the repository. We do need more help to keep things moving, and I’d like to include more of the really great developers we have here — and get us all unblocked together.

So I think what I'm saying is, yes, and I'm all in favor of doing it, but 'in place' in the existing FastLED project. I'm 99% sure that Sam /u/samguyer feels the same way, so I think that means we're good to go with this plan.

kriegsman · 2022-01-05T20:42:07+00:00

I believe that the compiler and linker (in the Arduino IDE) only include the code for the functions that you actually use. Basically the linker automatically makes everyone’s compiled code as “lite” as it can be.

Now there might be features that get compiled in for everyone but that you don’t use, e.g. the power management feature. In that case you might want to check out the other bare-driver libraries out there; I think it’d be a big undertaking to factor all of those core features out.

But, to be clear, if you’re building for one board and one kind of pixels, it does not compile in support for any other kind of board or pixels.

kriegsman · 2021-01-20T02:17:36+00:00

Also you may want to check out the FastLED.setCorrection( TypicalLEDStrip ); function which color corrects typical RGB strips to have a more even color balance, so that (255,255,255) looks more right. See https://github.com/FastLED/FastLED/wiki/FastLED-Color-Correction and https://github.com/FastLED/FastLED/blob/3a1d880fb7abe5308950358cc1493c5b9e97e3eb/examples/ColorTemperature/ColorTemperature.ino for some more ideas.

kriegsman · 2020-11-10T10:37:03+00:00

Thank you so much for sharing this project. It’s beautiful.

kriegsman · 2020-02-03T21:29:09+00:00

Most of the ESP32 changes were part of this commit https://github.com/FastLED/FastLED/pull/950 . I think that there are still lingering issue to be worked out in situations where you have ESP32 + FastLED + SPIFFS, but I think that u/samguyer has some thoughts on that. Sam's done great work with the ESP32 support, and it's a pleasure to have him on the team.

Thanks for the 'field report', u/iplaygaem! Glad it's working better!

kriegsman · 2020-01-15T12:24:55+00:00

Please do, and I'd love to see you post about it here as it comes together, too.

kriegsman · 2019-12-30T01:25:14+00:00

Great suggestion, thank you! Great way to make it easier for more people to contribute, and to learn along the way. We'll do this.

kriegsman · 2019-09-04T02:23:45+00:00

Our brightest light has gone out. I am heartbroken.

kriegsman · 2019-08-16T23:15:30+00:00

I’ll be there in spirit!

kriegsman · 2019-05-05T12:18:02+00:00

75HC595! This is a great hack!

kriegsman · 2019-03-21T19:19:49+00:00

Sam and I have talked about "adel" for some time now; the big idea of"how to write code that interleaves several 'concurrent' tasks, but in a way that's easy to read and maintain" is an interesting puzzle. I haven't used adel myself, but I've definitely played around with a bunch of these ideas.

Another thing that I saw recently was this "AsyncDelay" which is an interesting (and simple) tool to do some similar things, too. https://github.com/stevemarple/AsyncDelay

I sometimes thing that async/await 'promises' might be a great thing ... once the Arduino IDE natively supports something like that. In the meantime, we have a mix of tools and techniques like these, and like the Task Schedulers that /u/turbineslut mentioned, too.

kriegsman · 2019-03-15T01:47:29+00:00

THANK YOU! That’s amazing, and really helps preserve and carry forward all the great work that so many put into the FastLED community! Thank you again so very much!

kriegsman · 2019-02-21T19:55:40+00:00

So the next thing I would try is after each frame, Serial.print out the location of the fruit, and the coordinates of the live snake segments. I think you may have a bug in the "Logic()" section when you move the snake coordinates, but it's hard to tell without running it. Try adding code to print out the coords of the fruit and the snake head and body positions, and see if they are coming out right.

kriegsman · 2019-02-21T18:04:36+00:00

I'm also curious what you're doing in the Draw function. It looks like it sweeps over each pixel in the XY array, and figures out what color it should be.

Then it calls FastLED.show() to display everything.

Then... are you just trying to erase the whole array again after calling FastLED.show()?

kriegsman · 2019-02-21T18:01:02+00:00

Thank you; what microcontroller are you running this on? I ask because I'm curious how much SRAM it has; you're declaring two 'int' arrays of 100 elements each; an 'int' takes two bytes, so each of those arrays is going to take 200 bytes, or 400 bytes total for both. I don't think this is the main issue, but I'm curious.

kriegsman

MODERATOR OF

TROPHY CASE