These are chat archives for Makuna/NeoPixelBus

18th
Jun 2015
sticilface
@sticilface
Jun 18 2015 10:49
That is great thanks. I'll have to do some reworking to shoe horn it in... not even tried yet...
my other question is that I've got all my stuff being dynamically allocated... so NeoPixelBus->SetPixelColor etc... will all that still work with this and the animation callbacks etc...?
sticilface
@sticilface
Jun 18 2015 10:55
Looking at your code it is just the setpixelcolor instruction that has to be different. everything else can stay the same. I do like the look of this...
What sort of memory overhead does running these animations have? have you tested on several 100 LEDs? I guess I will find out. :)
sticilface
@sticilface
Jun 18 2015 14:24

Just trying it out now... but i need some help with the dynamic part of my sketch... I've got this
NeoPixelBus* strip = NULL; // dynamic but this does not work
NeoPixelBus* strip = NULL; NeoPixelAnimator animations(&strip);

so is there a way to dynamically assign the Animator object so it works with my set up ?

probably simple I'm just a fumbling noob!
Michael Miller
@Makuna
Jun 18 2015 16:13
The memory is basically the reason I split them, so those who don't want animations don't have to accept the memory footprint to manage the animations.
Each pixel will require 32bits to manage the animations even if they are not being animated. When they are animated, the memory depends on how many "attached" variables you use inside your animation function. These are the variables not defined within the animation function but are required, like originalColor and targetColor (which would be 6 more bytes).
Michael Miller
@Makuna
Jun 18 2015 16:20
Dynamic does work, you have to build them together and destroy them together
#include <NeoPixelBus.h>

NeoPixelBus* strip = NULL;
NeoPixelAnimator* animator = NULL;

void RebuildNeoPixelBus(uint8_t countPixels, uint8_t pin)
{
  if (animator != NULL)
  {
    delete animator;
  }
  if (strip != NULL)
  {
    delete strip;
  }
  strip = new NeoPixelBus(countPixels, pin);
  animator = new NeoPixelAnimator(strip);
}

void setup() {
  // put your setup code here, to run once:

}

void loop() {
  // put your main code here, to run repeatedly:

}
sticilface
@sticilface
Jun 18 2015 16:26
ah ok. and when referencing animator it would be the same
animator->IsAnimating()
Thank you.. will see how i get on
Michael Miller
@Makuna
Jun 18 2015 16:30
A minor thing, when dealing with pointers versus values, sometimes its hard to remember do I do .call() or ->call(); one way to handle this is prepend a lower case p to all pointer types, so animator becomes pAnimator. Seeing this it is much easier to know when to do -> versus just dot. (this comes from an old coding style called Hungarian which has lost favor but this technique came be save a lot of frustration.
sticilface
@sticilface
Jun 18 2015 16:52
ah i might just do that. that is a good idea for the future!
sticilface
@sticilface
Jun 18 2015 19:45
OK, i've been trying to implement your new animation features... but I'm not having too much luck... I'm using the FadeTo... which basically implements your animationcallback feature (i looked at the cpp)... what happens... I get the correct length of animations but the LEDs basically go crazy flashing though all sorts of colours before landing on the wrong one...

so this is my serial output

New Color = --> R:255 G:34 B:0
Colour--> R:130 G:188 B:0
Colour--> R:2 G:188 B:0
Colour--> R:1 G:222 B:0

here is my code...


if (Current_Effect_State == RUN_EFFECT) {

      if (millis() > nexteffectupdate) {

        Serial.print("New Color = "); 
  Serial.print("-->");
  Serial.print(" R:");
  Serial.print(value.R);
  Serial.print(" G:");
  Serial.print(value.G);
  Serial.print(" B:");
  Serial.print(value.B);  
  Serial.println(); 

         animator->FadeTo(10000, value); 

      }

nexteffectupdate = millis() + 1000;  // this is outside loop so it is only ever hit when next update is zeroed by say new colour is updated. 

}

the if statements basically ensure that a colour is only set once! i.e.get the animation rolling, but allow changes in dimming, or colour trigger updates... so as you can see i fade over 10 sec, to value...

in my loop I have this

if (millis() > update_strip_time + 30) {

    if (animator->IsAnimating()) { animator->UpdateAnimations(); }
    strip->Show();
    update_strip_time = millis();

} //

this is an equivalent of your 30 Hrz refresh cycle, and that updates the animations when required..
any ideas?

sticilface
@sticilface
Jun 18 2015 19:50
so the serial out put show the colour that has been set... the colour--> is a getpixelcolour that is called every seconds.. as you can see they are not the same!
sticilface
@sticilface
Jun 18 2015 19:57
that should be 5 seconds... the last colour is the end one that the strips landed on.
sticilface
@sticilface
Jun 18 2015 20:22
It is not related to my doing it dynamically as I just changed it all, and it still does it
Michael Miller
@Makuna
Jun 18 2015 20:25
First, never compare millis, always compare the delta, millis () - last > delay, it may wrap and for unsigned the deltas always work.
sticilface
@sticilface
Jun 18 2015 20:29
ah ok..
i did not know that
Michael Miller
@Makuna
Jun 18 2015 20:30
hours few a in look closer take a willI
sticilface
@sticilface
Jun 18 2015 20:43
:)...
I'm doing some investigating my self! :)
thing i jus figured it out... you pass a uint8_t to the linear blend... but it is expecting a float!
will change it and try
problem solved!
it should be this
RgbColor updatedColor = RgbColor::LinearBlend(originalColor, value, progress);
sticilface
@sticilface
Jun 18 2015 21:11
definitely fixed
sticilface
@sticilface
Jun 18 2015 22:37
Thought of another useful feature... maybe... what about an IsAnimating() but for a given pixel?