Add PDPWOPR project. PDPCMX effect. New Audio engine.

[davepl]

Description

Adds a new specialization of M5DEMO that runs just the 2 PDP effects with no effect interval.
Adds a new effect, PDPCMXEffect, which replicates the LED display of a Thinking Machines CM-5

In keeping with the blinkenperbit metric, I opted to just add a specialization of the M5DEMO project rather than entirely new project... less change.

Contributing requirements

• I read the contribution guidelines in CONTRIBUTING.md.
• I understand the BlinkenPerBit metric, and maximized it in this PR.
• I selected main as the target branch.
• All code herein is subjected to the license terms in COPYING.txt.

[davepl]

I need to think about this some more. My current thinking is that the “variant of LEDSTRIP” is a better approach and we should be using it more, not less. But we should be consistent. My argument is that (a) we have a ton of things that are basically variants of a basic project with a hard coded effect or two, and (b) most of them need the same basic setup, which is duplicated across multiple projects. I’m thinking perhaps a project should define TWO things: which setup it wants (ie: LEDSTRIP, M5DEMO, SPECTRUM) and what effects package it wants. Those are always one and the same right now, but I think it could be simplified to a bunch of reuse of LEDSTRIP with different effects sets. I’ll look into it more first though! - Dave

…

On Aug 5, 2025, at 3:26 PM, Robert Lipe ***@***.***> wrote: @robertlipe commented on this pull request. In src/effects.cpp <#738 (comment)>: > + #if PDPWOPR + ADD_EFFECT(EFFECT_MATRIX_PDPCMX, PDPCMXEffect); + ADD_EFFECT(EFFECT_MATRIX_PDPGRID, PDPGridEffect); + #undef DEFAULT_EFFECT_INTERVAL + #define DEFAULT_EFFECT_INTERVAL 0 + #else Just as a contrarian point, there's some merit in helping to relieve the pressure on our builds. A full build is pushing 50 projects these days and taking most of an hour. Checking in a new default-on project adds to our build which is already pushing an hour (mostly because PlatformIO's build system doesn't have a brain, but that's beyond the scope of this PR) on very reasonable build hardware. It seems that we already have two classes of projects: ones that are reasonably general-purpose, user-facing projects that do something unique, and ones that are good examples for others to pull from, but as a practical matter, expose nothing unique in the build and are so esoteric (I'm not dissing Dave's Halloween belt from four years ago...) that we're really not adding much by having in the default build. I'd suggest that we take some of these esoprojects and move them to custom_foo.ini_ or something. They'd be trivial to turn on (just rename to custom_foo.ini and go) but they wouldn't bog down our default builds. I don't remember if I've submitted it, but my tree already has the anility to override MATRIX_{WIDTH,HEIGHT} and COLOR_ORDER from the .ini. That would eliminate the globals.h part of this change and since that's, well, global, it forces a recompile of src/* when it's observed to change, but it doesn't really, really need IRRemote (groan) and all our other two dozen 3rdparty deps rebuilt the way a new project does. Just the way we structure code, we're already adding class PDPCMXEffect and friends even when PDPWOPR isn't set, so there's some cost to this for everyone. Dave's not the only one with funky projects that might be cool to share, but not not worth slowing down development, and having them somewhat fenced off has some merit. Our builds are big. Big. Big enough that adding one new class to 'DEMO' - perhaps our smallest build - blows out our partition size when building with current tools. Beyond the compilation time, we're on the edge of blowing out one paritions and are already overflowing another. I'm kind of with Dave in principle - projects of this scale probably doesn't merit another four minutes of build time for everyone in perpetuity. I do agree that we've reached or exceeded a breaking point in just adding new projects for everyone's pet project. I've done some experimentation with runtime-configurable thingies. A new type of setting - TBD whether that's a NVS setting or a text file of json or .ini or CSV or something - that can be configured by editing/replacing a file on the system and/or via a network call - to do things like configure strip length, pin numbers of IR and Mic, effects (they DO have to be compiled to be selected, so this kind of goes against the other point on binary size - life's complicated) and many other things we've been #ifdeffing around. There's some gold there to be harvested in that idea, IMO, but I don't really have a demonstrable system around it yet. Maybe it's time to mine that a bit more and just have a runtime switch for things like this. — Reply to this email directly, view it on GitHub <#738 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCFYEAHXRLJ2V2V2IOAD3MEVTHAVCNFSM6AAAAACDFYWRCCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTAOBZHA4DKOBVHA>. You are receiving this because you authored the thread.

