@Daniel_Garcia@Mark_Kriegsman In case you guys decide one day to continue the work on the library I hereby suggest to make this animation (or an improved version) a part of the official FastLED examples in case that feels appropriate to you.
Thank you @Stefan_Petrick . I wasn’t quite getting the code you posted earlier plugged in and working but I have this running now. Will play around with some of the variables since I have it running on a small 8x4 matrix. Great stuff.
@marmil Cool, please report how it goes. On such a small matrix you might need to adjust the (at the moment) hardcoded noise points which are used for the controlling. Also the factor for scale_x and scale_y might need an adaption. Or you render it as it is but use only a 8x4 area for displaying. I´ll think about how to make this more universal usable without fiddling arround. 8x4 is really small. Challenging.
@Stefan_Petrick Here’s my initial venture of trying to dial something in last night. I was playing with those controlling values, but not fully understanding what they were doing. Also I imagine I should pay more attention to the x y scale since my matrix is wide (8x4).
And thank you for the code update. I just tried that out and it basically works right out of the box now on my tiny and non-symmetrical matrix. Cool.
Good questions. Answers to line 113: 8000 is basically the minimum for the zoom factor. If it is set smaller it is more likely to happen that you see just a plain color all over the matrix. Too far zoomed in = boring. To this set minimum the modulated value is added. If you increase the factor 16 you zoom more out = very small structures. Tends to flicker. Answers to line 124: I looked at the output from inoise16 and noticed that most of the time the values are in the range between 11000 and 51000. Basically the range is 0 - 64k but most of the time the values are in this middle range. So I decided to use just this part of the given results because there “is the music playing” and I cut the rest of by limiting. That helps mainly in the colormapping to don´t waste color resolution with values that maybe appear once every hour. It´s moving permantently all over the selected range now = if we are limited to 8 bit colors we better use the full possible range permanently in order to have smooth edges. The next 2 lines (the subtraction and division) scale this limited value down into the range of 0-255. Not precisely but for sure <255. Now we have a byte value we can work with. Next question, please!
Okay, I got the particularly erratic movements smoother now by averaging every control point over 4 neighbor noise values. The code looks really crazy now… I also added a noise influence causing the colormapping to become slightly desaturated controlled by the noise. That adds a bit more “breathing” to the animation. What do you think? Improving the effect or over the top? https://www.youtube.com/watch?v=xFCByH6AcJc&feature=youtu.be
Thanks for the explanations of those values. I have messed with most of them now and found some values I like/that seem to work on my matrix. Here’s a new tweak with things rather slowed down so those more erratic movements are now rather subtle (but it also causes it go nearly still for a bit now and then).
I was planning to mess with the saturation too. Good idea to add another level of variety.
I really like your new version with less erratic moves and call it an improvement!
Looking good, @marmil ! And a nice dolly shot - how did you do that?
You might like to also try stuff like
ctrl[1] = (noise[0][Width-1][0] + noise[0][Width-2][0] + noise [0][Width-1][1] + noise[0][Width-2][1]) / 4;
Later you can use this ctrl[1] instead of a single point like noise[0][0][0]