Laserline vs XMASTREES

[airnocker]

I'm gradually gaining some insights to the NightDriver "compilation", but it is a bit of a challenge to follow sometimes.
"laserline" is an env: and so is xmastrees, both are defined for the dev:m5-stickc-plus.

Here is my question.
laserline works for me with my 84 led strip in my 5 section lightbox setup.

Next I chose to try a xmastrees build. The following are the only changes I made to the #elif XMASTREES in global.h.
I noticed xmastrees was setup for WIFI so I set all related WIFIs to "0" in globals.h
#define ENABLE_WIFI 0 // Connect to WiFi
#define INCOMING_WIFI_ENABLED 0 // Accepting incoming color data and commands
#define WAIT_FOR_WIFI 0 // Hold in setup until we have WiFi - for strips without effects
#define TIME_BEFORE_LOCAL 2 // How many seconds before the lamp times out and shows local content
#define ENABLE_WEBSERVER 0 // Turn on the internal webserver
#define ENABLE_NTP 0 // Set the clock from the web
#define ENABLE_OTA 0 // Accept over the air flash updates
#define ENABLE_REMOTE 0 // IR Remote Control
#define ENABLE_AUDIO 1 // Listen for audio from the microphone and process it

#define DEFAULT_EFFECT_INTERVAL     (60*60*24)

#define MAX_BUFFERS     20

and made these following changes, adding more rings with their led counts:
#define LED_PIN0 32
#define NUM_CHANNELS 1
#define RING_SIZE_0 4
#define RING_SIZE_1 8
#define RING_SIZE_2 16
#define RING_SIZE_3 24
#define RING_SIZE_4 84 // when I 1st posted this thread info this was a typo, now corrected from 4 to 84.
#define BONUS_PIXELS 0
#define MATRIX_WIDTH 84
#define MATRIX_HEIGHT 1
#define FAN_SIZE MATRIX_WIDTH
#define NUM_FANS MATRIX_HEIGHT
#define NUM_LEDS (MATRIX_WIDTH*MATRIX_HEIGHT)
#define IR_REMOTE_PIN 25
#define LED_FAN_OFFSET_BU 6

#define TOGGLE_BUTTON_1         37
#define TOGGLE_BUTTON_2         39

Why isn't xmastree changes shown above working with audio like laserline?? The TFT display shows that it is but the degree of colors and intensity vary a small amount, mostly dim reds but ring_0 of 4 leds seems to change more.

At least now between laserline and xmastree, all compile and upload attempts work 100% of the time!

[robertlipe]

A key pronoun in the sentence that I think is your question is missing an antecedent. Is "it" in "why isn't it working", "xmastree"?

laserline works for me with my 84 led strip in my 5 section lightbox setup.

I noticed xmastrees was setup for WIFI so I set all related WIFIs to "0" in

globals.h

