Audio Peak Level not dropping

[Yincognito]

I think you didn't explain it well from the start (and having so many posts about other unrelated or vaguely related things doesn't help). Example:

...On sensing a drop in volume, it will pause the meter (or Measure) for a second to allow it to stay in position when dropped, but react straight away when increased in volume.

Increased in volume compared to what?! Here, it can be interpreted both ways, since you didn't specify: compared to the previous value (which is what I understood, given our discussion about previous values earlier in the thread), or compared to the initial value that represents the position (which is probably what you meant based in the last replies, though without conveying it then). They are entirely different things, albeit similar in one aspect: the 1st one impossible without giving up staying on position for a whole second, the 2nd one also impossible without giving up staying on position for a whole second (see below), but not mentioned / communicated properly.

Actually, I'm thinking it may be better to have it pause as priority for the whole second. Please!

So, the code was written based on what you specified: stay on the 0.7 position for the whole second, which is incompatible with any position change during that second, whether it's 0.4 or 0.9. It's irrelevant how a VU meter behaves, those helping out, including myself, act on what the user communicates in his posts. If the details are not complete in those posts, the result is corresponding to the available details.

[sl23]

Oh, I just sent a message! I appreciate what you're saying, and you are right, I didn't explain perfectly. I can only apologise, I genuinely feel bad for that as I know you have been a great help here many times. I did try to explain my problems and how they affect me, and this is part of it. A few years ago, I wouldn't have had this trouble explaining, it is what it is. I presumed you knew how Peak meters worked with all that knowledge you have! Maybe that subconsciously affected my description?! lol

Increased in volume from the previous measure reading, but only if it is an increase in volume from that previous reading as shown in my description. I thought that was obvious, no? But it is ignored during that second on a decrease in volume and stays paused until the time, user definable, is up.

It's ok, don't worry, I just wanted to explain in a proper way how they worked. I shouldn't have assumed you knew that!

[Yincognito]

Oh, I just sent a message! I appreciate what you're saying, and you are right, I didn't explain perfectly. I can only apologise, I genuinely feel bad for that as I know you have been a great help here many times. I did try to explain my problems and how they affect me, and this is part of it. A few years ago, I wouldn't have had this trouble explaining, it is what it is. I presumed you knew how Peak meters worked with all that knowledge you have! Maybe that subconsciously affected my description?! lol

Increased in volume from the previous measure reading, but only if it is an increase in volume from that previous reading as shown in my description. I thought that was obvious, no? But it is ignored during that second on a decrease in volume and stays paused until the time, user definable, is up.

It's ok, don't worry, I just wanted to explain in a proper way how they worked. I shouldn't have assumed you knew that!

No need to apologize, but as you can see, the devil is indeed in the details. A clear description always helps, and it doesn’t have to be long or spanned on multiple posts.

By the way, I don't exactly get why the bare Peak measures (without IfConditions and OnChangeActions) in your last skin sample aren't enough, since they don't seem to go below the current value in their bare form. You said you wanted a faster attack, but what does that mean exactly? If possible, in a compact description, otherwise we're back at square one and have 5 pages and no desired result...

[sl23]

God I know, I just get stuck at different points and as the conversation is slow, I get impatient waiting for replies, not just you, so I end up putting up a load of posts trying to explain where I've got to, but I think it just makes it worse!

The bare measures work perfectly. The problem is that they don't have a hold setting. That's it! That's all it is. Peak meters don't 'bounce' around like that, or shouldn't. The whole idea of a peak meter is to have a stable reading to see where the volume is loudest and at what level, hence for easier readability, they have a hold setting, so you can evaluate the PEAK volume NOT the RMS loudest volume, which it seems to be doing by bouncing around.

All of this has been my effort to explain how it works, but I don't honestly know how to better explain than my last post:

To use your explanation above as a basis for an example:

• The process first chooses to display 0.7 when reaching 0.5, as you want to stay on the greater volume for that second and the volume dropped.

• Then, it still chooses 0.7 when reaching 0.3, for the same reasons.

