Audio Peak Level not dropping

[Yincognito]

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

Another way of approaching this based on only RMS and Max() would be to use ActionTimer with something like:

Code: Select all

ActionList1= ShowMaxAction | Wait 1000 | Repeat GradualDropAction, WaitTime, GradualDropSteps

and control it with [!CommandMeasure SomeMeasure "Stop 1"] and [!CommandMeasure SomeMeasure "Execute 1"] based on whether a new RMS Max() occured.

[sl23]

Well, how would you know it's peaked beforehand if the Peak indicators get there afterwards? lol That's what I mean.
The hold isn't really the issue for me. Even the drop afterwards is a little rubbish, but the worst thing for me is the fact that I can't figure out the attack responding properly to large increases in volume.

Source code! lol Are you joking? I can't even use a simple program like Rainmeter without asking for help!
Suppose no harm looking though.
Thanks.

I did think about ActionTimer, but I can't get my head around it. Perhaps worth taking a look at that too. Thank you.

[Yincognito]

Well, how would you know it's peaked beforehand if the Peak indicators get there afterwards? lol That's what I mean.

Apart from holding out or decreasing afterwards, I suppose the peak value is just the maximum current RMS or something, no?

Source code! lol Are you joking? I can't even use a simple program like Rainmeter without asking for help!

Well, there are comments, and the formulas are mostly self explanatory, though it's a bit of math involved...

[sl23]

Peak is generally the max RMS level, I believe, but you don't see it on the meter as it's too fast to register visually, so the Peak indicator is used to monitor the highest levels and transient peaks when recording to avoid clipping the signal. Least, that's my understanding of it.

I'm good at maths, but not used it in a loooooong time! Maybe, I should say, I was good! lol

[sl23]

Currently, I am trying this:

Code: Select all

[mPeakLeft]
Measure=Plugin
Plugin=AudioLevel
Parent=mAudio
Type=Peak
Channel=L
OnChangeAction=[!SetVariable PeakDelayL "[#CURRENTSECTION#]"]
DynamicVariables=1

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#]

IfCondition3=(#CURRENTSECTION# >= #PeakDelayL#)
IfTrueAction3=[!UnPauseMeasure #CURRENTSECTION#]

I can't help wondering though, is there any difference between using Ifcondition3, as above or using this IfFalseAction2 statement?:

Code: Select all

IfCondition2=(#CURRENTSECTION# < #PeakDelayL#)
IfTrueAction2=[!PauseMeasure #CURRENTSECTION#][!Delay 1000][!UnPauseMeasure #CURRENTSECTION#]
IfFalseAction2=[!UnPauseMeasure #CURRENTSECTION#]

Is there any performance difference? Not in Rainmeter CPU/RAM efficiency but in the skins ability to respond to the changes? I don't understand with the high Update of the skin why the !UnPause bang doesn't react quickly enough, creating a visual difference between the RMS and Peak.

[Yincognito]

I can't help wondering though, is there any difference between using Ifcondition3, as above or using this IfFalseAction2 statement?:

Generally speaking, yes, there can be. It's not performance related, more like functionally related. Can't come up with an example or an explanation now since it's a bit difficult to explain (or remember) since it involves more complex scenarios, but in your case there shouldn't be any difference.

P.S. One thing I forgot to mention during our discussion here: !Delay has some "erratic" behavior if more delays are overlapping or done concurrently - at least that's what my experience with it was in some cases. You probably noticed that I didn't use it in my sample, and chose to count time with a Calc instead. That being said, the problem you have "might" (I'm just guessing here) be related to pausing the measure with the IfCondition. A paused measure will NOT run any IfCondition attached to it.

[sl23]

Ok, thanks.

A paused measure will NOT run any IfCondition attached to it.

[sl23]

One thing, of the many, I don't understand, why do some plugins use Parent/Child? I don't get the reason for it. Why not just have one measure for each 'type' of info like in CPU or Internet for example?

This'll be why it's not updating the increase in volume then even if the reason you stated isn't the cause:

Note that this is a very limited form of what is offered by the ActionTimer plugin. There is no way to interrupt or cancel this short of a !Refresh of the skin, and nothing in the action itself can be dynamically changed during the execution of the action.

[Yincognito]

One thing, of the many, I don't understand, why do some plugins use Parent/Child? I don't get the reason for it. Why not just have one measure for each 'type' of info like in CPU or Internet for example?

This'll be why it's not updating the increase in volume then even if the reason you stated isn't the cause:

The Parent/Child system probably has to do with how the plugins were written and the fact that they need a multitude of options that refer to related but different "child" instances from the same "parent" category.

I'm not entirely certain that this is the cause regarding delays. After all, it says "nothing in the action itself", which seems to indicate that other actions are perfectly fine with it.

[sl23]

Oh right I see.