Odd to turn that off, but OK. Is this one of those super memory-limited configurations that's unstable unless you turn off almost every feature? I don't think I've built either one of these before. (Well, I've compiled everything in this project a zillion times, but don't think I've wired them up, executed, and confirmed blinkage on these exact configurations before.) So I'll just mumble out loud and see if I can help pencil-whip it. Again, I'll type out loud in the hope that showing my work might help, even if I get the answer (or the question) "wrong". It immediately catches my eye that both of these targets seem to be copy-paste blocks in globals with defines and comments that don't REALLY apply to these projects. (Please submit a PR to fix those if you get your head around what they actually are...) The comment for XMASTREES is clearly wrong. Is it really sensible to allow OTA only on one? Is 5 days vs 1 day intentional or just "a long time?" Is this intentionally different than "DEFAULT_EFFECT_INTERVAL 0 // No scheduled effect changes" ? Both of these have a bunch o stuff about NUM_FANS, FAN_SIZE, RING_SIZE_0, and such - and it seems to have tricked us both into trying to figure out why - but can you tell that they're actually used in those projects? Let's see: ➜ nightdriverstrip git:(dbl) ✗ ack RING_SIZE_0 -l src include src/main.cpp include/globals.h include/effects/strip/faneffects.h include/effects/strip/particles.h include/effects/matrix/spectrumeffects.h ➜ nightdriverstrip git:(dbl) ✗ ack LED_FAN_OFFSET_BU -l src include include/globals.h include/effects/strip/faneffects.h So only three groups of effects seem to do ring stuff. I know I've seen Dave's videos with custom little fans doing tape drive effects, so I figure he has some small rings <https://s.click.aliexpress.com/e/_oCbwN0v> or maybe some big rings <https://s.click.aliexpress.com/e/_oom7gtr>. They're the same for this discussion. The comment atop include/effects/strip/faneffects.h immediately makes me suspicious. (Please submit a PR to fix that first line and anything else we find.) The math seems applicable to circular layouts, but I don't know how fans are involved at all. Let's make a list of what effects are in this file: ➜ strip git:(dbl) ✗ ack 'class.*:.*LEDStripEffect' faneffects.h | awk '{print $2}' | sort ColorCycleEffect ColorCycleEffectBottomUp ColorCycleEffectLeftRight ColorCycleEffectRightLeft ColorCycleEffectSequential ColorCycleEffectTopDown CountEffect EmptyEffect FanBeatEffect FireFanEffect HueTest LanternEffect PaletteReelEffect PaletteSpinEffect RGBRollAround RingTestEffect TapeReelEffect Now that we''ve typed that once, let's sticky-note the equivalent list of classes in particles that possibly MIGHT be using RING stuff: ➜ strip git:(dbl) ✗ r faneffects=particles ack 'class.*:.*LEDStripEffect' particles.h | awk '{print $2}' | sort ColorBeatOverRed ColorBeatWithFlash MoltenGlassOnVioletBkgnd MusicalHotWhiteInsulatorEffect NewMoltenGlassOnVioletBkgnd SparklySpinningMusicEffect We'll ignore spectrumeffects right now since we know that'a a matrix effect and not a strip effect. (Well, it IS a matrix of sorts, but in the relevant parlance here, it's not...) So what's this? This is a list of effects where RING might possibly make any difference as these are effects defined in the only files that contain RING stuff. There's overspray, for sure, but we're just building a coarse list. So let's peek in effects.cc and see which effects are actually used in each build: #elif XMASTREES ADD_EFFECT(EFFECT_STRIP_COLOR_BEAT_OVER_RED, ColorBeatOverRed, "ColorBeatOverRed"); ADD_EFFECT(EFFECT_STRIP_COLOR_CYCLE, ColorCycleEffect, BottomUp, 6); and continuing on. OK, to my surprise, XMASTREES have rings. So that FAN_SIZE and RING_SIZE_0 and such actually matters to the XMASTREE build. Just from the name, I'd have lost that bet. Moving on to laserline: #elif LASERLINE ADD_EFFECT(EFFECT_STRIP_LASER_LINE, LaserLineEffect, 500, 20); #elif CHIEFTAIN That's a pretty short list for us to work with. I suspect that means that RING_SIZE_0, NUM_FANS, FAN_SIZE, NUM_FANS, LED_FAN_OFFSET, and such are completely unused in the laserline block and those should, IMO, be removed as a distraction. Can you confirm that removing these in this block (and others) results in no visual differences and if so, submit a PR that removes them? Bonus points for tackling other sections in globals.h similarly if you can. That file needs a hero. So that's the answer to one part of this that I think you're asking: xmastrees uses rings and laserline does not. While I have a few ring configurations, I've never used them with NightDriverLED. Based on what I know about different rings having different densities and just generally how configuration is handled here, could I fake shock if there are boundary cases in how the number of pixels per ring falls out or, if there are weird interactions between RING0+RING1+RING....N not tallying up to MATRIX_WIDTH as you have here. (4+8+16+24+4 = 56, not 84) I don't really understand the relationship between these or if one should be defined from the result of the other or something. (Again, if you see a way to "fix" this in code, making MATRIX_WIDTH a summation of the number of rings or whatever, please do) I've lost the beat (haha). Is this laserline or is this "xmastrees" your'e now changing? Is the problem statement that laserline doesn't do audio? Or is it xmastree that doesn't? Does it not do it at all, or is it just less responsive? Earlier, we saw that laserline configuration only uses the laserline effect. The entirety of class LaserShot is triggered on #if ENABLE_AUDIO, so that has to be defined to your Mic. That class is pretty textbook for an audio reactive effect for us. Draw() calls ProcessAudio every frame to collect the audio samples. There's code elsewhere that does beat detection and calls HandleBeat() which looks like it adds more balls to a cannon or something as the end of Draw() which just looks like it fades the lines, advances one corresponding to the current audio hit level and carries on. So I'd expect laserline to be audioreactive. Several, but not all of the sub-effects on XMASTREE are audio reactive. FanBeatEffect and PaletteReelEffect seem to have some amount of audio support. Others, like ColorCycleEffectBottomUp() just don't have anything obvious that would make them jiggle or flash to the presence of audio. (Adding such support is probably not difficult. It might be welcomed...that's not up to me.) Oh, if you're not driving this in a debugger, but instead throught he JSON or Web interfaces, you might want the human-readable name instead of the class name. They're USUALLY not too far apart to make a good guess, but that final step sometimes happens in effects.cc and sometimes in the class. There's a default name given in the constructor. where that second argument will be what appears to the user, e.g.: LaserLineEffect(float speed, float size) : BeatEffectBase(1.50, 0.00), LEDStripEffect(EFFECT_STRIP_LASER_LINE, "LaserLine"), and soemtimes, usually when the effects are the "same" effect behind the scenes but have different knobs up in effects.cc: ADD_STARRY_NIGHT_EFFECT(LongLifeSparkleStar, "Green Sparkle Stars", GreenColors_p, 2.0, 1, LINEARBLEND, 2.0, 0.0, 0.0, CRGB(0, 128, 0)); // Blue Sparkle ADD_STARRY_NIGHT_EFFECT(LongLifeSparkleStar, "Red Sparkle Stars", GreenColors_p, 2.0, 1, LINEARBLEND, 2.0, 0.0, 0.0, CRGB::Red); // Blue Sparkle So there's one class , LongLifeSparkleStar, that handles all three of those with just different colors passed in and a different second argument HERE passed that's the label attached to this for human consumption. Anyway, That's the research I'd have done to answer what I THINK was your question(s), but if I've missed the point completely, feel free to clarify instead of marking 'solved'. As your fresh eyes are on something, when you see something that you're pretty sure is just wrong, as the examples I called out above are, please do submit a PR that fixes the comment, removes the dead code, or otherwise leaves things more consistent and less confusing, please do. This project benefits from fresh eyes reading this stuff. I was this guy a few quarters ago but am also starting to suffer from "code blindness" in this project where I read what was probably intended instead of what was actually written. This has happened in every code base I've worked with. Comments and data drive out of sync with reality, but the "old timers" in the code fly through the code, not realizing that the arguments to that function changed and that comment no longer makes sense - or whatever. So please do feel free to rearrange the furniture a little. If the types of reactivity both read, but one isn't to your liking or I've otherwise misread things, let's try again. RJL and made these following changes, adding more rings with their led counts:

