Frank

@dedehai pinwheel has a general problem with holes - we tested it until 56x56, so below 56x56 there should be no holes (using sinf()/cosf(), not the _t approximations from AC).

> any reason it is 512? it could be [larger] 512 was just a "shot in the dark". You're right we could increase the value to 2^15 or higher.

> @softhack007 looking at the pinwheel some more. I have some fixes but also: why is the center calculated in such a complicated way (with shifting odd rays)? I removed...

> @softhack007 looking at the pinwheel some more. I have some fixes @DedeHai would be nice if we find an improvement, because each time I get a larger setup, there...

I was wondering if this should be included in the upcoming 0.15.0 release, maybe together with the new WLEDgetColorFromPalette function extracted from #4138 ? We have "feature freeze" for 0.15.0...

> I am not sure about this. These changes were not in any beta release @DedeHai thanks I think your judgement as the original author is very important. I agree...

Thanks @TripleWhy for the benchmark 🥇 Actually from my POV the main reason to use the new functions is accuracy when compared to fastLed sin8 or sin16 - especially fastled...

Hi @proosth, This fork is not under development any more - the latest soundreactive WLED (based on 0.14.x) is in the MoonModules fork now. https://github.com/MoonModules/WLED Actually I can't say much...

> I'll change back PR draft mode, when I've tested code changes with realtime DMX console e131 input. @mxklb did you make progress? This PR is in draft for 8...

Update: omitting "-g3 -ggdb" saves another 26 kB on the wrover build. Flash: 85.8% (used 1461869 bytes)