Move VU meter from a build flag to an option in the embedded web server. #523
Replies: 6 comments 4 replies
-
|
It's both. The VU meter is also a thing you can turn on or off using the IR remote - if you're using one. As such, it's also something we could make a setting in the web UI. The reason it's also a build flag is that the VU meter is added to the LED output in a function in the core of the drawing routines - the ones that are also used for non-matrix setups. Adding a VU meter to a strip is obviously nonsensical. If one were to argue that it makes sense to add the build flag to every env in platformio.ini that concerns a matrix with audio in, I'd certainly agree with that if a web UI setting was added for it also. |
Beta Was this translation helpful? Give feedback.
-
|
Is there anyway outside of platform.ini that we can set rules for builds? Not a matrix, then no VU meter..... A single effect, then no web server.. A basic ESP32 with no PSRAM, then only these environments are available. Or maybe platform.ini is the right spot and I'm missing something. Or can we build platform.ini on the fly......That would be tremendous... Point people at the web build site, they enter their chip, get the builds they can have, select the options they want ( features and effects) and click go... A couple of reasons for the last option. I run the Insulators env in 2 configs. I have a 4 ring setup that only runs the TapeReelEffect (because it is sooooo cool) and I have a 6 ring setup embedded under a shot glass tray that runs all of the effects. Both have audio. I dont think the insulator build gets the webserver via the web build currently. I had to build both manually. |
Beta Was this translation helpful? Give feedback.
-
To a certain extent, this is what the platformio.ini/globals.h combo is trying to do. The general idea is/was that platformio.ini configures a number of "core facts" about the environment one wants to build (type of device, name of project, whether a matrix is attached to the board or not, etc.) The contents of globals.h then take these and set up a whole range of "derived" defines that are used throughout the codebase. The extent to which this worked out is a matter of extensive debate in this project's issues, discussions, PRs - basically every type of content we have. Part of the tricky bit is that there are so many things that a user may choose to toggle on or off in the context of something that's otherwise preconfigured - and in many cases has to make trade-off decisions because of limited resources (mainly RAM, to a lesser extent flash) on many, if not most, chips/boards. To another extent, your idea works the wrong way around - or at least in an impractical direction. For instance, the number of effects is determined by code, and can't be easily converted to a build flag at build time.
Simply put that would require a web-based build-on-demand environment. That takes a lot of development, as well as compute resources; those aren't free. The former is something we could potentially cover if we have enough developer hands on deck, the latter would require some sort of spending budget - and not once, but continuously. As no one here is making money out of this, that would boil down to finding a (number of) sponsor(s). Until then, custom hardware setups will indeed require custom (local) NDS builds. |
Beta Was this translation helpful? Give feedback.
-
|
I just opened #524 to expose the IR remote control "show VU meter" toggle via the web UI as well, and persist its value. |
Beta Was this translation helpful? Give feedback.
-
|
Mike, I share your criticism about the build process and have given a lot
of thought to a better plan that doesn't make it an even bigger mess. It's
not easy. The minute I start typing things about configurations being a
quartile of
cpu + board + effects patterns + tunables (IR, VU, audio)
I realize I sound like a crazy person.
To a certain extent, this is what the platformio.ini/globals.h combo is
trying to do. The general idea is/was that platformio.ini configures a
number of "core facts" about the environment one wants to build (type of
device, name of
We can see that's the goal, and we keep inching there, but it's not our
total current reality, so it's easy to understand the quizzical looks.
There is a stated aversion to config files in our doc, but we have compiile
time constants in the global namespace for things like the audio pin that
require recompilation of the world when changed. For better and worse, we
already have to have a JSON parser, so moving some of our configurations
into JSON files doesn't seem like the craziest move ever. I know why some
of our knobs have to be compile-time constants, but there are a lot that we
could push into config files. (Of course, doing so would tank the very tip
I'm about to share...) I don't think that things like the power limit, the
pin number of IR are our big problems, though, so I'm happy to leave that
fruit hanging for now.
Or can we build platform.ini on the fly......That would be tremendous...
Point people at the web build site, they enter their chip, get the builds
they can have, select the options they want ( features and effects) and
click go...
I have a lot of (too many) source trees + a lot of hardware clumps in
various forms of completion. I try to manage this by touching
platformio.ini and config.h as little as possible. This way I have fewer
dirty files when I try to flip between branches or create a PR to share.
I use (or create) the most bare build target possible and then add
build_flags to the environment from the handful of little shell scripts
that I use to do the actual builds that also set the serial port because
platformio's "guessing" of serial ports tries to connect to that pair of
bluetooth earbuds I once used three years ago and all kinds of other goofy
things. It also mis-guesses the "correct" serial port for devices that use
the common WCH910x (maybe it's CH34x) chips that need /dev/cu.wchBLAH
instead of /dev/cu.BLAH.
As a pro tip, use 'pio project config' to debug passing flags without
actually doing the builds. So if you need to set specific flags, use
something like:
PLATFORMIO_BUILD_FLAGS="-DFOO=1 -DBAR=2" pio project config
to convince yourself that you're building the right set of flags (like
turning on VU meter for mesmerizer-lolin) and then you can do the
PLATFORMIO_BUILD_FLAGS="-DFOO=1 -DBAR=2" pio run target --target upload -e
mesmerizer-lolin to do the build and run.
On a new or freshly flashed board, an target of buildfs is needed once to
create and the root filesystem.
Something (I think it's scons) sorts the flags in a helpful way so that a
-U passed this way happens last and can disable flags that default on. So
if I wanted a fanset that didn't use screen, you can see that the flags are
helpfully ordered so the -U comes after the -D when you do
PLATFORMIO_BUILD_FLAGS="-UUSE_SCREEN " pio project config
... and look at fanset, for example.
I think there's a way in the GUI to provide build flags beyond stuffing
them in platformio.ini, but I used as little of platformio/visual code as
possible and that includes their editor.
Simply put that would require a web-based build-on-demand environment.
That takes a lot of development, as well as compute resources; those aren't
free. The former is something
There's a well known ESP32 project that does this. Their ecosystem is huge
and is likely co-supported by the companies making hardware dongles that
use ESP32s for IoT hardware. This project is far from having that kind of
support infrastructure. Our bus factor is still really low in terms of
developers actually doing work.
Our compiles are also pretty expensive computationally. Anyone paying for
build time on Google Cloud or whatever would need to fix a lot of our
redundant checkouts and compiles. This just isn't funny after doing a full
build:
$ du -h .pio
59G .pio
I do agree with Rutger's move that VU meter should Just Be There. It's a
pretty weird thing to be a compile-time knob to be turned. Good call.
I think this is how we make progress on this stuff, though. We find one
zany thing at a time and try to poke at it hard enough to make it go away.
… Message ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/523/comments/7598575
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
I've merged #524, so the web UI VU meter toggle is in. As explained before, the |
Beta Was this translation helpful? Give feedback.
-
|
You guys are amazing... So much support and guidance/teaching/leading/growth ops......... |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @mikejohnau, I really appreciate you saying that. When all's said and done I do put a fair amount of time and effort into this (and I know @robertlipe and others do too), so it is really nice to hear that's appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
It's true... While Davepl and his youtube stuff may have dragged me in, you, Robert and the rest of the guys supporting this project have kept me here and made spend lots of dollars on DasBlinkenLights....... But I love it.. My home office window now pisses off the neighbours and the front of my house scares off couriers...all on 5 volts.... Who'd have thought that? |
Beta Was this translation helpful? Give feedback.
-
|
Thanx!
Wait until you learn that 24v 2811s can usually still be driven from 3.3v
data.. now you can ignite leaves in your neighbors yard!
…On Sat, Nov 18, 2023, 5:42 AM mikejohnau ***@***.***> wrote:
It's true... While Davepl and his youtube stuff may have dragged me in,
you, Robert and the rest of the guys supporting this project have kept me
here and made spend lots of dollars on DasBlinkenLights....... But I love
it.. My home office window now pisses off the neighbours and the front of
my house scares off couriers...all on 5 volts.... Who'd have thought that?
—
Reply to this email directly, view it on GitHub
<#523 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD33NQSEJMJ5FYYC5GNTYFCNI7AVCNFSM6AAAAAA7PPXC72VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TMMBWGAZDQ>
.
You are receiving this because you were mentioned.Message ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/523/comments/7606028
@github.com>
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Just looked at this discussion
and wondered why VU meter is a build flag and not a feature that can be turned on and off in the EWS by env?
Beta Was this translation helpful? Give feedback.
All reactions