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.
sl23 wrote: ↑July 3rd, 2024, 4:38 pm
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?
sl23 wrote: ↑July 3rd, 2024, 4:38 pm
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...
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
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.
sl23 wrote: ↑July 3rd, 2024, 5:20 pm
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.
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.
sl23 wrote: ↑July 3rd, 2024, 6:21 pm
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.