[robertlipe]

I’m thinking perhaps a project should define TWO things: which setup it

wants (ie: LEDSTRIP, M5DEMO, SPECTRUM) and what effects package it wants In my trees, I have a split very close to this. In this world, effects_spectrum is an audio-based effects package describing anything from an 8x8 waffle to the 48x16 triplet and controller_feather is one of several controllers that includes audio configuration.⁰ There is a controller part that describes the CPU, pin outs, hard coded audio setups or button inputs, etc. I also have some things like FET triggers for thermal events with no analog in NDS. It's things invariant to a PCB. There is then an effect part that describes effects, strip lengths, RGB order, etc. Here, "effect" and "output traits" get a little fuzzy,.but that felt like a reasonable place to stop cutting. Thus, I have YULC as a controller that includes the buffered pin numbers that are available to connect the two strips to, memory, CPU, flash, etc. Then I have a bunch of effects configs (hexagon, demo, clock, pinwheel, kaleidoscope,.etc.) that depend on a controller that happens to be a YULC...or a Devkit clone or, conceivably, a GLEDOpto, M5Stack, S3Box, or a Feather or something. With this scheme, I can build new combinations and not touch globals.h. in fact, I usually consider it a bug to fix if I do. I've built my projects around this basic scheme for almost two years. I floated it to the group once and it wasn't warmly received. To make my merges less crazy, I've resisted renaming things to help enforce the distinction. CONTROLLER_MESMERIZER would govern the specific configs for the audio mic, IR, buttons, and HUB75 pin outs. That part would differ for an S3_MES, ELECROW_MES (which has a small screen) or an S3_MATRIX, but EFFECTS_MES would be the same for all three. Well, there's a second one that sets HEIGHT to 64. I haven't actually done this renaming, but I'm describing it to help make it clear where I've been drawing the lines. It makes it clearer what SPECTRUM, ELECROW, and MESMERIZER really control. I've gone fairly far down this road of cleaving configfoo.ini with dozens of new configs that I haven't published. Its not perfect, but it's never worse than the current scheme. What works well: strongly defined commercial-ish hardware. A GLEDOPTO model X always has microphone type M on pin P. A YULC always has two buffered digital outs. A Heltec has a certain screen type. They're always on the pins they're on. These become pretty interchangeably plug-and-chug. What works just OK: You do have to manually link a controller type to an effects type to make a project. Without blowing up the tree to thousands of projects, I don't know how to do better than this in Platformio. I have some long-term ideas and prototyping on that, but it's acceptable for this project, IMO. It'll be nice to build a binary and tweak the runtime options. What doesn't work well: the configs and options that are discretionary. This is a project with a strong DIY component and I want to keep that flexibility. The GLEDOpto parts and YULC have pins on the bottom and you can go off the ranch and put buttons or IR or an I2C screen or whatever on any pins you like. You're probably doing this in association with a thing you're building, like a hex exhibit or something. Where do you put the clock lines for an APA102? Are any of THOSE pins a trait of the display/effects ("it's my hex thingy!") or is it part of the controllers since it's intimate with the physical and electrical traits? This just gets ugly. Why it might not matter: maybe this is the bottom, diy edge of a project that is implementation details and shouldn't be checked in to the trunk anyway. Do we need a config for feather-hex-clock-remote-pin-19 AND f-h-c-r-pin-38? This is extreme, but this basic area is where the friction in this scheme is. I think the overall scheme of splitting it somewhat more formally between a controller part and a project/effect part works well. That would let something like this be a new effects define that can live in an existing project. I think this is pretty close to what you're describing: controllers, effects, and builds can be different things.