• But, when reaching 0.4, what do you do choose: 0.7 to stay on it for a whole second, (YES, unless it goes OVER 0.7 during that second) or 0.4 because the volume increased from the previous 0.3? (NO because it's a drop in volume) BUT NOW... if you change that 0.3 to 0.9, then as this is louder, or higher in value, than 0.7, it overrides the delay. This is how I imagine it to work, I don't have access to tools or code to prove it, but I can see with my own eyes that ANY and EVERY peak meter in existence works the way I described. Watch the video!

• Can you do both at the same time without one of them being canceled by the other? Well, that's the point I was having trouble with in the beginning, but I don't think you understood what I was getting at, maybe that's my fault?!

This is how it works now, using your example above:

• 0.7 - paused as start of timing

• 0.5 - paused as at 200 ms

• 0.3 - paused as at 400 ms

• 0.4 - paused as at 600 ms

• 0.2 - paused as at 800 ms

• 0.9 - moved up as at 1000 ms

Exactly right, but only because the example doesn't take into account what I hadn't foreseen, as I said above.
ie, How it should work:

• 0.7 - paused as start of timing

• 0.5 - paused as at 200 ms

• 0.9 - moved up as higher value registered and timing starts again from 0

• 0.4 - paused as at 200 ms

• 0.2 - paused as at 400 ms

• 0.9 - paused as at 600 ms

• 0.7 - paused as at 800 ms

• 0.5 - moved down as at 1000 ms, timing restarted

• 0.8 - moved up as higher value registered, timing restarted

• 0.4 - paused as at 200 ms

• 0.2 - paused as at 400 ms

• 0.9 - moved up as higher value registered, timing restarted, etc...

The Peak meter only drops when the timer reaches 1000 ms, but rises regardless of the timing if the value exceeds it's current state.

That last statement is the key:
The Peak meter only drops when the timer reaches 1000 ms, but rises regardless of the timing if the value exceeds it's current state.
NEVER drops until 1000 ms. ALWAYS rises, but HOLDS the highest value until either 1000 ms or a higher value is given.
As is the last quote in the spoiler.

Does that clear it up?

[sl23]

My skin almost works and feels so close, but I just can't get it to unpause quickly enough on rapid high volume changes. So the RMS value (green bars) quite often go past the Peak Value (aqua colour) which shouldn't happen.

[Yincognito]

The bare measures work perfectly. The problem is that they don't have a hold setting. The Peak meter only drops when the timer reaches 1000 ms, but rises regardless of the timing if the value exceeds it's current state.
Does that clear it up?

Perfectly. Though apparently, not every peak meter has a hold setting:

Maybe the Rainmeter Type=Peak is made based on such considerations.

Yes, I know, the peak meters in Winamp and Foobar do hold for a while.

[sl23]

Is that your own? That looks like someone's personal project. I have honestly never seen one like that. Also, if you watch, it does exactly what Rainmeter does. the RMS goes over the Peak indicator. Which isn't true Peak indication. That is the thing I am struggling with in my skin, everything else seems ok.

I have owned many hifi systems and never had EQ's work that way. Pro stuff definitely doesn't. And I know Rainmeter isn't meant for such things, but I would like to use it rather than having another app on my PC, so I can just get a rough idea if Input/Output levels are excessive. Plus it looks awful jumping around like that!

[Yincognito]

Is that your own? That looks like someone's personal project. I have honestly never seen one like that. Also, if you watch, it does exactly what Rainmeter does. the RMS goes over the Peak indicator. Which isn't true Peak indication.

It's taken from Giphy, after searching for "peak meter gif", don't know where it really comes from:
https://giphy.com/gifs/sound-waves-peak-meter-Aga929s9jwOM8
I don't know where you see the single "Peak" indicators on the top going under the multiple "RMS" indicators, cause I don't. Open the .webp in Photoshop or something, and check all 46 frames one by one like I did if you don't believe it. And yes, I posted it because it behaves exactly like the Rainmeter Type=Peak ones, which proves that there are different ways of representing them (with hold, without hold, etc). Of course, you prefer the former, which is fine, what I meant that it's not "wrong" either way.

[sl23]

Ok good. Must be an optical illusion, it looks to me like it goes over?! The right channel looks like it does briefly, about halfway through I think.
Well, ya learn something new every day! lol
But for working with audio, then it is wrong. For just looking good, then yeah, no problem.

No problem, I'll just live with what I have as it isn't too bad. Just too much of a perfectionist!

[Yincognito]

Ok good. Must be an optical illusion, it looks to me like it goes over?!
Well, ya learn something new every day! lol
But for working with audio, then it is wrong. For just looking good, then yeah, no problem.

LOL, ok, if you say so... I have a friend who's an expert in these things, has electric guitars and other bunch of audio stuff not to mention he sings really well, but I'm too lazy to call him now and ask about it (we tend to have long talks about everything under the sun, and that takes lots of cigars for me, lol).

No problem, I'll just live with what I have as it isn't too bad. Just too much of a perfectionist!

You don't have to live with it, you can make things behave as you want, though I'm not 100% sure about the best way to do it (especially the gradual drop afterwards, which seems to be a max of past values decreasing). Making it "stick" / "hold" is not a problem IMHO, what you do afterwards to replicate exactly what Winamp / Foobar do might be, since after holding out, both the RMS and Peak levels are time offset from the value that you holded on to. You could also take a look at the AudioLevel code to find out how Type=Peak works:
https://github.com/rainmeter/rainmeter/blob/master/Plugins/PluginAudioLevel/PluginAudioLevel.cpp