Today just some experiments with simple caleidoscopes, @Mark_Kriegsman new wave functions and the usage of 2 CRGB arrays - one for the emitter/seed and one for the applied effect.
Code: Stefan Petrick - Pastebin.com
edit: Same code but different emitters Caleidoscope With Lissajous Emitters - YouTube
#FunkyClouds
Really interesting effects!
I like the thing of using multiple buffers and layers. Comes out great here.
Forgive me but I forget. Using a Teensy here?
I stumbled over the source of the flam3 renderer https://code.google.com/p/flam3/source/browse/#svn%2Ftrunk%2Fsrc which is the basis for the electric sheep project https://www.youtube.com/watch?v=jVD67pMdv9k Although I’m just at the very beginning of understanding how the renderer really works it’s mind blowing, what those guys do with layers and filtering… Just by the way: is there still any intention to publish an “official” FastLED effect lib? I feel drawn to universalize concepts, so that people out there can use it easily. As far as I know, nothing like this exists yet.
Awesome! I like ur clear code, may i can use this in my project. I’m very intrestet on a special effect lib.
I really like the idea of an effects / animation library. Dan and I keep discussing how best to work it all.
But basically: yes! (Somehow!)
It would be an honor and pleasure for me to contribute somehow. Need’s a good structure / architecture first. And answers to basic questions, like writing many fast specific functions (for odd/even HEIGHT / WIDTH) or slower general ones, linking effects to specific layers or not… and much more…
Your hit on the interesting question: what’s the “standard API” for an animation or effect? I think this may be the next big area of work for us with FastLED. Moving up a layer.
Cool. Keep me informed about the progress you make while I keep trying to express my ideas in code.
It would be kind of interesting to know what already exists in your head / codestack to don’t waste time with reinventing the wheel… And I’m allways a bit unsecure to publish code here, because I fear that for the coders this is just all boring and sooo 80s…
Bist du dir sicher? You are sure 
It’s exists not old or new Code! I’m also unsure how teribble is my english. No, may u check the Code samples area. May u find some modules, they demonstrate how can build an effects library: https://bitbucket.org/ratkins/ledeffects/src
That effect is very close to something I saw last year and was trying to figure out how to reproduce. Your projects looks really nice, and I definitely appreciate that you keep posting the code as well!
Now it’s my turn to start working on trying to understand this stuff better. 
Thanks Frank, I already saw that one. And yes, i know the code area here where is some pretty awesome stuff hidden. I just can’t believe that this is all, people use…
By the way - exactly the same code as above - just with different (Lissajous) emitters with static colors: https://www.youtube.com/watch?v=8e3DDWnyEtE&feature=youtu.be
There’s a fundamental design tension between aiming high (declarative sprite definitions, render windows, inversion of control – no explicit ‘loop’, abstract timebases), and aiming low (an ever-growing library of helper functions and sample code for specific effects).
Dan and I both want both of these things, and we also both have day jobs. Dan’s done more work abstracting his own animations ‘up’, and we both talk about what the future APIs might be like.
One basic thing is that each animation and effect should be separated apart, and that the main Arduino loop function should mostly not contain animation code itself.
One idea is for each animation function to take a pointer to the CRGB buffer to draw into, a length for that buffer, a void* context, and a “time” parameter maybe in milliseconds, describing what slice of the animation to draw. (For two dimensional patterns, it might be a pointer to the CRGB matrix, X and Y dimensions, a void* context, and a time.)
Each animation could then render into it’s own buffer (potentially), and you could have compositing functions to distill those outputs down into the final leds[] array(s).
But this is all still pretty wide open speculation. Often we’ll have an idea, and play with it for a few weeks, just to see how it works in practice. So far, no one overarching master API has emerged. I suspect that in the end there will be a couple of different ones, at different ‘levels’ of abstraction.
And yes, some of it does seems kind of 80’s … but then again, back in the 80’s I was doing pixelated 8-bit video graphics on low-MHz CPUs, and having a blast doing it, so this is all good!
And then there’s the matter of only having 2K of RAM on ATmegas, or 512 bytes on ATtinys…
Sure, all the advanced stuff will require a Teensy.
Thanks for disclosing and sharing your vision. I think for now I’ll keep growing a collection of specific helper functions.
My long-term vision is a level of abstraction similar to a audio sythesizer/sequenzer where you can basically express any idea by only adjusting the right parameters…
Yep - that’s why I’ve been exclusively using the Teensy. 64K of RAM and 256K of flash. This becomes even more important when you start thinking about double-buffering on a 24 x 24 array.
Exactly: I love the ‘parameterized’ approach.
A related idea to think about is how Flash animation works, with timelines, paths, and sprites.
Your synthesizer idea is similar to what I’ve done with my matrix. I have a number of pattern classes, and many of them have assorted parameters that change the behavior. When combining them in different ways, it really varies the resulting output.
Is there any video or code you’d share, @Dave_Morgan ?