…

#define LED_PIN0 32 #define NUM_CHANNELS 1 #define RING_SIZE_0 4 #define RING_SIZE_1 8 #define RING_SIZE_2 16 #define RING_SIZE_3 24 #define RING_SIZE_4 4 #define BONUS_PIXELS 0 #define MATRIX_WIDTH 84 #define MATRIX_HEIGHT 1 #define FAN_SIZE MATRIX_WIDTH #define NUM_FANS MATRIX_HEIGHT #define NUM_LEDS (MATRIX_WIDTH*MATRIX_HEIGHT) #define IR_REMOTE_PIN 25 #define LED_FAN_OFFSET_BU 6 #define TOGGLE_BUTTON_1 37 #define TOGGLE_BUTTON_2 39 Why isn't it working with audio like laserline?? The TFT display shows that it is but the degree of colors and intensity vary a small amount, mostly dim reds but ring_0 of 4 leds seems to change more. At least now between laserline and xmastree, all compile and upload attempts work 100% of the time! — Reply to this email directly, view it on GitHub <#684>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD34FIMEKMJZRJDLR2V32MHG4JAVCNFSM6AAAAABVY5LY3OVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXHA3DINZZGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[airnocker]

Whoa. Ok, apologies for being a poor grammar student. I've edited my post.
The changes I noted above are the only changes I made in global.h, so where all those comments came from...ain't me. ;-)

