Vu meter on top is gone in the mesmerizer

[heidepiek]

I have just download the code for the nightdriverstrip, and build a new mesmerizer sketch for my lolin D32 pro. But the vu on top is gone!
Is this supposed to be the case? There where some things changed, is this one off them?

[rbergen]

No, that's because you're using the mesmerizer_lolin configuration in platformio.ini, which doesn't set the SHOW_VU_METER define. If you want the VU meter to show up, add -DSHOW_VU_METER=1 to the build_flags section of [env:mesmerizer_lolin], which starts at line 503 of platformio.ini. You can use [env:mesmerizer] for inspiration; it's right above it.

[heidepiek]

I thought that since I am really using a lolin D32 pro, I should also use the env:mesmerizer_lolin. Sorry, it works now.
Thank you very much rutger! 👍 Have now used the env:mesmerizer. But tomorrow when I get home from work I am also definitely going to try if I can get your tip with the define working with the env:mesmerizer_lolin as well.💪

Harrie

[robertlipe]

How funny that this tidbit came up just, what, two hours ago? I didn't even know that mesmerizer_lolin was an actively used target until that conversation. But honestly, this flag is tested in one place. Is it even intentionally excluded in that configuration? Should we think about just whacking that flag and letting the VU meter come and go via the remote (a checkbox setting in the web UI?) and letting VU meter be available by default in any of our matrix configurations?

…

On Tue, Nov 14, 2023 at 3:14 PM Rutger van Bergen ***@***.***> wrote: No, that's because you're using the mesmerizer_lolin configuration in platformio.ini, which doesn't set the SHOW_VU_METER define. If you want the VU meter to show up, add -DSHOW_VU_METER=1 to the build_flags section of [env:mesmerizer_lolin], which starts at line 503 of platformio.ini. You can use [env:mesmerizer] for inspiration; it's right above it. — Reply to this email directly, view it on GitHub <#514 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD36DIIWACVO2QA3RNFDYEPNK5AVCNFSM6AAAAAA7LNSRS2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKNRZHEYDC> . You are receiving this because you are subscribed to this thread.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/514/comments/7569901 @github.com>

[rbergen]

I don't know if it was intentionally excluded, because as I recall it that configuration was submitted by an outside contributor. But I'd think copying and pasting the mesmerizer config in its entirety (leaving the flag in) would probably have been easier than doing so and then taking it out.

Putting mesmerizer_lolin aside for a second, the interesting thing is that the VU meter basically is enabled for all matrix configurations that have incoming audio enabled. We can't just check for USE_HUB75, as that would exclude the WS2812B matrix configurations like Spectrum - which also have it set. On the other hand, if we were to have any matrix configurations without support for listening to audio showing a VU meter is pointless.

Maybe it is possible to put some Boolean logic together using other flags/defines to "compute" if the VU meter should be shown or not, but I'm not sure it would be very simple - or clear.

[robertlipe]

On Wed, Nov 15, 2023 at 2:41 AM Rutger van Bergen ***@***.***> wrote: I don't know if it was intentionally excluded, because as I recall it that configuration was submitted by an outside contributor. But I'd think copying and pasting the mesmerizer config in its entirety (leaving the flag in) would probably have been easier than doing so and then taking it out.

Having not dug into the history - and having not been here during that time - I'd always assumed that before Mesmerizer was hardware of its own that it began, like Harrie's board, a commodity Lolin board that had hardware added on to be a development vehicle before the actual schematic/Bill Of Materials was contracted out. I such thought it was kind of dead configuration. I have no problems modifying my beliefs on any of that; it was just an explanation that worked for me. I mean, it doesn't make sense that mesmerizer, mesmerizer_lolin use their own independent optimizatino flags and different partition tables, either, right? I figured that Mesmerizer was the 'living' (actively developed, tested) fork so when things like OTA came around, Mesmerizer got its own partition table - since it knew exactly how much flash was installed, unlike D32 Pro which comes in 4MB and 16MB flash versions. Similarly, having its own different debugger configuration didn't SEEM like an intentional choice as much as the two just sharing DNA in the past with only one getting active attention. It just seemed like a vestige.

Putting mesmerizer_lolin aside for a second, the interesting thing is that the VU meter basically *is* enabled for all matrix configurations that have incoming audio enabled. We can't just check for USE_HUB75, as that would exclude the WS2812B matrix configurations like Spectrum - which also have it set. On the other hand, if we were to have any matrix configurations *without support for listening to audio* showing a VU meter is pointless.

