Audio Peak Level not dropping

[sl23]

I really appreciate your attempts and thank you so much for your time. Not really sure where you were going with it. The thing is, the blue "Fake Value" should never be below the others as that's the point of a Peak meter which is really what this has all been about.

No worries, I didn't think this was going to happen as it's a real hassle for me to figure out and I don't want to keep asking, cause you've helped so much, lately and in the past!

I'll just have to live with what I have I suppose...

EDIT: This was the original issue with the way I was doing it. It doesn't respond to increase in volume instantly, so the Last and Current Values jump up quicker than the Fake Value does. Anyway, just trying to explain a bit better.

[Yincognito]

I really appreciate your attempts and thank you so much for your time. Not really sure where you were going with it. The thing is, the blue "Fake Value" should never be below the others as that's the point of a Peak meter which is really what this has all been about.

This is precisely why I asked you twice about what should be the priority, because if time expiration is the priority as you also twice stated, then FakeValue will not always (or, better said, very rarely) be the greatest of the values. On the other hand, the value increase priority will do what you think you want, but it will stay on position for a much shorter time.

In short, in this case, you want to have your cookie and eat it too. That's simply not possible, and it doesn't help that you don't really know the implications of what you want.

[sl23]

On sensing a drop in volume, which can be made more or less sensitive by adding/removing zeros after the decimal, it will pause the meter to allow it to stay when dropped, but react straight away when increased in volume.

Don't take this the wrong way, I don't mean any disrespect, but maybe you didn't read this properly?

1. On sensing a drop in volume, it will pause the meter to allow it to stay when dropped = Peak Hold time.
2. but react straight away when increased in volume.

Your approach doesn't do both at once, so cake, or cookie, and eat it, was what I specified.

Like I said, I am thankful you tried, and I won't harass you over it. Thanks again for trying.

[sl23]

That's simply not possible, and it doesn't help that you don't really know the implications of what you want.

Every VU meter with Peak does exactly what I'm asking. But I assume you mean it's not possible with Rainmeter?
What do you mean by "you don't really know the implications of what you want." If I did I wouldn't have asked for help
No offence meant.

[Yincognito]

Don't take this the wrong way, I don't mean any disrespect, but maybe you didn't read this properly?

No disrespect either, but I actually read more than you were thinking of, given that I included the 2nd way (the "value increase" priority) in the code as well, anticipating your response (despite you assuring me that you wanted the "time expiration" priority twice). It's just that you didn't understand the implications properly.

Let me explain it better, for the last time: you either stay on that initial greater position for the whole second regardless of the increasing in volume potentially happening during that second OR you react straight away when increasing in volume regardless of whether that might happen during the second you want to stay in that initial greater position. It's either one or the other, there's no middle way, it's like saying you want to both drive your car for one whole hour and immediately get out whenever your speed increases.

Every VU meter with Peak does exactly what I'm asking.

No, it does not, because it's not logically possible, see the real life example above. It has nothing to do with Rainmeter. Whatever you think you saw in those VU meters is mostly likely skipping some values or something. But if you want, feel free to provide such an example, with the entire data for examination, and if you're right I'll admit without any issues.

For the earlier example with each of these volumes at 200 ms each, during a whole second:
1) 0.7
2) 0.5
3) 0.3
4) 0.4
5) 0.2
The process first chooses to display 0.7 when reaching 0.5, because 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, or 0.4 because the volume increased from the previous 0.3? Can you do both at the same time without one of them being canceled by the other? Show me the VU meter - or any other tool or human - that can do the latter, and I'll eat my hat (or hood, lol). Do you understand now?

[sl23]

if 0.7, 0.5, 0.3, 0.4, 0.2 happen one after the other during that one second while it should stay in position at 0.7 (because 0.5 was less than the previous 0.7 value), it should however use 0.4 when this occurs (because it is greater than the previous 0.3 value), right? In other words, an increase in the value has priority over the potential stay in position that might be happening at the same time? Yes or no.

if 0.7, 0.5, 0.3, 0.4, 0.2 happen one after the other during that one second while it should stay in position at 0.7
This was correct, what I asked for and what you achieved. Perfect, except I hadn't foreseen the downside of it. If you change it to this
if 0.7, 0.5, 0.3, 0.9, 0.2 Then the priority is given to the increase if it all happens as before within that second. Your code doesn't do that as it just continues regardless of the increase.

Only if during that second there is an increase in volume above the 0.7 does it override the delay. Perhaps, I assumed you know more about how Peak meters worked? You are a magician with code but if you aren't aware of how they work, then you can't make the code do what you want. Have you ever seen Peak meters in action?
I'm not saying you aren't right, I'm just guessing at how it appears to work from a non-programmer pov.

I'll try make a quick video with foobar...

[sl23]

I love analogies!

Imagine throwing a ball in the air, only a short distance, and hitting it up at different heights.
Except imagine it pauses in mid air, then drops. before it does, your hands are still moving up and down.
When it falls, it cannot go below your hands, physically impossible, unless you miss of course, so you hit it again no matter where your hands are.

If your hands are low, it doesn't affect the position of the ball, but soon as your hands go higher than the ball, regardless if paused or falling, it is hit upwards again.

Sorry, crap analogy, or maybe just a crap explanation of a good analogy, I dunno. But you get the idea hopefully?

[sl23]

Here's a 20 second video.
Notice your skin at 8 seconds, the green goes higher than the blue meter. This should not happen as the whole purpose of a Peak meter is to evaluate the highest volume level ALWAYS. Peak monitoring never ever goes below the current RMS level as it does with both yours and mine.
It would be like the ball goes literally through your hands in my very special analogy!