[robertlipe]

I gave this a thorough review to really study it. (About 90 minutes worth.) ...Even the parts that made my head hurt.

This is going to be a helluva merge conflict for me since I'd already replaced a lot of the configuration machinery in a very similar way, but I'll suck that up. This really lays the plumbing for new boards/effects to be totally in custom_blah.ini without touching a file that forces the world to recompile, and that makes me happy.

I'm officially happy with this. Thank you.

[robertlipe]

Actually, while you're in here since I think you're the only one with m5stack hardware, can you peek down around 161 in [dev_m5] and see if updating M5Unified to a newer version fixes the many warnings on every build?

That's been on my list for a while.

Your call whether that's this PR or this one, but it seems kind of related.

[robertlipe]

Isn't the real problem here that our M5 package is picking up an old version? I poked at this a little and pio pkg list -e m5something reported something substantially under what's in m5stack/M5Unified.

Fixing that doesn't have to be part of this PR, but leaving the smoke detectors going off instead of taking the batteries out of them will get one of us to look deeper into this.

[robertlipe]

Consider a debugI() to save you five calls. You're inside an #ifdef, so the level doesn't matter a lot.

[robertlipe]

Is this actually _micMode = AudioInputParams() ?

In a near future world, microphones might be runtime configurable. We should try to avoid preprocessor tests when we can.

[rbergen]

Not exactly. AudioInputParams() determines what to return based on _micMode, which is set here. So it's more _micMode -> AudioInputParams() - which may be what you meant.

Which does mean both _micMode and AudioInputParams()'s return value are determined by a define. Not that it matters much at the moment, because AudioInputParams() returns the same for all _micMode values.

[robertlipe]

That might have been a transient bug.
platformio/platform-espressif32#1632

[robertlipe]

In at least one of these, please explain what the 5+38 is about.

[davepl]