I'd always figured that would be handled by CanDisplayVUMeter() and that approximately the Effect subclasses that were also subclassing BeatEffectBase (probably && NROWS > 1) would be getting a different LedStripEffect with a specialization that returned true. Actually, I thought it followed the same basic model with an LEDStrip that used ledmatrixgfx.h probably returning true for CanDisplayVUMeter(). i see now that's not quite how it DOES work but again, that was a fable that sort of worked in my head so I never really dug into further before this morning. It just seemed more likely that the difference of whether to show VU meter on two nearly identical hardware configurations by default (well, actually, you cant turn it on at all, as that's why we're meeting here together today in thie bugreport at all) seemed to be more accidental than a product of considered design choices.

Maybe it is possible to put some Boolean logic together using other flags/defines to "compute" if the VU meter should be shown or not, but I'm not sure it would be very simple - or clear

No, if we try to find a way to sentence that flag to death, it should probably be using existing plumbing and not inventing yet something else. We need LESS clever configuration machinery - and fewer flags - and not more. :-) I should probably build a Spectrum so I have a deeper understanding of the effects that are native to it. Better yet, do we have a GOOD viewer so that a developer can spin through builds without wiring up hardware? We have LEDViewer code that's on port 0xc001 if you believe the comments or port 12000 if you believe the code, but the number of bytes received isn't a multiple of MATRIX_WIDTH * MATRIX_HEIGHT - and isn't even the same twice in a row for a paused display. I'd like a web viewer or a Qt viewer or something - heck, the opposite of samples/videoserver/VideoServer2.py that hocked up array of pixels into a PNG/GIF that could be fed into imageviewer or display or whatever would be super handy.

[rbergen]

Having not dug into the history - and having not been here during that time - I'd always assumed that before Mesmerizer was hardware of its own that it began, like Harrie's board, a commodity Lolin board that had hardware added on to be a development vehicle before the actual schematic/Bill Of Materials was contracted out.

No, that's not how it worked. The mesmerizer configuration was there before mesmerizer_lolin. What exactly happened in Dave's fork before the Mesmerizer board was the Mesmerizer board and things ended up in the main tree I don't know/remember. What I do know is that there were a number of alpha/beta iterations on the Mesmerizer board before it reached the current state; it was not put together in a couple of months. In the time it did take to develop the board, Dave was already developing/porting effects for it, and pushing them to the main tree. That is to say that for quite some time, the development of everything Mesmerizer (hardware and software) was a one-man show. That changed somewhat when Dave shipped me an early version of the board.

I figured that Mesmerizer was the 'living' (actively developed, tested) fork so when things like OTA came around, Mesmerizer got its own partition table - since it knew exactly how much flash was installed, unlike D32 Pro which comes in 4MB and 16MB flash versions.

Again, no. The actual reason mesmerizer got its "own" (bigger) partition table is that with all the effects and additional features, we ran out of program space on the smaller one.

Similarly, having its own different debugger configuration didn't SEEM like an intentional choice as much as the two just sharing DNA in the past with only one getting active attention.

As far as I recall, that difference was/is hardware-capability driven.

It just seemed more likely that the difference of whether to show VU meter on two nearly identical hardware configurations by default (well, actually, you cant turn it on at all, as that's why we're meeting here together today in thie bugreport at all) seemed to be more accidental than a product of considered design choices.

And you may be right. I just don't know, and frankly I don't care much either. If we can think of a change that objectively improves what we're looking at then I think we should just go for it no matter what considerations were 3, 6 or however many months ago.

No, if we try to find a way to sentence that flag to death, it should probably be using existing plumbing and not inventing yet something else.

That's what I meant: Boolean logic using other existing flags/defines.

I should probably build a Spectrum so I have a deeper understanding of the effects that are native to it. Better yet, do we have a GOOD viewer so that a developer can spin through builds without wiring up hardware?

I don't. Dave has developed a viewer that taps into the ColorDataServer capability, but I've never used it myself.

I'd like a web viewer or a Qt viewer or something - heck, the opposite of samples/videoserver/VideoServer2.py that hocked up array of pixels into a PNG/GIF that could be fed into imageviewer or display or whatever would be super handy.

A web viewer would require ColorDataServer to be (re)implemented using a web socket, which is what #356 is suggesting. And then the actual web viewer using that web socket would have to be developed as well, obviously.
Qt is a language this project doesn't speak (yet).