SHOW_VU_METER should never be on without ENABLE_AUDIO, but I hit this, so opted to guard it here. We could/should look into why that's possible as a separate issue.

[davepl]

SHOW_VU_METER should never be on without ENABLE_AUDIO, but I hit this, so opted to guard it here. We could/should look into why that's possible as a separate issue.

Originally posted by @davepl in #766 (comment)

[robertlipe]

Actually, why does SHOW_VU_METER exist in isolation?

Why not just delete the tests (and associated #endifs) and let IsVUVisible() carry the water?

[rbergen]

It's a good question. One could argue that an alternative approach would be to refactor DeviceConfig::ShowVUMeter() (which kind of drives IsVUVisible()) to just return false if SHOW_VU_METER is not set to anything other than 0, and just ignore calls to DeviceConfig::SetShowVUMeter() altogether in that situation.

In fact, I think a PR to that effect would have an easy time getting through the review process. :)

[rbergen]

...unless the question is why SHOW_VU_METER exists at all. The non-answer answer to that one is that it was decided at some point that a build-time flag was required that can dictate that a VU meter is not shown under any circumstance. Why exactly that decision was made I wouldn't dare speculate.

[robertlipe]

Indeed, my questioning was leaning toward the former. Fewer global compile time flags makes me happier. I opened the door for the latter, but it can still effectively exist and be in only one file. I'll probably fling a pr out for discussion.

Insert Jedi mind trick here.
Imagine if there was an itty bitty bit of human readable json for each target that controlled led configuration, remote configuration, vu meter default, and maybe/hopefully the effect set. The device reads it at boot. It's editable from a computer and probably can be tweaked at runtime via API, though not always casually. Now we don't have #defines that make reusing library objects between builds a problem. We don't have to recomplike to change from ws2812 to ws2815. We don't have to recompile the worl to move the remote from pin5 to pin6 because we touched p*in which triggered a global namespace change.

Sure, you'll still need builds for esp32-S3, P4, and ESP32-nothing. You could probably justify different builds for different screen libraries, but maybe pin numbers are in this file. Mesmerizer already has FastLED, but maybe we have to have a smaller build for the 4MB boards.

It's more tha three or four, but just maybe we don't NEED to compile 50 firmware.Bins just for combinations of things as small as SHOW_VU_METER.

... And yes, the cynical question is "who will pay for that?" The answer is I don't honestly think it's THAT much work. I'm willing to take it on and have already done some experimentation on this. A key happens to be the ability to build and run a variety of binaries on a reasonable sunset of hardware. I don't need to build Dave's belt. I need a (some) device to confirm via automation that it's received a configuration that would have matched the defines would have delivered.

A great job for a simulated display and a conversational API between programs on the host and the board. Getting the #defines out of global space also happens to allow build objects of the libraries. Seeing my 2026 plan here yet?

I've had plenty of time to think about this while downloading and building 243,646 copies of IRRemote. 😁

[rbergen]

Ah, we're back at the "how to get rid of the build-time configurations" topic. It only took us until the second day of the new year. By now, I think we've been discussing it for so long one can raise a new-born to a small human being with strong opinions, during the same period. :)

But seriously, you know I have a bit of a soft spot for JSON configuration, and now that this would be the third way we use it, one could even accuse us of consistency in its application. Which is something I also like in and of itself.

You've been a strong advocate for dev QOL improvements ever since you joined the project. Personally, I have outsourced the "50 builds" part of the development workflow to GitHub CI in my fork, but that's also possible because I only have a small number of physical devices. That means I normally only have to build one or two configurations locally to test the work I've done. That said, I can certainly see that this would be a big timesaver for people who have more hardware setups to drive.

So yes, this is something I certainly would find worthy of exploring. In terms of work, we do also have to consider the way this approach impacts CI, the web installer, the web installer creation scripts, etc. Just to be clear: that's not an argument against this as far as I'm concerned, but more a note to self as these are things I'd feel called to work on.

As for your 2026 plan, I think that was also the 2023 plan at a conceptual level. It does sound like we may be getting closer to the execution phase. :)