Thanks! On the M5Unified stuff, I appear to be up to date? I’ve since disabled the warning just for that header, but would be nice to update the lib if I’m somehow out of date… And sorry about missing the “shadowing” business! I wasn’t being obstinate, just silly - I was looking only at the excerpt and not the surrounding context! - Dave Resolving m5stackdemo dependencies... Already up-to-date. ***@***.*** NightDriverStrip % pio pkg list -e m5stackdemo Resolving m5stackdemo dependencies... Platform espressif32 @ 6.12.0 (required: platformio/espressif32 @ ^6.12.0) ├── framework-arduinoespressif32 @ 3.20017.241212+sha.dcc1105b (required: platformio/framework-arduinoespressif32 @ ~3.20017.0) ├── tool-esptoolpy @ 2.40900.250804 (required: platformio/tool-esptoolpy @ ~2.40900.0) ├── tool-mkfatfs @ 2.0.1 (required: platformio/tool-mkfatfs @ ~2.0.0) ├── tool-mklittlefs @ 1.203.210628 (required: platformio/tool-mklittlefs @ ~1.203.0) ├── tool-mkspiffs @ 2.230.0 (required: platformio/tool-mkspiffs @ ~2.230.0) ├── toolchain-riscv32-esp @ 8.4.0+2021r2-patch5 (required: espressif/toolchain-riscv32-esp @ 8.4.0+2021r2-patch5) └── toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5 (required: espressif/toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5) Libraries ├── Adafruit BusIO @ 1.17.2 (required: adafruit/Adafruit BusIO @ ^1.17.2) ├── Adafruit GFX Library @ 1.12.1 (required: adafruit/Adafruit GFX Library @ ^1.12.1) ├── ArduinoJson @ 7.4.2 (required: bblanchon/ArduinoJson @ ^7.4.2) ├── Bounce2 @ 2.72.0 (required: thomasfredericks/Bounce2 @ ^2.72.0) ├── ESPAsyncWebServer @ 3.7.10 (required: esp32async/ESPAsyncWebServer @ ^3.7.10) │ └── AsyncTCP @ 3.4.7 (required: ESP32Async/AsyncTCP @ ^3.4.5) ├── FastLED @ 3.10.1 (required: fastled/FastLED @ ^3.10.1) ├── IRremoteESP8266 @ 2.8.6 (required: crankyoldgit/IRremoteESP8266 @ ^2.8.6) ├── M5Unified @ 0.1.17 (required: m5stack/M5Unified @ ^0.1.17) │ └── M5GFX @ 0.2.9 (required: M5GFX @ >=0.1.17) ├── QRCode @ 0.0.1 (required: QRCode @ ^0.0.1) ├── RemoteDebug @ 3.0.5+sha.706f093 (required: git+https://github.com/PlummersSoftwareLLC/RemoteDebug) ├── TJpg_Decoder @ 1.1.0 (required: Bodmer/TJpg_Decoder @ ^1.1.0) ├── U8g2 @ 2.36.12 (required: olikraus/U8g2 @ ^2.36.12) ├── UrlEncode @ 1.0.1 (required: plageoj/UrlEncode @ ^1.0.1) └── arduinoFFT @ 2.0.4 (required: kosme/arduinoFFT @ ^2.0.4)

…

On Aug 11, 2025, at 8:01 PM, Robert Lipe ***@***.***> wrote: @robertlipe approved this pull request. I gave this a thorough review to really study it. (About 90 minutes worth.) ...Even the parts that made my head hurt. This is going to be a helluva merge conflict for me since I'd already replaced a lot of the configuration machinery in a very similar way, but I'll suck that up. This really lays the plumbing for new boards/effects to be totally in custom_blah.ini without touching a file that forces the world to recompile, and that makes me happy. I'm officially happy with this. Thank you. In platformio.ini <#738 (comment)>: > @@ -91,7 +91,7 @@ board = adafruit_feather_esp32s3_tft monitor_speed = 1500000 upload_speed = 1500000 lib_deps = ${base.lib_deps} - TFT_eSPI + bodmer/TFT_eSPI @ ^2.5.43 [dev_esp32] Actually, while you're in here since I think you're the only one with m5stack hardware, can you peek down around 161 in [dev_m5] and see if updating M5Unified to a newer version fixes the many warnings on every build? That's been on my list for a while. Your call whether that's this PR or this one, but it seems kind of related. In include/globals.h <#738 (comment)>: > #if USE_M5 +// Disable the deprecated Atom messages +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" Isn't the real problem here that our M5 package is picking up an old version? I poked at this a little and pio pkg list -e m5something reported something substantially under what's in m5stack/M5Unified. Fixing that doesn't have to be part of this PR, but leaving the smoke detectors going off instead of taking the batteries out of them will get one of us to look deeper into this. In include/globals.h <#738 (comment)>: > +#ifndef LED_PIN0 When I did this, I left a device for LED_PIN0 and NOT a default for everything else because they really don't make sense. The premise is that you always need at least one, but looking for conflicts in the others was a drag. In include/soundanalyzer.h <#738 (comment)>: > + // Length is NUM_BANDS; pairs with BandBinStarts(). + + inline const int *BandBinEnds() const + { + return _bandBinEnd; + } +#if ENABLE_AUDIO_DEBUG + // Print per-band [start-end] bin ranges over Serial for debugging. + // Useful to verify spacing and coverage with current config. + + void DumpBandLayout() const + { + Serial.println("Band layout (start-end):"); + for (int b = 0; b < NUM_BANDS; b++) + { + Serial.print(b); Consider a debugI() to save you five calls. You're inside an #ifdef, so the level doesn't matter a lot. In include/soundanalyzer.h <#738 (comment)>: > inline void RunSamplerPass() { if (millis() - _msLastRemote > AUDIO_PEAK_REMOTE_TIMEOUT) { - #if M5STICKCPLUS2 - _MicMode = PeakData::M5PLUS2; - #elif USE_M5 - _MicMode = PeakData::M5; - #else - _MicMode = PeakData::MESMERIZERMIC; - #endif - +#if M5STICKCPLUS2 Is this actually _micMode = AudioInputParams() ? In a near future world, microphones might be runtime configurable. We should try to avoid preprocessor tests when we can. In install_intelhex.py <#738 (comment)>: > @@ -0,0 +1,6 @@ +Import("env") + +try: + import intelhex That might have been a transient bug. platformio/platform-espressif32#1632 <platformio/platform-espressif32#1632> In platformio.ini <#738 (comment)>: > @@ -247,11 +278,11 @@ build_flags = ${base.build_flags} -DLV_CONF_PATH="../../../../include/amoled/lv_conf.h" -DLV_CONF_INCLUDE_SIMPLE ${psram_flags.build_flags} - ${unity_double_flags.build_flags} -lib_deps = lewisxhe/SensorLib @ ^0.1.4 - lewisxhe/XPowersLib @ ^0.2.1 - https://github.com/lvgl/lvgl.git#release/v8.3 - ${base.lib_deps} +lib_deps = ${dev_esp32_s3.lib_deps} + lewisxhe/SensorLib @ ^0.1.4 I think there's a stowaway tab in here. In platformio.ini <#738 (comment)>: > build_flags = -DM5DEMO=1 - ${dev_m5stick-c.build_flags} -board_build.partitions = config/partitions_custom_noota.csv + -DEFFECTS_DEMO=1 + -DPROJECT_NAME="\"M5Demo\"" + -DMATRIX_WIDTH=144*5+38 In at least one of these, please explain what the 5+38 is about. — Reply to this email directly, view it on GitHub <#738 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF4ILV2T27L7HZJRWND3NFKJFAVCNFSM6AAAAACDFYWRCCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTAOJQGMYTMMBXGA>. You are receiving this because you were assigned.

[robertlipe]

*davepl* left a comment (PlummersSoftwareLLC/NightDriverStrip#738) <#738 (comment)> Thanks! On the M5Unified stuff, I appear to be up to date? I’ve since disabled the warning just for that header, but would be nice to update the lib if I’m somehow out of date…

Actually, you're not—and I was on the same, so it's not just me. I was lightly poking at it because we have so many targets that are on m5 (of which I have zero), and I crashed into issues of it not building on Arduino3. That's why I was looking into it. It's when I fell into the I2S black hole last week. More in a moment. And sorry about missing the “shadowing” business! I wasn’t being obstinate,

just silly - I was looking only at the excerpt and not the surrounding context!

I was briefly miffed that I'd spelled it out like three times, but it took Rutger to get you to hear it, but that lasted only a few minutes. It's one of the advantages of a bad memory. :-) ***@***.*** NightDriverStrip % pio pkg list -e m5stackdemo [ .... ]

├── M5Unified @ 0.1.17 (required: m5stack/M5Unified @ ^0.1.17) │ └── M5GFX @ 0.2.9 (required: M5GFX @ >=0.1.17)

For our audience members, the first number is the version we HAVE, and the second is the version that we've asked for. "Anything that's API compatible with 0.1.17, and as high as possible." So apparently something happened after 0.1.17 where they knew they broke compatibility. We look at their releases <https://github.com/m5stack/M5Unified/releases> and see the following release was 0.2.0, so it was likely intentional. That version also lists "IDF v5 Compatible Fix", which is probably a prereq for "my" project. So we never got 0.2.0. (This is where I lost the beat before.) I just changed lib_deps = ${base.lib_deps} - m5stack/M5Unified @ ^0.1.17 + m5stack/M5Unified @ ^0.2.7 $ pio run -e m5demo. # builds without missing a beat. m5plusdemo and m5stackdemo seem similarly unfazed. A full build will take me about an hour. If your machines can knock it down (or you can wait a bit more...) see if maybe just bumping it is totally safe and the changes are in areas that don't affect us. Message ID: <PlummersSoftwareLLC/NightDriverStrip/pull/738/c3177564810@

…

github.com>

[robertlipe]

TBC: m5 *compiling* (warning-free) is, of course, only the first step to ensuring they actually run, but since m5stack is now Espressif's retail brand, I have a pretty good feeling that they have the software chops to not commit something that doesn't work.

…

On Tue, Aug 12, 2025 at 12:16 AM Robert Lipe ***@***.***> wrote: > *davepl* left a comment (PlummersSoftwareLLC/NightDriverStrip#738) > <#738 (comment)> > Thanks! On the M5Unified stuff, I appear to be up to date? I’ve since > disabled the warning just for that header, but would be nice to update the > lib if I’m somehow out of date… Actually, you're not—and I was on the same, so it's not just me. I was lightly poking at it because we have so many targets that are on m5 (of which I have zero), and I crashed into issues of it not building on Arduino3. That's why I was looking into it. It's when I fell into the I2S black hole last week. More in a moment. And sorry about missing the “shadowing” business! I wasn’t being > obstinate, just silly - I was looking only at the excerpt and not the > surrounding context! I was briefly miffed that I'd spelled it out like three times, but it took Rutger to get you to hear it, but that lasted only a few minutes. It's one of the advantages of a bad memory. :-) ***@***.*** NightDriverStrip % pio pkg list -e m5stackdemo [ .... ] > ├── M5Unified @ 0.1.17 (required: m5stack/M5Unified @ ^0.1.17) > │ └── M5GFX @ 0.2.9 (required: M5GFX @ >=0.1.17) > For our audience members, the first number is the version we HAVE, and the second is the version that we've asked for. "Anything that's API compatible with 0.1.17, and as high as possible." So apparently something happened after 0.1.17 where they knew they broke compatibility. We look at their releases <https://github.com/m5stack/M5Unified/releases> and see the following release was 0.2.0, so it was likely intentional. That version also lists "IDF v5 Compatible Fix", which is probably a prereq for "my" project. So we never got 0.2.0. (This is where I lost the beat before.) I just changed lib_deps = ${base.lib_deps} - m5stack/M5Unified @ ^0.1.17 + m5stack/M5Unified @ ^0.2.7 $ pio run -e m5demo. # builds without missing a beat. m5plusdemo and m5stackdemo seem similarly unfazed. A full build will take me about an hour. If your machines can knock it down (or you can wait a bit more...) see if maybe just bumping it is totally safe and the changes are in areas that don't affect us. Message ID: <PlummersSoftwareLLC/NightDriverStrip/pull/738/c3177564810@ > github.com> >

[davepl]

Thanks… although I don’t understand why the lower version doesn’t auto-upgrade, forcing the version number does get it to build. I have not TESTED but will in the AM! - Dave

…

On Aug 11, 2025, at 10:21 PM, Robert Lipe ***@***.***> wrote: robertlipe left a comment (PlummersSoftwareLLC/NightDriverStrip#738) <#738 (comment)>TBC: m5 *compiling* (warning-free) is, of course, only the first step to ensuring they actually run, but since m5stack is now Espressif's retail brand, I have a pretty good feeling that they have the software chops to not commit something that doesn't work. On Tue, Aug 12, 2025 at 12:16 AM Robert Lipe ***@***.***> wrote: > >> *davepl* left a comment (PlummersSoftwareLLC/NightDriverStrip#738) >> <#738 (comment)> >> Thanks! On the M5Unified stuff, I appear to be up to date? I’ve since >> disabled the warning just for that header, but would be nice to update the >> lib if I’m somehow out of date… > > > Actually, you're not—and I was on the same, so it's not just me. I was > lightly poking at it because we have so many targets that are on m5 (of > which I have zero), and I crashed into issues of it not building on > Arduino3. That's why I was looking into it. It's when I fell into the I2S > black hole last week. More in a moment. > > And sorry about missing the “shadowing” business! I wasn’t being >> obstinate, just silly - I was looking only at the excerpt and not the >> surrounding context! > > > I was briefly miffed that I'd spelled it out like three times, but it took > Rutger to get you to hear it, but that lasted only a few minutes. It's one > of the advantages of a bad memory. :-) > > > ***@***.*** NightDriverStrip % pio pkg list -e m5stackdemo > > [ .... ] > >> ├── M5Unified @ 0.1.17 (required: m5stack/M5Unified @ ^0.1.17) >> │ └── M5GFX @ 0.2.9 (required: M5GFX @ >=0.1.17) >> > > For our audience members, the first number is the version we HAVE, and the > second is the version that we've asked for. "Anything that's API compatible > with 0.1.17, and as high as possible." > > So apparently something happened after 0.1.17 where they knew they broke > compatibility. We look at their releases > <https://github.com/m5stack/M5Unified/releases> and see the following > release was 0.2.0, so it was likely intentional. That version also lists > "IDF v5 Compatible Fix", which is probably a prereq for "my" project. So we > never got 0.2.0. > > (This is where I lost the beat before.) > > I just changed > lib_deps = ${base.lib_deps} > - m5stack/M5Unified @ ^0.1.17 > + m5stack/M5Unified @ ^0.2.7 > > $ pio run -e m5demo. # builds without missing a beat. > > m5plusdemo and m5stackdemo seem similarly unfazed. > > A full build will take me about an hour. If your machines can knock it > down (or you can wait a bit more...) see if maybe just bumping it is > totally safe and the changes are in areas that don't affect us. > > > > Message ID: <PlummersSoftwareLLC/NightDriverStrip/pull/738/c3177564810@ >> github.com> >> > — Reply to this email directly, view it on GitHub <#738 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF2XFLSMYTTJDEZCVH33NF2XPAVCNFSM6AAAAACDFYWRCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCNZXG42DMOBQGU>. You are receiving this because you were assigned.

[robertlipe]

I haven't investigated at great(er) detail, but there must be some API (that we're not using) that the author knew changed in some incompatible way so that 0.1.x wasn't safe to auto migrate to 0.2.x. Despite the annoyingly small version numbers, this is how semver is supposed to work. We just happen to depend on a few other packages that don't use semver. We've developed an evolutionary survival skill to expect breakage and assume those three fields are basically an int will that can be simply compared. On Tue, Aug 12, 2025, 4:43 AM David W Plummer ***@***.***> wrote:

…

*davepl* left a comment (PlummersSoftwareLLC/NightDriverStrip#738) <#738 (comment)> Thanks… although I don’t understand why the lower version doesn’t auto-upgrade, forcing the version number does get it to build. I have not TESTED but will in the AM! - Dave > On Aug 11, 2025, at 10:21 PM, Robert Lipe ***@***.***> wrote: > > > robertlipe > left a comment > (PlummersSoftwareLLC/NightDriverStrip#738) > < #738 (comment)>TBC: m5 *compiling* (warning-free) is, of course, only the first step to > ensuring they actually run, but since m5stack is now Espressif's retail > brand, I have a pretty good feeling that they have the software chops to > not commit something that doesn't work. > > On Tue, Aug 12, 2025 at 12:16 AM Robert Lipe ***@***.***> wrote: > > > > >> *davepl* left a comment (PlummersSoftwareLLC/NightDriverStrip#738) > >> < #738 (comment)> > >> Thanks! On the M5Unified stuff, I appear to be up to date? I’ve since > >> disabled the warning just for that header, but would be nice to update the > >> lib if I’m somehow out of date… > > > > > > Actually, you're not—and I was on the same, so it's not just me. I was > > lightly poking at it because we have so many targets that are on m5 (of > > which I have zero), and I crashed into issues of it not building on > > Arduino3. That's why I was looking into it. It's when I fell into the I2S > > black hole last week. More in a moment. > > > > And sorry about missing the “shadowing” business! I wasn’t being > >> obstinate, just silly - I was looking only at the excerpt and not the > >> surrounding context! > > > > > > I was briefly miffed that I'd spelled it out like three times, but it took > > Rutger to get you to hear it, but that lasted only a few minutes. It's one > > of the advantages of a bad memory. :-) > > > > > > ***@***.*** NightDriverStrip % pio pkg list -e m5stackdemo > > > > [ .... ] > > > >> ├── M5Unified @ 0.1.17 (required: m5stack/M5Unified @ ^0.1.17) > >> │ └── M5GFX @ 0.2.9 (required: M5GFX @ >=0.1.17) > >> > > > > For our audience members, the first number is the version we HAVE, and the > > second is the version that we've asked for. "Anything that's API compatible > > with 0.1.17, and as high as possible." > > > > So apparently something happened after 0.1.17 where they knew they broke > > compatibility. We look at their releases > > <https://github.com/m5stack/M5Unified/releases> and see the following > > release was 0.2.0, so it was likely intentional. That version also lists > > "IDF v5 Compatible Fix", which is probably a prereq for "my" project. So we > > never got 0.2.0. > > > > (This is where I lost the beat before.) > > > > I just changed > > lib_deps = ${base.lib_deps} > > - m5stack/M5Unified @ ^0.1.17 > > + m5stack/M5Unified @ ^0.2.7 > > > > $ pio run -e m5demo. # builds without missing a beat. > > > > m5plusdemo and m5stackdemo seem similarly unfazed. > > > > A full build will take me about an hour. If your machines can knock it > > down (or you can wait a bit more...) see if maybe just bumping it is > > totally safe and the changes are in areas that don't affect us. > > > > > > > > Message ID: <PlummersSoftwareLLC/NightDriverStrip/pull/738/c3177564810@ > >> github.com> > >> > > > — > Reply to this email directly, view it on GitHub < #738 (comment)>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AA4HCF2XFLSMYTTJDEZCVH33NF2XPAVCNFSM6AAAAACDFYWRCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCNZXG42DMOBQGU>. > You are receiving this because you were assigned. > — Reply to this email directly, view it on GitHub <#738 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD332X5O7EJYYWKUM6DT3NGZN5AVCNFSM6AAAAACDFYWRCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCNZYGU4DSNRXHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rbergen]

It's actually basic semantic versioning compatibility rules. As long as the major version is 0 (like in the case of 0.1.17), minor version bumps are also treated as "breaking" because the API is considered unstable. Quoting from the npm semver docs about carets: "Allows changes that do not modify the left-most non-zero digit in the [major, minor, patch] tuple. In other words, this allows patch and minor updates for versions 1.0.0 and above, patch updates for versions 0.X >=0.1.0, and no updates for versions 0.0.X."

[rbergen]

One or two things you may want to look at, but nothing serious enough to block approval.

It's a very nice overhaul of our project configuration ball of wool, for sure!

[rbergen]

Not exactly. AudioInputParams() determines what to return based on _micMode, which is set here. So it's more _micMode -> AudioInputParams() - which may be what you meant.

Which does mean both _micMode and AudioInputParams()'s return value are determined by a define. Not that it matters much at the moment, because AudioInputParams() returns the same for all _micMode values.

[rbergen]

Just mentioning here that if any of the "effective effects sets" for any of the known project names (-DPROJECT_NAME in platformio.ini) has changed in this update, the EFFECT_SET_VERSION define for that block needs to be bumped, to make the people flashing this update get the updated set. If PROJECT_NAME and EFFECT_SET_VERSION are the same as what had been persisted to JSON with the then-current effect set, the device will load the set persisted to JSON instead of what is put together here.

[rbergen]

Again, if it turns out install_intelhex.py is no longer necessary, then neither is this.

[davepl]

Thanks for the reviews! It builds, so in it goes :-)