Audio Peak Level not dropping

[sl23]

I'm wanting to use the Peak Level meter in my current skin. So I've resurrected an old version. I can remember there is an issue with the Peak metering, it doesn't hold the position, it basically acts like the RMS metering, but just gets the highest value. But a proper Peak meter holds it's value for 2-3 seconds.

I have a version of that code still that someone helped with. But the issue was that onced it peaked at 0db for a few seconds it never dropped once the volume got lower. It works well, until that point, then it stops responding. I was hoping to get this fixed if anyone has a clue about it.

I have tried adding this to the mPeakLeft measure, which fails:

Code: Select all

IfCondition=[mPeakLeft] = 1
IfTrueAction=[!UpdateMeasure mPeakLeft][!UpdateMeasure mTimeLeft][!UpdateMeter PeakLeft][!Redraw]

Here's the reduced set of code from the original skin with only the main set of meters:

Code: Select all

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

[Variables]
Player=CAD
ResetTime=2
VolLow=40
VolMax=100

Green=128,255,0
Orange=255,170,0
OrangeDark=255,128,0
Red=255,100,100
White20=255,255,255,20

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

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

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

[mPeakLeft]
Measure=Calc
Formula=( Max ( mPeakLeft, mLeft ))
OnChangeAction=[!DisableMeasure "mTimeLeft"][!UpdateMeasure "mTimeLeft"][!EnableMeasure "mTimeLeft"]
IfCondition=[mPeakLeft] = 1
IfTrueAction=[!UpdateMeasure mPeakLeft][!UpdateMeasure mTimeLeft][!UpdateMeter PeakLeft][!Redraw]

[mPeakRight]
Measure=Calc
Formula=( Max ( mPeakRight, mRight ))
OnChangeAction=[!DisableMeasure "mTimeRight"][!UpdateMeasure "mTimeRight"][!EnableMeasure "mTimeRight"]
IfCondition=[mPeakRight]=1
IfTrueAction=[!UpdateMeasure mPmPeakRighteakLeft][!UpdateMeasure mTimeLeft][!UpdateMeter mPeakRight][!Redraw]

