While finding myself unplanned in holiday after coincidental meeting the most beautiful lady in the world and so while being far away from my playground and any controllers and LEDs I found and find a lot of inspiration, also concerning LEDs…
-
Would it be theoretically working, to have a modified FastLED.show which uses a small CRGB to drive a larger number of LEDs by repeating the content again and again? Like for example to drive hundreds of LEDs with an ATtiny based on a CRGB leds[64]
-
I´d like to provide a documention wiki for the fast growing FunkyClouds collection (propably soon a lib). Any suggestion, what´s easy to use and to augment beside an own wordpress site?
-
Wild idea: Matrix, having a CRGB leds. Having a 2nd byte array of the same size. Fill the 2nd with a effect, lets say plasma. Scale it down to a grayscale/calculate just one color channel. Interpret these grayscale as a direction vector and manipulate the screenbuffer in the following way: move/fade the content of leds along these paths to create softening along different paths for each pixel. Like black= up, 25%=left, 50%=down, white=right, and all inbetween. Thinkable or just crazy? Any idea, how to handle these vector thing mathematically?
In my imagination it looks very interesting to combine effects in layers in that way…
Enough for today, greetings and love to all of you! LIFE IS GREAT!
-
not at the moment. The timing constraints are (currently) tight enough that adding a wrapped outer loop messes with that. It’s something I want to look into doing, but it is pretty far down on the priority list of things that need to get put in there.
-
i’ve bee mostly happy with the github wiki so far for building out FastLED documentation. We’ll see if I still feel that way when I start doing up full API level documentation.
-
Interesting idea - best I can suggest is play with it! See what pops out! What I can tell you is I often mix different types of value sources for things (e.g. one set of noise parameters for brightness, another set of noise parameters for hue, and both with different sets of oscillators for moving around the noise space in different directions) - the more mixing of sources for adjusting values, the less “patterny” things end up looking, which is a bonus in my book! What you’re describing is almost making me think of a variation on the game of life. I really should put up my stupid-fast generic cellular automata code (it allowed for up to 9 predecessor neighbors for value calculations, but was linear performance based on the number of cells you had, not the number of neighbors referenced 
Here’s an off the cuff example that just uses the low 4 bits with this pattern:
bit 0 - if 1, bit1 determines up vs down, otherwise no up or down change
bit 1 - if bit0 is 1, then 0 is down, 1 is up
bit 2 - if 1, bit3 determines left vs right, otherwise no left/right change
bit 3 - if bit2 is 1, then 0 is left, 1 is right
CRGB oldArray[NUM_LEDS];
uint8_t dirvector[NUM_LEDS];
void move() {
// first, save off the current led values
memcpy8(oldArray, leds, NUM_LEDS * sizeof(CRGB));
for(int x = 0; x < WIDTH; x++) {
for(int y = 0; y < HEIGHT; y++) {
int newx = x;
int newy = y;
int vector = dirvector[XY(x,y)];
// if bit 1 is set, use bit 2 to determine which direction to adjust y value
if(vector & 0x01) { newy += (vector & 0x02) ? 1 : -1; }
// if bit 3 is set, use bit 4 to determine which direction to adjust x value
if(vector & 0x04) { newx += (vector & 0x08) ? 1 : -1; }
leds[XY(newx,newy)] = oldArray[XY(newx,newy)];
}
Naturally, you’d want some bounds checking in place to either wrap values or let an led “walk of the edge”. You could even have a bit more fun and use the top 4 bits of dirvector to determine the “distance” that things move by