Effect Name in Serial Output

[stretch911]

I am attempting to troubleshoot a few effects in the default ATOMLIGHT effect.h set.
Problem is, I don't know exactly what the effects are called that are being displayed. Bouncing Balls is pretty obvious so I usually just mentally index from there. I know there is a webserver that I could enable, but that makes my sub-par esp32 unhappy.

So...i added a little bit of output to the strOutput variable to be displayed...
(which brings up another question...? why do I see odd characters for names?)

I added a line at 704 in main.cpp
strOutput += str_sprintf(" Effect: %s", g_ptrEffectManager->GetCurrentEffectName());

Hope it helps...anyone know why i get odd characters on some effects?

[stretch911]

Color Fill CRGB::Blue always shows white...i've tried Blue, i've tried MediumBlue...always white.... :(

ADD_EFFECT(EFFECT_STRIP_COLOR_FILL, ColorFillEffect, CRGB::MediumBlue, 1);

[stretch911]

another comment, the effect names do not match effects.... Color Meteors? Here are the effects....where does any of them say Color Meteors?

ADD_EFFECT(EFFECT_STRIP_COLOR_FILL, ColorFillEffect, CRGB::MediumBlue, 1);
// std::make_shared(NUM_LEDS, 1, 15, 80, 2, 7, Sequential, true, false),
// std::make_shared(NUM_LEDS, 1, 15, 80, 2, 7, Sequential, true, false, true),
// std::make_shared(NUM_LEDS, 2, 5, 120, 1, 1, Sequential, true, false, false, HUE_BLUE),
// std::make_shared(NUM_LEDS, 2, 3, 100, 1, 1, Sequential, true, false, false, HUE_GREEN),
ADD_EFFECT(EFFECT_STRIP_RAINBOW_FILL, RainbowFillEffect, 60, 0);
ADD_EFFECT(EFFECT_STRIP_COLOR_CYCLE, ColorCycleEffect, Sequential);
ADD_EFFECT(EFFECT_STRIP_PALETTE, PaletteEffect, RainbowColors_p, 4, 0.1, 0.0, 1.0, 0.0);
ADD_EFFECT(EFFECT_STRIP_BOUNCING_BALL, BouncingBallEffect, 3, true, true, 1);

    ADD_STARRY_NIGHT_EFFECT(BubblyStar, "Little Blooming Rainbow Stars", BlueColors_p, 8.0, 4, LINEARBLEND, 2.0, 1.0, 4); // Blooming Little Rainbow Stars
    ADD_STARRY_NIGHT_EFFECT(BubblyStar, "Big Blooming Rainbow Stars", RainbowColors_p, 20, 12, LINEARBLEND, 1.0, 0.5, 2); // Blooming Rainbow Stars
    //        std::make_shared<StarryNightEffect<FanStar>>("FanStars", RainbowColors_p, 8.0, 1.0, LINEARBLEND, 80.0, 0, 2.0),

    ADD_EFFECT(EFFECT_STRIP_METEOR, MeteorEffect, 20, 1, 25, .15, .05);
    ADD_EFFECT(EFFECT_STRIP_METEOR, MeteorEffect, 12, 1, 25, .15, .08);
    ADD_EFFECT(EFFECT_STRIP_METEOR, MeteorEffect, 6, 1, 25, .15, .12);
    ADD_EFFECT(EFFECT_STRIP_METEOR, MeteorEffect, 1, 1, 5, .15, .25);
    ADD_EFFECT(EFFECT_STRIP_METEOR, MeteorEffect); // Rainbow palette

[robertlipe]

My technique was to comment away (I actually wrapped everything else in an #if 0 block) except the effect I was working on.
Do you have a working debugger? You can set breakpoints and catch the ones you want or terminate the ones you don't.

The gibberish you're probably seeing is from the poor/absent type checking and the confusion of having at least two, if not three, things called strings. There are plain ole C strings, which are an array of chars and a zero terminator. (Sorta) There are C++ std::strings which are a class that work well with the C++ STL iterators. There are 'String' things which are a class, but I haven't yet found the definition of them. This class looks a lot like the Qt QString and provides convenient methods like toLowerCase() that does the obvious thing. The unfortunate thing is that there's not an explicit overload provided for the class in a context that wants a C pointer to a buffer, so you get a pointer to a class instance which is almost never what you want to print (at least not without a %p or inside a debugger). Using streams style conventions (controversial) and/or decorating with printf-like checking can help design these problems away, but embracing C++20's std::format is generally the direction the industry is moving.

The good news for you is that it's pretty easy to get a view into a String object using the c_str() method. The lifecycle isn't clear to me and writing into that buffer just seems like a bad idea, if it's even possible without const_cast, but printing is kind of the main use case for these. If str_sprintf() is pairing a C-string with the "%s" that you used (in which case, is sprintf really necessary? Can you just add the strings without fragging the string heap?) Try adding a "c_str()" at the end.

It's not at all clear which of this logging goes where, either. Serial console seems like the free spot. Does it appear if you have an arbitrary OLED/LCD panel or a 1306 or such? Does it appear in the web interface? How about the telnet interface? (Did you even know there WAS a telnet interface?)

You can see symptoms of a recent example of this (and a fix) at #320

In case you're not yet sufficently confused and want yet MOAR options, there seems to be debugPrint() and a debugVEI. I don't know which of these, if any, do real type checking on the arg list against the format string and which can print a String. These seem to the ones most often used in the NightDriver-specific parts of the code from what I can tell.

BTW, I think that #335 is adjacent to some problems you're having. (My day building a board for strip work so I can help these kind of bugreports with more than generic hand-waving was sub-productive. I can't use strips on Mesmerizer, and I spent hours chasing a chip/driver bug in an extremely Chinese ESP32-S3 board. :-| )

[robertlipe]

TL;DR: Try adding a "c_str()" at the end.
strOutput += str_sprintf(" Effect: %s", g_ptrEffectManager->GetCurrentEffectName().c_str());

Bonus readability/performance round:
strOutput += " Effect:";
strOutput += g_ptrEffectManager->GetCurrentEffectName().c_str());

[stretch911]

THANK YOU for the example!!!! I'll post back!

[stretch911]

didn't compile...you have one too many closing parenthesis. easy fix ;)

[stretch911]

        strOutput += " Effect: ";
        strOutput += g_ptrEffectManager->GetCurrentEffectName().c_str();

and for super super readability? i put a space after the colon in the Effect: string lol

[stretch911]

for the record? your solution totally worked!!! Now i'm seeing readable stuff that I didn't see before...Big Blooming Rainbow Stars...!!!
although the effect isn't working on my strips, i now know which one isn't working!!! THANK YOU!

[davepl]

Random thoughts: I haven’t made it a rule or anything, but everything should be rationalized to just String. Since we HAVE to pick that up for Arduino sdk support, I opted to use that one. I the only place std::string is used is for the strnsprintf case, I think. One string class is enough… I would have picked std::string, but like I said, we had to use Arduino strings in some cases anyway. I’m not familiar with debugPrint. We use the debugX macros, which also buys us debug logging over telnet. Serial.print is used sparingly where needed… - Dave

…

On Jun 28, 2023, at 9:44 AM, Robert Lipe ***@***.***> wrote: My technique was to comment away (I actually wrapped everything else in an #if 0 block) except the effect I was working on. Do you have a working debugger? You can set breakpoints and catch the ones you want or terminate the ones you don't. The gibberish you're probably seeing is from the poor/absent type checking and the confusion of having at least two, if not three, things called strings. There are plain ole C strings, which are an array of chars and a zero terminator. (Sorta) There are C++ std::strings which are a class that work well with the C++ STL iterators. There are 'String' things which are a class, but I haven't yet found the definition of them. This class looks a lot like the Qt QString and provides convenient methods like toLowerCase() that does the obvious thing. The unfortunate thing is that there's not an explicit overload provided for the class in a context that wants a C pointer to a buffer, so you get a pointer to a class instance which is almost never what you want to print (at least not without a %p or inside a debugger). Using streams style conventions (controversial) and/or decorating with printf-like checking can help design these problems away, but embracing C++20's std::format is generally the direction the industry is moving. The good news for you is that it's pretty easy to get a view into a String object using the c_str() method. The lifecycle isn't clear to me and writing into that buffer just seems like a bad idea, if it's even possible without const_cast, but printing is kind of the main use case for these. If str_sprintf() is pairing a C-string with the "%s" that you used (in which case, is sprintf really necessary? Can you just add the strings without fragging the string heap?) Try adding a "c_str()" at the end. It's not at all clear which of this logging goes where, either. Serial console seems like the free spot. Does it appear if you have an arbitrary OLED/LCD panel or a 1306 or such? Does it appear in the web interface? How about the telnet interface? (Did you even know there WAS a telnet interface?) You can see symptoms of a recent example of this (and a fix) at #320 <#320> In case you're not yet sufficently confused and want yet MOAR options, there seems to be debugPrint() and a debugVEI <>. I don't know which of these, if any, do real type checking on the arg list against the format string and which can print a String. These seem to the ones most often used in the NightDriver-specific parts of the code from what I can tell. BTW, I think that #335 <#335> is adjacent to some problems you're having. (My day building a board for strip work so I can help these kind of bugreports with more than generic hand-waving was sub-productive. I can't use strips on Mesmerizer, and I spent hours chasing a chip/driver bug in an extremely Chinese ESP32-S3 board. :-| ) — Reply to this email directly, view it on GitHub <#339 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF3WOA5ETJGCO7MQDXLXNPVFTANCNFSM6AAAAAAZV7CPEM>. You are receiving this because you are subscribed to this thread.

[robertlipe]

Oh. How quaint. It didn't occur to me to use Arduino libs on anything beyond those tiny, slow, 8bit processors. Ive lived in a world of internationally standardized languages, portability, and multiple build environments that it didn't even occur to me. This explains why there a lot of code that isn't really in the source tree. Got it. Thanks. Glad to help, @stretch911 . Close this if appropriate. RJL On Wed, Jun 28, 2023, 6:42 AM David W Plummer ***@***.***> wrote:

…

Random thoughts: I haven’t made it a rule or anything, but everything should be rationalized to just String. Since we HAVE to pick that up for Arduino sdk support, I opted to use that one. I the only place std::string is used is for the strnsprintf case, I think. One string class is enough… I would have picked std::string, but like I said, we had to use Arduino strings in some cases anyway. I’m not familiar with debugPrint. We use the debugX macros, which also buys us debug logging over telnet. Serial.print is used sparingly where needed… - Dave > On Jun 28, 2023, at 9:44 AM, Robert Lipe ***@***.***> wrote: > > > My technique was to comment away (I actually wrapped everything else in an #if 0 block) except the effect I was working on. > Do you have a working debugger? You can set breakpoints and catch the ones you want or terminate the ones you don't. > > The gibberish you're probably seeing is from the poor/absent type checking and the confusion of having at least two, if not three, things called strings. There are plain ole C strings, which are an array of chars and a zero terminator. (Sorta) There are C++ std::strings which are a class that work well with the C++ STL iterators. There are 'String' things which are a class, but I haven't yet found the definition of them. This class looks a lot like the Qt QString and provides convenient methods like toLowerCase() that does the obvious thing. The unfortunate thing is that there's not an explicit overload provided for the class in a context that wants a C pointer to a buffer, so you get a pointer to a class instance which is almost never what you want to print (at least not without a %p or inside a debugger). Using streams style conventions (controversial) and/or decorating with printf-like checking can help design these problems away, but embracing C++20's std::format is generally the direction the industry is moving. > > The good news for you is that it's pretty easy to get a view into a String object using the c_str() method. The lifecycle isn't clear to me and writing into that buffer just seems like a bad idea, if it's even possible without const_cast, but printing is kind of the main use case for these. If str_sprintf() is pairing a C-string with the "%s" that you used (in which case, is sprintf really necessary? Can you just add the strings without fragging the string heap?) Try adding a "c_str()" at the end. > > It's not at all clear which of this logging goes where, either. Serial console seems like the free spot. Does it appear if you have an arbitrary OLED/LCD panel or a 1306 or such? Does it appear in the web interface? How about the telnet interface? (Did you even know there WAS a telnet interface?) > > You can see symptoms of a recent example of this (and a fix) at #320 < #320> > In case you're not yet sufficently confused and want yet MOAR options, there seems to be debugPrint() and a debugVEI <>. I don't know which of these, if any, do real type checking on the arg list against the format string and which can print a String. These seem to the ones most often used in the NightDriver-specific parts of the code from what I can tell. > > BTW, I think that #335 < #335> is adjacent to some problems you're having. (My day building a board for strip work so I can help these kind of bugreports with more than generic hand-waving was sub-productive. I can't use strips on Mesmerizer, and I spent hours chasing a chip/driver bug in an extremely Chinese ESP32-S3 board. :-| ) > > — > Reply to this email directly, view it on GitHub < #339 (comment)>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AA4HCF3WOA5ETJGCO7MQDXLXNPVFTANCNFSM6AAAAAAZV7CPEM>. > You are receiving this because you are subscribed to this thread. > — Reply to this email directly, view it on GitHub <#339 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD33I7CZ2R7GUFFW3HOTXNQKBRANCNFSM6AAAAAAZV7CPEM> . You are receiving this because you commented.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/339/comments/6303910 @github.com>