[mTimeLeft]
Measure=Calc
Formula=( mTimeLeft + 1 )
IfCondition=(mTimeLeft=#ResetTime#)
IfTrueAction=[!DisableMeasure "mPeakLeft"][!UpdateMeasure "mPeakLeft"][!EnableMeasure "mPeakLeft"]
UpdateDivider=40

[mTimeRight]
Measure=Calc
Formula=( mTimeRight + 1 )
IfCondition=(mTimeRight=#ResetTime#)
IfTrueAction=[!DisableMeasure "mPeakRight"][!UpdateMeasure "mPeakRight"][!EnableMeasure "mPeakRight"]
UpdateDivider=40

[mClipLeft]
Measure=Plugin
Plugin=AudioLevel
Port=Output
Sensitivity=35
Channel=L
RMSAttack=50
RMSDecay=1000
RMSGain=2.0
IfCondition=[mClipLeft]=1
IfTrueAction=[!ShowMeter ClipBarL][!UpdateMeter ClipBarL][!Redraw]
IfFalseAction=[!HideMeter ClipBarL][!UpdateMeter ClipBarL][!Redraw]
DynamicVariables=1

[mClipRight]
Measure=Plugin
Plugin=AudioLevel
Port=Output
Sensitivity=35
Channel=R
RMSAttack=50
RMSDecay=1000
RMSGain=2.0
IfCondition=[mClipRight]=1
IfTrueAction=[!ShowMeter ClipBarR][!UpdateMeter ClipBarR][!Redraw]
IfFalseAction=[!HideMeter ClipBarR][!UpdateMeter ClipBarR][!Redraw]
DynamicVariables=1

========================================
; Meters
========================================
[sBar]
BarOrientation=Horizontal
SolidColor=#White20#
DynamicVariables=1
W=200
H=5

[OutBarL]
Meter=Bar
MeasureName=mLeft
MeterStyle=sBar
BarColor=#Green#,100
X=0
Y=0

[ClipBarL]
Meter=Bar
MeasureName=mClipLeft
MeterStyle=sBar
BarColor=#Red#
W=5
X=5R
Y=r

[PeakBarL]
Meter=Bar
MeasureName=mPeakLeft
MeterStyle=sBar
BarColor=#OrangeDark#
W=2
X=([OutBarL:W]*[mPeakLeft])
Y=r

[OutBarR]
Meter=Bar
MeasureName=mRight
MeterStyle=sBar
BarColor=#Green#,100
X=0
Y=2R

[ClipBarR]
Meter=Bar
MeasureName=mClipRight
MeterStyle=sBar
BarColor=#Red#
W=5
X=5R
Y=r

[PeakBarR]
Meter=Bar
MeasureName=mPeakRight
MeterStyle=sBar
BarColor=#OrangeDark#
W=2
X=([OutBarR:W]*[mPeakRight])
Y=r

I've changed the whole thing to use shape meters instead of graphics, in case you want to try it.
Seems to work ok, just that problem with the Peak indicators 'sticking' which I tried to find a way to reset them on max but not working out for me!

Appreciate any help

[Yincognito]

I have tried adding this to the mPeakLeft measure, which fails:

Again, if you "connect the dots", the answer is in the first sentence of the Usage chapter from this page in the manual - just remember what you need to update in similar approaches:
https://docs.rainmeter.net/manual/plugins/audiolevel/

Seems to work ok, just that problem with the Peak indicators 'sticking' which I tried to find a way to reset them on max but not working out for me!

I doubt they'll reset since their source is the audio signal which is more or less independent of your actions in the skin, but, although it does not answer your question - or at least not entirely -, why don't you try to (temporarily?) use AverageSize for an effect closer to the "sticking to" one?
https://docs.rainmeter.net/manual/measures/general-options/

[sl23]

Is it about Percentages? But the values in the About window don't show percentage, all Measures show between 0 and 1. The Peak measures don't go below 1 once they've been there for a couple seconds. If it is about percentage, that's the third sentence on that page!

The problem I think is the mTimeLeft/Right measures as once they get to 2, that stops the mPeakLeft/Right measures working correctly. Is that right? Those mTimeLeft/Right measures never go back down, they just keep counting ever upward, so if they need to be below 2 in order for the Peak measuring to work, they need resetting, don't they? Gotta be a better way!

Do I use AverageSize instead of or as well as the mTime measures? Should I remove all excess code and start from scratch with the raw measures/meters required for the skin?

EDIT: Makes no difference where I put the AverageSize=20, still works the same.

[sl23]

Ok, so I tried the AverageSize again but increased to 100 due to the fast update rate of the skin. It has an effect, but slows response time down, so that the Main meters go past the Peak ones, which shouldn't happen. How do I overcome this?

[Yincognito]

Is it about Percentages?
[...]
Do I use AverageSize instead of or as well as the mTime measures?

No, I meant that you have to update the parent in a parent - child measure system, not (only) the child. It's literally the first sentence there, not complicated to deduct, based on how other parent - child measures like WebParser and others work.

No, I meant that using AverageSize prolongs the output of the measure value, since the average changes slower than plain values (hence being closer to "stick to" a certain value).

As for maintaining the level of peak measures (not meters), it may also have to do with the values of the Peak related options from the AudioLevel parent measure. Incidentally, I didn't use peaks in any skin whatsoever, so I'm not an expert in how they should or do behave.

[sl23]

Oh, you meant first sentence in the Usage part, not page.

But using AverageSize on the Parent will affect all measures. Create a new one for peaks then, yes?

Just watch any digital VU meter with a Peak monitor on it and it always holds for a second before dropping. The trouble with AverageSize is that it is working for decay but it affects attack, which I don't want. Why it's not programmed with fast attack, slow decay is beyond me! That's how it's supposed to work.

I have already tried adjusting the settings for the Peak measures. These don't affect the 'Hold' of the Peak Meter, it just slows down the movement back. A peak meter performance could be divided into three zones:
Attack Speed
Hold Time
Decay Speed

But the way it has been designed is with only two: Attack and Decay. So I'm trying to figure out a way to delay the decay side of it in order to emulate a Hold Time. Not sure if that is a possibility? I know it's not likely an easy solution! I don't think it's even possible to constantly monitor drops in volume to then activate a delay bang, whilst monitoring for volume increase to then quickly respond to that and reset the delay on every increase of the volume.

[Yincognito]

Oh, you meant first sentence in the Usage part, not page.

Indeed - I believe that I was clear enough in my earlier reply:

the answer is in the first sentence of the Usage chapter from this page in the manual

Understanding is up to you, I can't control that...

But using AverageSize on the Parent will affect all measures. Create a new one for peaks then, yes?

Not sure about that, generally it's parents that provide data to the children, you'll have to test it yourself.

Not sure if that is a possibility? I know it's not likely an easy solution!

It probably is easy, actually. For example, on a second look at your code, I didn't see a child measure with Type=Peak there, they're all RMS based ones. If that doesn't work, you could simply pass the peak value to a Calc with a suited UpdateDivider on it and be done with it.

[sl23]

Sorry, as I said, my impatience makes me skim read instead of reading properly!

I didn't write the code for the Peak. Years ago I think it was eclectic-tech maybe did that part. I just need it to stop sticking when maxed out for 2 seconds.

I'll try adding them and your suggestion too. Thanks

[sl23]

Trouble with adding the UpdateDivider is that it will also slow the attack response time. What's needed is to delay the decrease responding straight away without affecting attack. It also makes it jittery rather than smooth.

[Yincognito]

Sorry, as I said, my impatience makes me skim read instead of reading properly!

I didn't write the code for the Peak. Years ago I think it was eclectic-tech maybe did that part. I just need it to stop sticking when maxed out for 2 seconds.

I'll try adding them and your suggestion too. Thanks

Don't worry, I got it wrong too, I thought that you wanted the peak to stick instead. Oh, what a carousel of misunderstandings...

In any case, I think using the Type=Peak in the relevant child measures, coupled with proper Peak related options in the parent measure, should get you closer to what you want. Can't guarantee how much closer, since as I said, I almost never used anything other than RMS in AudioLevel measures. Regardless, there is the Calc + UpdateDivider variant which is much more flexible, so you have a plan B.