By replacing
if (x % 2 == 1) {
return (x * (WIDTH) + (HEIGHT - y -1));
} else {
return (x * (WIDTH) + y);
}
by just
return (x * (WIDTH) + y);
in the XY function.
I see, there are way more comments required in the code to make it universal usable. Well, it’s the first code I ever published…I keep learning.
That’s it! wow…thanks for the share, I’m still learning too! THANKS
I have noticed that if I add FastLED.delay(20); before the FastLED.show() I get a much smoother transition. I wonder if you can prosper from this addition too?
What means “smoother” to you? The delay makes for my understanding the blurring slower, but not smoother because the stepwidth of the scaling is still the same. If you don’t do anything with the framebuffer there is no new (interpolated) information to display = no increased smoothness. But if you have 20 ms left (and a bit RAM) you could consider writing the new content into a different buffer and use the 20 ms to fade from buffer 1 to buffer 2 over several frames in order to soften the appearance even more… On my setup with 256 LEDs at one single data line it’s 4 times slower than on yours if you are using WS281x, too.
The smoothness comes from the frame rate. I’m using WS2812B’s. I needed to slow the frame rate down, in order for the animations to look less ‘blocky’ between frames.
So you say with a lower framerate you get better results, than with a higher? That’s hard to understand for me but it’s 4 o’clock in the morning here…so I have to and will sleep about it. But you have my full trust that you will find solutions which serve you. 
Did you already play with the speed of the oscillators? Increase tact (time in ms between the steps) in order to slow them down.
I tried a few things, here is the best setup I get with a small matrix.
The dithering is what makes the animations smoother looking. I’ve been tweaking numbers all day and I’ve reached the conclusion that a faster frame rate isn’t always better. Without using the delay, the lower brightness values look terrible at a fast frame rate. It looks ‘flickery’. I have the master brightness clamped at around 32 and the difference between using delay and not, is quite noticeable.
Do I understand right, that FastLED (v2.1) automatically dithers now what I see without touching the screenbuffer? So that I would see with the same content in the screenbuffer slightly different frames (if I would capture it with a high speed camera) while I keep pushing it with FastLED.show again and again? Or with FastLED.delay?
@Daniel_Garcia @Mark_Kriegsman Is that real?
I’m just trying to understand @Jon_Burroughs observation.
The dither only works at low brightness levels. The delay is adding a bit of time so the dithering happens a bit longer, which in turn looks ‘smoother’ and better in transitions, to your eye. Without adding the delay, the length of time the leds were displaying a low value in brightness, looked ‘flickery’. The new delay function pushes data to the leds, while regulating the frame rate.
The flicker seems to have to do with updating WS2812 LEDs too fast. This is because WS2812s have a 400hz PWM rate, which is much slower than many other chips. If the framerate is below 400hz then the two frequencies interfere with each other, causing flickering. It can be quite dramatic. It changes depending upon the exact timing.
Sorry, above 400hz causes the flickering, not below.
That makes perfect sense, Paul. Jon drove only 64 LEDs - and all the calculations are integer based - which is pretty quick. So it’s not about the dithering. I love it when the main problem appears to be code running too fast!
Hi stephen! REALLY nice work! i’ve been trying to use it for testing… but something is weird with my diy matrix. I’ve built a 16x8 matrix. it goes from 1 to 8, and in the up it goes down to 16 and so forth. I’m struggling with my low level programmation to make it work… but without success. With ""return (x * (WIDTH) + y); “” it seem that only skips a line… somehow misplaced… any help? Thx a LOT!