Also, notice there is a Peak Hold setting in the analyser's Options window. Which the AudioLevel plugin should have.

Hopefully the idea is better understood.

[sl23]

Try my skin, which isn't perfect as I can't get it to act on attack quickly enough, so the RMS value again goes above the Peak Value, which it should never do.

Code: Select all

[Rainmeter]
Update=25
BackgroundMode=2
SolidColor=255,255,255,20
AccurateText=1
MiddleMouseUpAction=[!Refresh]

[Metadata]
Name=VU Metre
Author=sl23
Information=VU Metre
Version=2024.6.30
License=CC BY 3.0

[Variables]
AquaDark=0,255,255,200
Green=128,255,0
Orange=255,170,0
OrangeDark=255,128,0
Red=255,100,100
White20=255,255,255,10
PeakDelayL=0
PeakDelayR=0

========================================
; Measures
========================================
[mAudio]
Measure=Plugin
Plugin=AudioLevel
Port=Output
RMSAttack=52
RMSDecay=300
RMSGain=2.0
PeakAttack=50
PeakDecay=3000
PeakGain=2.0
DynamicVariables=1

[mLeft]
Measure=Plugin
Plugin=AudioLevel
Parent=mAudio
Type=RMS
Channel=L

[mRight]
Measure=Plugin
Plugin=AudioLevel
Parent=mAudio
Type=RMS
Channel=R

[mPeakLeft]
Measure=Plugin
Plugin=AudioLevel
Parent=mAudio
Type=Peak
Channel=L
OnChangeAction=[!SetVariable PeakDelayL "[#CURRENTSECTION#]"]
IfCondition=#CURRENTSECTION#=1
IfTrueAction=[!ShowMeter ClipL][!UpdateMeter ClipL][!Redraw]
IfFalseAction=[!Delay 1000][!HideMeter ClipL][!UpdateMeter ClipL][!Redraw]
IfCondition2=(#CURRENTSECTION# < #PeakDelayL#)
IfTrueAction2=[!PauseMeasure #CURRENTSECTION#][!Delay 1000][!UnPauseMeasure #CURRENTSECTION#]
IfFalseAction2=[!UnPauseMeasure #CURRENTSECTION#]
DynamicVariables=1

[mPeakRight]
Measure=Plugin
Plugin=AudioLevel
Parent=mAudio
Type=Peak
Channel=R
OnChangeAction=[!SetVariable PeakDelayR "[#CURRENTSECTION#]"]
IfCondition=#CURRENTSECTION#=1
IfTrueAction=[!ShowMeter ClipR][!UpdateMeter ClipR][!Redraw]
IfFalseAction=[!Delay 1000][!HideMeter ClipR][!UpdateMeter ClipR][!Redraw]
IfCondition2=(#CURRENTSECTION# < #PeakDelayR#)
IfTrueAction2=[!PauseMeasure #CURRENTSECTION#][!Delay 1000][!UnPauseMeasure #CURRENTSECTION#]
;IfFalseAction2=[!UnPauseMeasure #CURRENTSECTION#]
DynamicVariables=1

========================================
; Meters
========================================
[sClip]
Shape=Rectangle 0,0,5,4 | Fill Color #Red# | StrokeWidth 0
Y=r
Hidden=1

[sPeak]
Shape=Rectangle 0,0,2,4 | Fill Color #AquaDark# | StrokeWidth 0
DynamicVariables=1
Y=r

[sBar]
BarOrientation=Horizontal
BarColor=#Green#,70
SolidColor=#White20#
W=200
H=4
Y=r

;-------------------------------------
[OutBarL]
Meter=Bar
MeasureName=mLeft
MeterStyle=sBar
X=0

[ClipL]
Meter=Shape
MeterStyle=sClip
X=5R

[PeakBarL]
Meter=Shape
MeterStyle=sPeak
X=([OutBarL:X]+[OutBarL:W]*[mPeakLeft])

;-------------------------------------
[OutBarR]
Meter=Bar
MeasureName=mRight
MeterStyle=sBar
X=0
Y=2R

[ClipR]
Meter=Shape
MeterStyle=sClip
X=5R

[PeakBarR]
Meter=Shape
MeterStyle=sPeak
X=([OutBarR:X]+[OutBarR:W]*[mPeakRight])

But it achieves the hold and almost works correctly, apart from needing faster reaction to increases in RMS volume above the Peaks current state. But I have no idea how to achieve that.

I'm not sure, but I think the key is in the use of the IfFalseAction2 condition of the [mPeakLeft] measure.
Sorry for the quick succession of posts again!

[sl23]

No, it does not, because it's not logically possible,
The process first chooses to display 0.7 when reaching 0.5, because 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, or 0.4 because the volume increased from the previous 0.3? Can you do both at the same time without one of them being canceled by the other? Show me the VU meter - or any other tool or human - that can do the latter, and I'll eat my hat (or hood, lol). Do you understand now?

Did you watch the video?
Do you see how it works?
Despite being logically impossible! lol

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?!

• Show me the VU meter - or any other tool or human - that can do the latter, and I'll eat my hat (or hood, lol).

Have you watched that video yet? I wanna see pics of you eatin' yer hat, or hood! Don't care which! lol

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.
How is that logically impossible? It works, and is how every Peak meter in existence works (watch the video to see it in action), and I can see the logic in it, I just don't know how to convert that into Rainmeter speak!

PS:

Did you watch the video yet? l