I’m working on adapting my early examples and other sample LED animation sequences to a format where they can be run concurrently with other sequences in real time. I’m curious what other people may be doing in this respect?
It seems the approach is rather than use delay() instead to maintain internal timers based on millis() values. I’m debating the best approach towards keeping track of those timer values. There are probably a bunch of different approaches towards doing this. I was having mixed results using the WAIT macros and started trying to code my own routines. What have other people done? I think it would be cool to come up with some kind of unified approach towards writing sequences that can be combined with other simultaneous sequences.
Thoughts? Approaches? If you are driving multiple strands with different sequences, what’s your approach towards multi-tasking them on the Arduino?
I use a pretty straightforward approach for this : I save the millis() with the first instruction inside the main if. The if checks so see if enough time has passed before executing again. Here is a basic Strobe animation as an example :
unsigned long LastStrobe[NumStrips]; //Delay variable
bool StrobeHigh[NumStrips];
void Strobe(int Strip, int Delay=50){
//delay
unsigned long Elapsed = millis()-LastStrobe[Strip];
if (Elapsed >= Delay) {
LastStrobe[Strip] = millis();
//Reset the animation
void StrobeReset(int Strip, bool ResetAll = false){
if (ResetAll){
memset(LastStrobe,0,sizeof(LastStrobe));
} else LastStrobe[Strip] = 0;
}
This has been working very well for me, and it’s also easy to convert animations that use delay(). I integrated Fire2012() easily in my code. I can smoothly run tens of different strips with individual animation.
Ahh, so you use a single-dimensional array to reference the strips by number. That makes sense. I was thinking about how the functions would work if you called them with different LED arrays and you do it by referring to each array as 0, 1, 2?
Any other approaches? I was hoping to make my routines accept the LED array as a parameter to make them even more portable.
I’m wondering how a sequence like cylon might be adapted in this instance, where you might have a loop along the way in addition to a delay. I guess instead of a for-loop, you would use some kind of index that increments after a timer mark has passed?
Although I guess you could still use a for-loop but have some facility to break out of the loop if the delay condition isn’t met?
I have an animation kind of like that, called “Party Mode”. It’s an animation that calls basic animations randomly and times them to a certain bpm. I use a “beat counter” and “beat bank” to keep track of where I am in the loop.
For example, I’ll start a Strobe() at beat 64 and give it 16 “beats”.
Every 468 ms, I’ll add +1 to Beat Counter and -1 to Beat Bank. When Beat Bank reaches 0 and thus Beat counter 80, I generate a new set of parameters for an animation. Spin() for example, for 32 beats. And so on.
Basically, the Beat Bank times the remaining time on the current animation, while the Beat Counter tracks where I am in the “song”. I put milder effects at the beginning and more punch at the end.
I am running concurrent animations ont he same strip and for that I define a static number of channels (e.g. 16 channels) which all draw its own animation on an led array that might be NUM_LEDs (covering the full strip) or much smaller. I then blend those arrays into the main target array that is given to FastLED. This is of course taking a lot of memory, but I am only using a teensy so it works for me even though I have 1200 LEDs.
Each channel has a set of parameters that influence how the channel draws itself and how it blends into the main array. To save memory and also to create cool effects, I can for example “clone” each channel to draw it several times onto the main array with a configurable distance. There are also fade in and fade out effects per channel.
I am still heavily working on the code which is why I did not post it yet but I am hoping to be in a state this weekend that it can be shared with you for experimenting if anyone is interested.
Its definetly not a light but a heavy approach with a lot of computing done for each frame but thanks to the teensy I still dont need more then 3-4 ms per frame for the internal drawing stuff.
@Franck_Marcotte , yes, I use 2812b and an OctoWS2811 Adaptor with 8 parallel outputs. RIght now I cant tell the exact FPS I am getting, since I cant use the serial port (using Teensy as MIDI device) but it is definetly above 100 FPS. I am also sure there is still a lot of optimazation potential in my library…right now i am just in the phase to put in all the functions i want.
@Sebastian_Stuecker , you could make a small function that checks if the FPS is greater (or less) then some number you choose, and if so, have it set one of your pixels to a bright color, or have it turn on/off the onboard LED on the microcontroller. No serial port needed but you can still get some feed back.
Is there any interest in trying to collaborate on a standard we can use to drive multiple sequences in real time?
I’ve run into glitches in the past trying to use EVERY_N_MILLISECONDS. I’m looking to start building a library of interesting sequences but I want these sequences to be portable and drivable in parallel with other sequences from a single controller. I don’t want to have to rewrite code later so I’m interested in hearing thoughts on different approaches. Maybe we could agree on some standard conventions and begin putting together a little library or format for making sequences portable and independent?
I am trying to do the same, but its probably still far away from a useable library …right now its strongly focused on my personal needs, including the MIDI part.
I have yet to fully comment the code…but feel free to have a look
I agree Franck, about how to approach of whether we’re dealing with one strip or multiple strips.
For this reason, I’m a proponent of passing the strip pointer /length to each function, and not assume we know what strips are being dealt with. That would allow subroutines to work with both separate arrays, and segments of a single array.
@Myche_Tician
I’ll keep that in mind. My code is not quite there yet but I got some pretty interesting stuff I wouldn’t mind sharing in the future. I’ll see if I can convert my functions to pass the strip pointer. On the top of my head I think we would still need to use multiple channels like Sebastian does. Combining both would probably use a shitload of memory, but Teensy and Due should have plenty and I think most people are moving towards those boards when using a lot of leds.
My solution does potentially use a lot of memory. But for each effect I am trying to only draw the part that does not repeat. Most effects actually repeat after a number of pixels so I just blend them into the target array several times. I will put together a video with the features I am already having…I just have to find the time for it.
I am sure my approach has still a lot of flaws and I am willing to collaborate on a project together with some of you and potentially throw away some of my stuff if it turns out there is a better way.
@Shayne_van_Asperen , I also checked your code and it seems you had quite a similar approach than I had. I am not sure if I understand the requirement towards multiple strips correctly. Why not just use one big array for all strips together. On which strip a pixel is, is then only determined by the index number.
The biggest restriction of my code is that it uses a lot of memory because it always draws into a pattern buffer first before it puts the pixels into the final led array.
Would you like to come up with a framework that works with Arduinos? My personal opinion is that Teensys are cheap but I understand if someone has a lot of small applications that also a small price difference matters (however with an LED amount below 150 even my approach would work on an Arduino I guess)
What I did try to do to achieve what we all seem to want here:
never use the FastLED.delay() function and never use the inbuilt EVERY…something macros. I always try to achieve the highest possible framerate. I leave it to each pattern code to individually calculate, how much time has passed since the last frame and what this means in terms of how far the pattern needs to progress for the current frame. For most effects this is very simple since they use the internal beat8, beatsin8, etc. functions but some of them simply work with durations. This is where some CPU power of the teensy is used due to some divisions with long integer variables. I coded the framework in a way, that a pattern with the same set of parameters (for pattern speed, hue change speed, etc.) always looks the same, no matter on how many LEDs the pattern is drawn and no matter how many other patterns might be rendered at the same time somewhere else on the same or on another strip.
Should we start a small project together, I suggest that we collect the requirements in some way to avoid unmet expectations
