What type of microphone does the original Mesmerizer hardware use?

[heidepiek]

After a request from Rutger to help test something, I downloaded and uploaded the latest release to my ESP. I have a custom-made PCB that can be placed on the matrix. What I noticed is that the VU meter, which can be turned on and off, responded even when there was no sound.

The release that was previously running on my Mesmerizer was version 1.1.0. After testing the latest release, I realized that changes were made to the audio processing after version 1.1.0, which are not working in my favor.

I created an issue, but so far, I have only received feedback from Rutger. I’ve tried everything, including using different microphones and modifying certain header files related to the VU meter. However, the VU meter still fluctuates even when there is no sound.

I do not own the original Mesmerizer hardware, but can someone who does tell me which microphone is supplied with Dave’s hardware? I assume the original hardware does not have this issue; otherwise, more people would have responded to the issue. I would like to test the original microphone to see if it works correctly with my hardware.

The AUDIO_MIC_SCALAR setting in later releases does affect microphone sensitivity, but the VU meter fluctuations persist.

I've been playing around with these values: audioLevel, sensitivityFactor, BeatEnhance. I also added a threshold value (noiseThreshold) to filter out small fluctuations and noise (With the help of chat 🙈, this dummy here is not a programmer 😟). Sometimes, with some help, I manage to get things working, but this one isn't so easy!

To make a long story short, who can help me with information about the microphone used in the original hardware?

Greetz,
Harrie

[fredswims]

I can only supply you with a picture. It is mounted on the circuit board.
I have not fully played with my kit as it is Tax Time. The microphone is labeled MIC1 and located in the upper left quadrant of the photo.

[heidepiek]

Thanks @fredswims. So it looks like the microphone is placed on the pcb. I thought an external microphone was used. Hope that there are more people who can share a light on this. On the picture it says mic1, but is it a mic?

Regards harrie

[sixfootdad]

Yes, there is an onboard SMD mic. It's ~4mm in diameter and ~1.5mm tall. It could very well be something like this. There are no other visible identifying marks. https://www.mouser.com/ProductDetail/Same-Sky/CMC-4015-25T?qs=48I1WSKJTybY3H5TKh6cjA%3D%3D

[heidepiek]

Aha, so there is also an onboard amplifier for the mic probably. Thanks for the info.

Harrie :)

[heidepiek]

I've been tinkering for hours again, trying different microphones. I even looked up a schematic for a microphone amplifier online and made a small PCB. But it’s all in vain. I can't get the VU meter to stay calm when there's no sound. I’m throwing in the towel. It's starting to frustrate me, and that means it's no longer a hobby!

I'm a tinkerer, I love messing around with 3D printers and electronics. But my understanding only goes so far. What some people take for granted can be complete abracadabra for others. Often, those same people will say you should just try harder, look things up, and learn. But not everyone has the same ability.

Whenever I ask something on the NightDriver GitHub, it's usually Rutger or Robert who respond. Sometimes, a few other tinkerers provide useful tips (for which I’m grateful!). Now, I opened an issue 27 days ago. Rutger was kind enough to acknowledge it and confirm the issue. But since then, there's been no feedback from the bright minds who created and maintain the code. Surely, someone must have made changes to the audio-related code?! Then please give some feedback so people who run into problems can actually feel like something is being worked on!

I know that no one is obligated to help or respond immediately. You shouldn’t just assume that people are there to serve you or are required to help. But it’s so frustrating when something that used to work fine on your hardware suddenly starts acting up. I meant well by testing the changes in the code to make sure they worked properly. But when your once-functioning hardware suddenly starts misbehaving, it really sucks.

