These are chat archives for Makuna/NeoPixelBus

6th
Aug 2015
Michael Miller
@Makuna
Aug 06 2015 02:16
@sticilface sorry I haven't yet, I will be "on vacation" for a few weeks, so no esp8266 nearby.
sticilface
@sticilface
Aug 06 2015 15:54
No worries at all. just curious. enjoy the hols!
sticilface
@sticilface
Aug 06 2015 19:28
While you're on holiday I thought I'd throw something else at you:) I've been writing some effects things have not been going so well... I've discovered that you time variable for animations is basically limited to 65 seconds as it is an uint16_t? would it be disastrous to up it to 32?
in terms of memory?
Michael Miller
@Makuna
Aug 06 2015 19:32
It will double memory use, but as long as there aren't a lot of pixels, shouldn't be a problem. What sort of animations take longer than 65 seconds?
sticilface
@sticilface
Aug 06 2015 19:38
mmm... i'm creating a sort of lava lamp type of thing with squares and such fading in and fading out... what i've got at the moment is that each pixel fades in and out over one animation callback...
           AnimUpdateCallback animUpdate = [=](float progress)
            {
                // progress will start at 0.0 and end at 1.0
                float new_progress = progress * 2.0; 
                if (new_progress >= 1) new_progress = (2.0 - new_progress); 
                RgbColor updatedColor = RgbColor::LinearBlend(originalColor, color, new_progress);
                strip->SetPixelColor(pixel, updatedColor);
                if (sq_pixel == 0 && progress == 1.0) effectPosition--; 
            };

            animator->StartAnimation(pixel, timeforsequence , animUpdate); // might change this to be a random variant...
          } // end of if for is pixel valid... >=0
so for progress 0 - > 0.5 it fades in, then from 0.5 -> 1 it fades out. Works nicely. except i was wondering why when i want it to happen very slowly it was not working. might also explain my random crashing. maybe i should approach the problem a different way... because at the moment there is no static part of the effect. might be good to have three parts to the effect (in, static, out).. however at the moment I like the fact that your callback handles everything :)
Michael Miller
@Makuna
Aug 06 2015 19:42
So in your case, millisecond accuracy isn't needed. Would 650 seconds length be good enough? I could include a flag on the NeoPixelBus that scales the time values, so no extra memory required, but you get only 10ms accuracy, or even 6,500 seconds with 100ms accuracy
sticilface
@sticilface
Aug 06 2015 19:43
That would be class :)
I was thinking that as a possible solution too
an
animator->SetTimeScale(x);
sticilface
@sticilface
Aug 06 2015 19:56
Let me know if u'd rather be enjoying your holiday. Got some more questions. Is there a way of 'doing something' when a particular animation has run / its called back is deleted. I'm thinking along the ~ type of thing, I'm just not sure how to implement it.
what is the name given to this notation = [=] ( xyz) i've done a bit of googling but can't find it
Michael Miller
@Makuna
Aug 06 2015 19:59
When the progress value is exactly 1.0, then you consider it finished, and doing any cleanup. Likewise, when it is exactly 0.0, you do setup sruff, but I would have to check and confirm 0.0 is always called, I know 1.0 is.
sticilface
@sticilface
Aug 06 2015 20:01
ok so my if (sq_pixel == 0 && progress == 1.0) effectPosition--; is the best way of doing that then
sticilface
@sticilface
Aug 06 2015 20:08
having a timescale might also be a good way of reducing the 'cpu demand' if the animation runner can hold of doing anything in-between?