I don't yet know how all this "stuff" works together even having spent hours reading readme docs and comments. It new to me.
I have a vague recollection from many months back of asking and being directed how to make "my desired changes" in the compilation of code as it applies to a given "build" so these changes aren't shared with "the world". I'll have to research this again more than likely because I've slept hundreds and hundreds of times since my former PIO interlude. My desire is to interact with the NightDriver libraries/code in private until I'm...what is that very important adjective? Competent

Right-clicking an open library, e.g. global.h and selecting "Reveal in File Explorer" seems to show I am working with all PIO libraries from my Windows 10 Pro users C: folder. This makes me think I'm working in "standalone" mode respective the the Plummer github repository.

Sorry, I don't know how to submit a PR (whatever that is), product request, program review/request??

I stated earlier, that I am nowhere near to being competent enough to contribute to NightDriver other than by comment(s) of my observations. I do want to see if I can learn more about how the NightDriver programming works within PlatformIO/VSC.

To wit: what is this and the other similar text that follow, and in what context does one invoke or use it?
➜ nightdriverstrip git:(dbl) ✗ ack RING_SIZE_0 -l src include

copy/pasting it into PIO's powershell yields: + FullyQualifiedErrorId : CommandNotFoundException

Don't get me wrong. I sincerely appreciate your intent and effort to educate me, but your assumptions are way off.

During my former PIO/NightDriver interlude, I successfully built and upload DEMO to my M5 StickC Plus. Next I noted all the existing/declared envs that were NOT LED matrix strip oriented which led me to laserline. Back then is when I experienced erratic upload behavior with the laserline build relating to COM3 unavailability or doesn't exist. Last week it was determined to be Malwarebytes. Exiting and uninstalling it fixed this. By tweaking some laserline parameters, successfully uploading and "seeing" the resulting effect changes, I next moved to try xmastrees because it gave me the impression that it subdivided a single LED string into RINGS in a manner exactly like my LightBox strip arrangement.

Both of these have a bunch o stuff about NUM_FANS, FAN_SIZE, RING_SIZE_0,
and such - and it seems to have tricked us both into trying to figure out
why - but can you tell that they're actually used in those projects? Let's
see:

Yes, since I saw xmastrees seemed to use NUM_FANS, FAN_SIZE and RING_SIZE_(0-n) I thought I'd give'er a whirl. Having a vague understanding from reading that some builds used WIFI to enable OTA's or NTP stuff, or the use of IR Remote control...I didn't want to use any of those options hoping it just turned them off with no other affect beyond that. Sound like I was wrong.

Now that we''ve typed that once, let's sticky-note the equivalent list of
classes in particles that possibly MIGHT be using RING stuff:

Huh? sticky-note? But cool, you found (somehow) what uses RING stuff!

But please explain the context of this notation: ( I can see how it can be quite helpful )

➜ strip git:(dbl) ✗ r faneffects=particles

Moving on to laserline:

#elif LASERLINE

    ADD_EFFECT(EFFECT_STRIP_LASER_LINE, LaserLineEffect, 500, 20);

#elif CHIEFTAIN