I'm someone who usually responds quickly when people ask something. On the NightDriver GitHub, there are usually just two people answering. The first says it's not their area of expertise (i get that). The second has remained silent so far :(

I think I’m done with this project. It’s really starting to frustrate me. I'm not getting any smarter! It’s a shame that the real experts hardly say anything. I still don’t know if this issue also occurs with the original hardware Dave made. You just hear nothing! And that’s depressing. Surely, enough people have this piece of hardware?

:(

[sixfootdad]

I bought the mesmerizer kit from ebay a while back, which came with a hub75 panel & Dave's board. I've always had the VU meter turned off because I personally didn't like the distraction with the other effects. However, I just checked & can confirm that the VU meter never stays calm, and the audio reactive effects are always moving.

[heidepiek]

I would like to kindly thank you. This answer is really helpful! I think that quite a few people own the Mesmerizer board but don’t provide any feedback. Many thanks, Mr. Karlson!

Regards Harrie :)

[robertlipe]

there are usually just two people answering. The first says it's not their area of expertise (i get that). The second has remained silent so far :(

Mr. Second here. Same answer as Mr. First. :-) I just had (have) nothing to add. Sometimes I intentionally keep my mouth shut because I know I'm already overshadowing here. (I'm an acquired taste and know that in strong doses can be an irritant.) The only permanent blinky box in my life with a microphone is the official Mesmerizer. I just don't do a lot of audio-reactive stuff, though I visited the non-mic part of it (on Mesmerizer) when adding the SM effects some time ago. The few times I've dived into the audio code to attempt to add audio for a breadboard-class project, I've fled in frustration without success. If you see that it's my PR that broke the code (I think I saw one of my cleanups fly by in a list), I'll do everything I can to fix it. I don't *think* I broke it, but I could be wrong. That's kind of a tough thing about projects like this. I don't think any one of us has every possible hardware combination, and it's not like we can type 'make check' and have an automated build try everything. This project is ahead of most in that it actually *compiles* all the time. (Thank you, First. 😉 ) Even that takes a commitment of almost an hour of machine build time per submit, and sometimes we *still* ask each other for help validating things before they go in -you've helped with a couple of those. So I don't think we're generally reckless. I know it's not a very satisfying problem-solving approach (though, I do it frequently), but you can time travel backward in time in Git and find the CL that broke it. (That's more practical for you than for the chap with a build from 2020 that may or may not have even ever been an official build...see? I read things I don't comment on) If you can help with that (apparently only you have *this* hardware...), then at least the two of us that aren't experts can have a limited amount of code that we have to think really hard about and/or have ammo to lean on the author of that change. I'd love to have a large, active group of developers working on (and supporting) this project, but we just don't. RJL

[heidepiek]

Thanks robert, sorry i`m really frustrated! 😞

[robertlipe]

I know. That's why I didn't snap back at you. We're fine. :-)

…

On Sun, Mar 30, 2025 at 9:34 AM Harke Bosgraaf ***@***.***> wrote: Thanks robert, sorry i`m really frustrated! 😞 — Reply to this email directly, view it on GitHub <#706 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD332BGJMN7DDNBC2O632W76IVAVCNFSM6AAAAAB2AD4IT2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENRWG44DGNA> . You are receiving this because you commented.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/706/comments/12667834 @github.com>

[rbergen]

Assuming I am Mr. First in @robertlipe's explanation (this does start to feel like a numerical version of Reservoir Dogs...), I can confirm that I don't know the audio code. That stuff is really quite specific, and I don't have the mental space (right now) to learn what needs to be learned to say or do anything useful about it. Which is also why in the history of my involvement with this project I've never touched any audio code that actually changes how audio is interpreted or visualized.

What I can say is:

• I highly appreciate anyone who contributes anything to this project. That includes "Mr. Second", @heidepiek and anyone else who has ever taken the trouble to answer a question, make a suggestion, or write any line of code towards the codebase.
• I care about this project, as I do about any project I play a part in, of which there are actually quite a few.
• I can't spend as much time or attention to this project (or any of the ones I'm involved with) as I'd like, because of, well, the realities of life. I need to fit everything I do here into my spare time, and I only have so much of it.
• The first two points make that I am saddened when anyone who ever contributed expresses frustration for lack of response or engagement with their questions or challenges. At the same time, the third point makes that I don't apologize for that. I'm genuinely doing what I can.

Putting that aside, Robert's suggestion is a sensible one. It is possible for anyone to track back code changes that were made (in the audio processing parts of the code specifically), check out the state of the codebase at specific points in time, and compare how the VU meter acts across various versions. If we reach the point that the culprit is pinned down to a specific commit - or at least a short timeframe within offending changes have been found to be -, I'm happy to look at the audio code in question and try to figure out what it is I'm actually looking at, even if I have no existing expertise to fall back on.

[heidepiek]

thanks mate, so far i found out that release 1.1.1 is oke and the vumeter relaxes. But if i upload release 1.2.0 it goes haywire. I compared these two releases v1.1.1...v1.2.0
And there are some changes made. So i wil try some stuf. But it won`t be easy for me!

Harrie :-)

[rbergen]

Just quickly browsing over the changes between those two releases, there are two sets of changes I would look at first:

• In soundanalyzer.h, between lines 645 and 652 (v1.1.1)/658 and 667 (v1.2.0)
• in audio.cpp, line 68 (v1.1.1)/72 (v1.2.0)

You could try reverting those changes in v1.2.0 and see what that does for you. There are other changes in places where VU things get drawn, but the changes I just mentioned directly relate to how the VU decay is being calculated and applied. Looking at the code in question I have to add to that that, as English speakers would say, it looks like Dutch to me. As that specific expression doesn't really work in our specific context, I'll add the Dutch translation: dat is Chinees voor mij.

[heidepiek]

Thanks rutger, when i come home from the chiropractor i wil try it😉 (forgot i had an appointment🙈) too busy with the mesmerizer🤭

[heidepiek]

Rutger, your quick review of the code has paid off—hats off to you! Just casually scanning through the code, identifying all the changes, and filtering out the right ones—impressive!
Here’s what I’ve altered:
In audio.cpp, I changed this:

71 if (g_Analyzer._VURatio > lastVU)
72 lastVU += (millis() - lastFrame) / 1000.0 * VU_DECAY_PER_SECOND * VU_REACTIVITY_RATIO;

To this:

71 if (g_Analyzer._VURatio > lastVU)
72 lastVU = g_Analyzer._VURatio;

In soundanalyzer.h, I changed this:

// Update the local band peaks from the global sound data. If we establish a new peak in any band,
// we reset the peak timestamp on that band

inline void UpdatePeakData()
{
for (int i = 0; i < NUM_BANDS; i++)
{
if (_Peaks[i] > _peak1Decay[i])
{
const float maxIncrease = std::max(0.0, g_Values.AppTime.LastFrameTime() * _peak1DecayRate * VU_REACTIVITY_RATIO);
_peak1Decay[i] = std::min(_Peaks[i], _peak1Decay[i] + maxIncrease);
_lastPeak1Time[i] = millis();
}
if (_Peaks[i] > _peak2Decay[i])
{
const float maxIncrease = std::max(0.0, g_Values.AppTime.LastFrameTime() * _peak2DecayRate * VU_REACTIVITY_RATIO);
_peak2Decay[i] = std::min(_Peaks[i], _peak2Decay[i] + maxIncrease);
}
}
}

inline PeakData GetPeakData() const
{
return _Peaks;
}

inline void SetPeakData(const PeakData &peaks)
{
debugV("Manually setting peaks!");
Serial.print(" #");
_msLastRemote = millis();
_Peaks = peaks;
}

To this:

// Update the local band peaks from the global sound data. If we establish a new peak in any band,
// we reset the peak timestamp on that band

inline void UpdatePeakData()
{
for (int i = 0; i < NUM_BANDS; i++)
{
if (_Peaks[i] > _peak1Decay[i])
{
_peak1Decay[i] = _Peaks[i];
_lastPeak1Time[i] = millis();
}
if (_Peaks[i] > _peak2Decay[i])
{
_peak2Decay[i] = _Peaks[i];
}
}
}

inline PeakData GetPeakData() const
{
return _Peaks;
}

inline void SetPeakData(const PeakData &peaks)
{
debugV("Manually setting peaks!");
Serial.print(" #");
_msLastRemote = millis();
_Peaks = peaks;
}

Now, the VU meter is silent when there is no sound! 🎵🔇

I’m not sure if this is the best way to do it, but for now, it works for me.

Huge thanks to everyone who responded! 🙌 I hope those with deeper knowledge of the code can fine-tune it if needed.

https://drive.google.com/file/d/1TIJRpEMcLUONkhlzl8CW2ATXhGcHLIaE/view?usp=sharing

Greetz from a happy camper!

Harrie :-)

[rbergen]

I think we should probably agree to call this teamwork. You narrowed down the set of changes to consider to a manageable size, after all. 🙂

From my perspective the tricky bit actually starts now. The changes you reverted were made with a reason, so now comes the challenge of figuring out what code to keep in the long run. But that is solidly on "my" territory, so to speak. I'll have a chat with Dave about it.

In any case, I'm happy to see you're feeling better than yesterday! 😉

[robertlipe]

Indeed. The First and Second thing came from

The first says it's not their area of expertise (i get that). The second

has remained silent so far :( It was pretty clear who was being (un)named there, so I ran with that. I probably should not try to be so clever when I know that I'm a minority in the conversation as a native English speaker. Sorry. Whether it's by translation (and I can tell you use a few different ones) or your own English, your messages come through loud and clear to me. I'll take a well-organized bugreport or conversation in even "broken" English over a native speaker's sloppy thoughts every time. Your English is better than my (non-existent) Dutch or Frisian. Besides, I'm partial to Towers of (GPS) Babel <https://www.gpsbabel.org/people/robertlipe.html>. :-)

more people with the original hardware haven’t tested

I don't know how many of those boards are actually out in the wild, and I don't need to, but I don't perceive that there is a large number of people with those boards that are following the development tree. We have two in this thread (thanks, gentlemen), but it doesn't seem like a lot. With no data to back it, I suspect that a majority of the units sold are unboxed, run the firmware that they shipped with, and don't even upgrade to subsequent releases. Buyers and Builders can overlap some, but it's not like we've seen any real support traffic for them or needed to help people install PlatformIO or whatever. I suspect a majority are unboxed, go onto a shelf, are tuned a bit with the remote, and blink forever. As for development, I actually run for weeks at a time with as little hardware as possible (often NO leds at all) for the kind of work I do on this project. Sure, I touch-test configurations when shipping a non-trival contribution. My mesmerizer can stay powered down (and sometimes, even lost...) for months at a time. This was why I was so happy to find that hardware in the video I sent you two - power, debug, jtag, serial console, AND 256 lights, all from one cable on a board that'll fit in your mouth. So, no, I don't have a permanent fixture that runs the nightly builds to notice such things. That may change soon, but it's not my current reality. Unsurprisingly, Rutger and I are making the same offer. If you can help track it down to one version that works vs. an adjacent version that doesn't, even though neither of us has a great handle on that code, we'll at least have a specific set of changes to scrutinize and may be able to come up with something. Maybe we were quieting a warning, and a variable incorrectly changed from signed to unsigned and can no longer swing negative when it should, for example. Together, I'm pretty sure we can get through it. We had a similar case a few weeks ago where there was a change in the screen handling on one specific brand of board. Neither of us "numbered" contributors had (have) the affected hardware. The person with the hardware identified a specific set of changes; together, we desk-checked a proposed set of changes and worked with the user with the hardware to refine them, and they all lived happily ever after. We just need to get you to the "happily ever after" part of the story. So we've confirmed that Mesmerizer on TOT is working as expected and it's your custom configuration (not that there's anything wrong with that...) that's being naughty, right? RJL

…

On Sun, Mar 30, 2025 at 2:06 PM Harke Bosgraaf ***@***.***> wrote: Rutger, you really don’t need to apologize. I think I’m the only autistic person here who even notices that the VU meter is still moving even when there’s no audio. What surprises me the most is that no one with the original Mesmerizer PCB has checked whether it behaves the same way. That’s something I would have noticed right away, and if someone had asked about it on the site, I would have pointed it out immediately! I know the VU meter can be turned off, but being the way I am – if a function exists, it should work properly! If someone had told me 28 days ago that the original Mesmerizer hardware also behaves this way, I wouldn’t have been so frustrated. I really appreciate everything No. 1 and No. 2 do (and yes, I mean you, Rutger, and Robert—this "dummy" actually looks up to you both!). And I fully understand that this is not easy stuff! I mean well, Rutger, but I also hope you understand where I’m coming from. I just find it disappointing that more people with the original hardware haven’t tested and confirmed this. The creator should have noticed this as well, don’t you think? I know you’re the maintainer, but the creator also has a few of these beautiful gizmos. Wouldn't he have noticed? And sorry for how I’m bringing this all across. Your English is 100 times better than mine! I have to translate everything from Frisian to English, and that often leads to some Babylonian confusion! You guys can convey things much more politely and sophisticatedly. When it comes to that, I’m just a clumsy country guy! But take it from me, Rutger, I don’t take anything for granted! Harrie — Reply to this email directly, view it on GitHub <#706 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD36YN2B3B5IKSFTJMG32XA6E7AVCNFSM6AAAAAB2AD4IT2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENRWHEZDIOA> . You are receiving this because you were mentioned.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/706/comments/12669248 @github.com>

[heidepiek]

If you read the reply from sixfootdad. In this discusion and wich i selected as answer robert, you can state that de official mesmerizer board also has this glitch of the vu meter moving without sound. So it is not my custom configuration being naughty🤔 I appreciatie that rutger and you want to help me with this glitch i have stumbled on. Before i uploaded the New version, i had a previous branch uploaded on my mesmerizer ( i'm tired and was almost sleeping so i cant remember the specific version) that had a vu meter that was calm at no sound. Tomorow when i come home from work i wil check. Thanks robert 😉

Ps: what do you mean by, on TOT

Harrie

[sixfootdad]

Unfortunately, I don't know if there's a way to easily search github to find commits that changed specific variables (assuming that's the case), but @heidepiek you could try increasing the VUDAMPEN, VUDAMPENMIN, and VUDAMPENMAX values in soundanalyzer.h to make the VU meter less reactive and then building/uploading to the board. VUDAMPEN is the most important as line 321 in soundanalyzer.h effectively sets the value of _VU to newval when VUDAMPEN is set to 0, which means it would react to everything the microphone can hear, whether or not the human in the room can.

[davepl]

FWIW, there’s also a sensitivity jumper with 3 possible positions right next to mic… but it should be “right” with no jumper installed. - Dave

…

On Mar 30, 2025, at 3:14 PM, Damian Karlson ***@***.***> wrote: Unfortunately, I don't know if there's a way to easily search github to find commits that changed specific variables (assuming that's the case), but @heidepiek <https://github.com/heidepiek> you could try increasing the VUDAMPEN, VUDAMPENMIN, and VUDAMPENMAX values in soundanalyzer.h to make the VU meter less reactive and then building/uploading to the board. VUDAMPEN is the most important as line 321 in soundanalyzer.h effectively sets the value of _VU to newval when VUDAMPEN is set to 0, which means it would react to everything the microphone can hear, whether or not the human in the room can. — Reply to this email directly, view it on GitHub <#706 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF4SUW23C6Q7QUBP43T2XBUF7AVCNFSM6AAAAAB2AD4IT2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENRXGAYDGNY>. You are receiving this because you are subscribed to this thread.

[heidepiek]

Sorry dave, i don't own your board. But i think lowering the whole microphone sensitivity is not the solution. The vu meter in the top should have his own parameter to adjust the sensitivity. The rest of the mesmerizer effects that use audio are working as expected. I think if you lower the overall sensitivity, it will effect the other effects being to less responsive ( and also tried this already with the adjustible mics!) . I think (hope) mr karlson is right.

Harrie

[robertlipe]

On Sun, Mar 30, 2025 at 5:14 PM Damian Karlson ***@***.***> wrote: Unfortunately, I don't know if there's a way to easily search github to find commits that changed specific variables (assuming that's the case), but @heidepiek <https://github.com/heidepiek> you could try increasing the VUDAMPEN, VUDAMPENMIN, and VUDAMPENMAX values in soundanalyzer.h to make the VU meter less reactive

Those lines haven't changed in a while. ➜ nightdriverstrip git:(dbl) ✗ git blame include/soundanalyzer.h | grep VUD 28d2c6c (Dave Plummer 2023-02-26 11:45:38 -0800 87) #ifndef VUDAMPEN 26ed198 (Dave Plummer 2023-05-11 21:23:47 -0700 88) #define VUDAMPEN 0 // How slowly VU reacts 28d2c6c (Dave Plummer 2023-02-26 11:45:38 -0800 91) #define VUDAMPENMIN 1 // How slowly VU min creeps up to test noise floor 28d2c6c (Dave Plummer 2023-02-26 11:45:38 -0800 92) #define VUDAMPENMAX 1 // How slowly VU max drops down to test noise ceiling 28d2c6c (Dave Plummer 2023-02-26 11:45:38 -0800 321) _VU = (_oldVU * VUDAMPEN + newval) / (VUDAMPEN + 1); 28d2c6c (Dave Plummer 2023-02-26 11:45:38 -0800 330) _PeakVU = (_oldPeakVU * VUDAMPENMAX + _VU) / (VUDAMPENMAX + 1); 28d2c6c (Dave Plummer 2023-02-26 11:45:38 -0800 338) _MinVU = (_oldMinVU * VUDAMPENMIN + _VU) / (VUDAMPENMIN + 1); Nickel tour for exploring this kind of thing: You can do a 'git blame' on a whole file or group of files.: git blame filea fileb filec You can do a git log on a a file or files to see the history. In that history is a big alphanumeric number. If you want to see the change, you can then do something a 'git show 270e5cd'. There's some editor in my life that shows the commit that changed every line in the left gutter, but I just checked Cursor, visual\ studio\ code, Windstar, Neovim, and CLion and didn't see it. Maybe I turned it off. (I've been a bit promiscuous with editors lately...) Message ID:

…

<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/706/comments/12670037 @github.com>

[sixfootdad]

Ah, I forgot about git blame! 🤦
I guess the big question is whether or not your Mesmerizer VU meter is always active even in a quiet (for humans) room, @davepl.

[heidepiek]

Just home from work, tonight i will try to make some changes to get the vu meter quiet. Here is a little vid of the old and new release side by side:

old.versus.new.mp4

Greetz Harrie

[robertlipe]

Nice work, everyone!

…

On Mon, Mar 31, 2025, 3:04 PM Rutger van Bergen ***@***.***> wrote: I think we should probably agree to call this teamwork. You narrowed down the set of changes to consider to a manageable size, after all. 🙂 From my perspective the tricky bit actually starts now. The changes you reverted *were* made with a reason, so now comes the challenge of figuring out what code to keep in the long run. But that is solidly on "my" territory, so to speak. I'll have a chat with Dave about it. In any case, I'm happy to see you're feeling better than yesterday! 😉 — Reply to this email directly, view it on GitHub <#706 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD34VXPCJE75W5JYHMFD2XGNT3AVCNFSM6AAAAAB2AD4IT2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENRYGA4DOOA> . You are receiving this because you were mentioned.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/706/comments/12680878 @github.com>

[robertlipe]

We'll even give some credit to Pikachu, who probably oversaw this operation! Now we know how this panel is powered.

…

On Mon, Mar 31, 2025, 3:15 PM Robert Lipe ***@***.***> wrote: Nice work, everyone! On Mon, Mar 31, 2025, 3:04 PM Rutger van Bergen ***@***.***> wrote: > I think we should probably agree to call this teamwork. You narrowed down > the set of changes to consider to a manageable size, after all. 🙂 > > From my perspective the tricky bit actually starts now. The changes you > reverted *were* made with a reason, so now comes the challenge of > figuring out what code to keep in the long run. But that is solidly on "my" > territory, so to speak. I'll have a chat with Dave about it. > > In any case, I'm happy to see you're feeling better than yesterday! 😉 > > — > Reply to this email directly, view it on GitHub > <#706 (reply in thread)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACCSD34VXPCJE75W5JYHMFD2XGNT3AVCNFSM6AAAAAB2AD4IT2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENRYGA4DOOA> > . > You are receiving this because you were mentioned.Message ID: > <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/706/comments/12680878 > @github.com> >

[davepl]

Thanks, all! Just to clarify, I take no pride in the audio code of this thing - it was the first digital sampling I ever did, so everything from VU to spectrum analyzer to beat detection is made up without really knowing what the state of the art actually is for those things! It all evolved from blinking a single LED, and the path wasn’t always direct. In other words, if anyone can make it better, please feel free! I define better as: - Code smaller and cleaner than what’s there now - Resultant visual effects as good or better than what it can do now At the end of the day, how it looks is most important, how the code looks is next, but both matter! - Dave

…

On Mar 31, 2025, at 1:19 PM, Robert Lipe ***@***.***> wrote: We'll even give some credit to Pikachu, who probably oversaw this operation! Now we know how this panel is powered. On Mon, Mar 31, 2025, 3:15 PM Robert Lipe ***@***.***> wrote: > Nice work, everyone! > > On Mon, Mar 31, 2025, 3:04 PM Rutger van Bergen ***@***.***> > wrote: > >> I think we should probably agree to call this teamwork. You narrowed down >> the set of changes to consider to a manageable size, after all. 🙂 >> >> From my perspective the tricky bit actually starts now. The changes you >> reverted *were* made with a reason, so now comes the challenge of >> figuring out what code to keep in the long run. But that is solidly on "my" >> territory, so to speak. I'll have a chat with Dave about it. >> >> In any case, I'm happy to see you're feeling better than yesterday! 😉 >> >> — >> Reply to this email directly, view it on GitHub >> <#706 (reply in thread)>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/ACCSD34VXPCJE75W5JYHMFD2XGNT3AVCNFSM6AAAAAB2AD4IT2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENRYGA4DOOA> >> . >> You are receiving this because you were mentioned.Message ID: >> <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/706/comments/12680878 >> @github.com> >> > — Reply to this email directly, view it on GitHub <#706 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF7GJDMV3Q5K7J3RA5T2XGPNVAVCNFSM6AAAAAB2AD4IT2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENRYGA4TQNQ>. You are receiving this because you were mentioned.

[rbergen]

@davepl In this case the audio processing changes that "broke" the VU meter in quiet conditions were made in October last year, and I thought you maybe remembered why you made them. Then again, I do realize 5 months really is a century on this project's timeline. :)

If you don't, I think we'll stick with this revert until there is a reason to reconsider that decision.

[rbergen]

@heidepiek I've looked into it a bit, and I think I've narrowed down the culprit to one line in audio.cpp - one of the lines you reverted yesterday. I also have a thought on why that line is misbehaving, but I need to look into that quite a bit further. I'll only do that once I know I'm not barking up the wrong tree.

I've put a branch together in my fork with just that line reverted (the other changes are the removal of trailing whitespaces and two unnecessary lines in types.h): https://github.com/rbergen/NightDriverStrip/tree/fix-vu-in-silence. Could you use that code to build and flash an image, and take a look at how the VU meter behaves with it? It would really help me figure this one out.

[heidepiek]

I tried your branch, Rutger, but I find the VU meter's response a bit too fast. It’s quite twitchy, or how should I say it… Too quick. The other VU meter from the Mesmerizer branch we modified yesterday feels a bit more relaxed. Maybe you could adjust this. I also had an idea myself, but it didn’t lead to anything!

vu.meter.rutger.mp4

Left one is missing a pixel, not the firmware's fault 🤭

[rbergen]

Thanks so much!

Yeah, I think I know why that twitchiness is. I'll try to fix that tomorrow. One more round coming up! 🙂

[rbergen]

Changed. I've aligned the VU meter decay speed with that of the various VU effects that are also in the codebase.

[heidepiek]

Why do all the bright minds have insomnia? 🫣
I'm at work, will try tonight rutger.

[rbergen]

Haha, no insomnia here, maybe slightly different daily schedules. ;)

I look forward to hearing the outcome of your testing!

[heidepiek]

I just uploaded this version: https://drive.google.com/file/d/1CwaRdWt1S-GJaa7GpdrXTlYTeTjSDWGs/view?usp=sharing
Hope that is the good one, i peaked in the header files and think this is the right one. Here is a little preview. It is stil faster than the old one.
The left side your branche rutger.

vu.test.mp4

[rbergen]

@heidepiek The slower decay would be caused by the VU_DECAY_PER_SECOND constant being set to a value that's too low. If you can find a higher value that you feel matches the "good old days", I'm happy to hear what it is.

And about your weekend: in my view I'm taking away your time from your wife, not the other way around. ;) Have a good one, and we'll hear back from you when we do!

[heidepiek]

constexpr auto VU_DECAY_PER_SECOND = 3.00;

spectrum.analyzers.mp4

[rbergen]

Thank you! Alright, 3.00 it is. I'll update #709 accordingly.

[rbergen]

Just to confirm: would you agree this issue is fixed with the current code and that VU_DECAY_PER_SECOND value?

[heidepiek]

The code that i have currently on my mesmerizer (fix-vu-in-silence) is working good now. The vu_decay_per_second value is also good in my eyes. So yes i agree, it is fixed. Thanks guys! 👌👍💪