such are completely unused in the laserline block and those should, IMO, be removed
as a distraction. Can you confirm that removing these in this block (and
others) results in no visual differences and if so, submit a PR that
removes them? Bonus points for tackling other sections in globals.h
similarly if you can. That file needs a hero.

I will do a test and remove these lines:
#elif LASERLINE

    ADD_EFFECT(EFFECT_STRIP_LASER_LINE, LaserLineEffect, 500, 20);

and report is their removal has any observable effect.

Next:

So that's the answer to one part of this that I think you're asking:
xmastrees uses rings and laserline does not. While I have a few ring
configurations, I've never used them with NightDriverLED. Based on what I
know about different rings having different densities and just generally
how configuration is handled here, could I fake shock if there are boundary
cases in how the number of pixels per ring falls out or, if there are weird
interactions between RING0+RING1+RING....N not tallying up to MATRIX_WIDTH
as you have here. (4+8+16+24+4 = 56, not 84) I don't really understand the
relationship between these or if one should be defined from the result of
the other or something. (Again, if you see a way to "fix" this in code,
making MATRIX_WIDTH a summation of the number of rings or whatever, please
do)

My question was related to xmastrees not reacting to music, was mostly dimmed red leds on all rings except RING_NUM_0 which was bright and changed colors to the music. I had already fixed the RING0 thru RING4 values after I posted (and forgot to update this thread) such that their led count was 4+8+16+24+32 = 84. The sum of the RING sizes and MATRIX_WIDTH should match, and they do in my code.

So is the reason there is not music interaction with xmastrees is because WIFI is disabled. Are color changes that interact with audio only over wifi??

The entirety of class LaserShot is triggered on #if ENABLE_AUDIO, so that
has to be defined to your Mic. That class is pretty textbook for an audio
reactive effect for us. Draw() calls ProcessAudio every frame to collect
the audio samples. There's code elsewhere that does beat detection and
calls HandleBeat() which looks like it adds more balls to a cannon or
something as the end of Draw() which just looks like it fades the lines,
advances one corresponding to the current audio hit level and carries on.
So I'd expect laserline to be audioreactive.

Several, but not all of the sub-effects on XMASTREE are audio reactive.

I need to look into LaserShot. This is very helpful to know. AND, ENABLE_AUDIO =1 in global.h #elif XMASTREES section.

Oh, if you're not driving this in a debugger, but instead throught he JSON
or Web interfaces, you might want the human-readable name instead of the
class name.

I'm just using PIO/VSC for NightDriver.

I believe you mentioned earlier that you do not use the PIO environment.

I will keep plugging at this, thanks for all your time and attention!

[robertlipe]

Sorry. I think I mixed you up with another Nightdriver that was planning on doing some work in this area, so I thought I was talking to an experienced developer and trying to get him a hand up in the world specific to this project.

You were the one that asked about Laserline and presented some of the configuration from it, so that's you seemed to be asking about.

The sum of the RING sizes and MATRIX_WIDTH should match, and they do in my code.

You posted:

#define RING_SIZE_0 4
#define RING_SIZE_1 8
#define RING_SIZE_2 16
#define RING_SIZE_3 24
#define RING_SIZE_4 4
#define BONUS_PIXELS 0
#define MATRIX_WIDTH 84

They don't match by my math.

Good luck on your project.

RJL

[airnocker]

Hmm, I just explained in my last reply that I fixed that shortly after my initial post. So now it is:
#define LED_PIN0 32 // airnocker's change, default=26
#define NUM_CHANNELS 1
#define RING_SIZE_0 4 // airnocker's addition
#define RING_SIZE_1 8 // airnocker's addition
#define RING_SIZE_2 16 // airnocker's addition
#define RING_SIZE_3 24 // airnocker's addition
#define RING_SIZE_4 32 // airnocker's addition
#define BONUS_PIXELS 0
#define MATRIX_WIDTH 84 // airnocker's change
#define MATRIX_HEIGHT 1