ronzino wrote: ↑June 7th, 2022, 9:33 am
You are right, sampling with an update rate of the skin less then one second a measure sampled at 1hz is no sense.
But there are a lot of case where you need to go below 1hz sampling for example
FFT or vumeter on audio channels
Disk activity monitoring (the good old blinking led)
Time frame of gpu
Cpu core usage or frequency just to have smooth bar transition (over sampling and then averaging)
Yeah, well, the thing is that data collection once a second is done not per measure, not per skin, but per Rainmeter instance. So, you can't trick it to enable and trigger a measure at an under 1 second interval compared to another, or use two or more skins to get data at different times during a second.
Since there's no "proper" way (if there's any, to start with) to have two Rainmeters run at the same time on the same machine, we could scrap the perfection requirement from the task (even though I personally love things to be perfect, not to mention I do believe perfection exists and it's possible) and just focus on making it functional, assuming you really really want to do it this way. The code below will provide a basic
linear interpolation of what "could" be the CPU usage if the "transition" from one measured value to the one done a second later would happen at a constant rate (a
more complex interpolation like a polynomial or a spline one would be appropriate, but this should be enough for demonstration purposes). You can set the
Fast and
Slow update rates higher to better see what's going on, say 1000 and 10000 for example. The
CPUInterpolation measure computes the interpolation between
CPUPrev measured a second or more ago and
CPULast measured during the "current" second, according to how many
UpdatesForSecond passed from the
UpdatesPerSecond total ... well, technically it's the amount of
Fast updates for and per
Slow updates if you reference to something different than one second:
Code: Select all
[Variables]
FastUpdate=25
SlowUpdate=1000
UpdatesPerSecond=(#SlowUpdate#/#FastUpdate#)
UpdatesForSecond=0
CPUPrev=0
[Rainmeter]
Update=#FastUpdate#
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255
---Measures---
[CPULast]
Measure=Plugin
Plugin=UsageMonitor
Alias=CPU
Index=0
MinValue=0
MaxValue=100
UpdateDivider=#UpdatesPerSecond#
DynamicVariables=1
[CPUInterpolation]
Measure=Calc
Formula=([#CPUPrev]+[#UpdatesForSecond]*(CPULast-[#CPUPrev])/[#UpdatesPerSecond])
MinValue=0
MaxValue=100
OnUpdateAction=[!SetVariable UpdatesForSecond (([#UpdatesForSecond]+1)%[#UpdatesPerSecond])][!SetVariable CPUPrev ([#UpdatesForSecond]=0?[CPULast:]:[#CPUPrev])]
DynamicVariables=1
---Meters---
[Text]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
MeasureName=CPUInterpolation
Text=Prev: [#CPUPrev]#CRLF#Step: [#UpdatesForSecond]#CRLF#ICPU: %1#CRLF#Last: [CPULast:5]
NumOfDecimals=5
DynamicVariables=1
[Lines]
Meter=Line
MeasureName=CPULast
MeasureName2=CPUInterpolation
Y=10R
W=[Text:W]
H=100
LineCount=2
LineColor=0,255,0,255
LineColor2=255,0,0,255
SolidColor=0,0,0,255
AutoScale=1
AntiAlias=1
DynamicVariables=1
I added a Line meter to better illustrate the effect (green is the once per second data, red is the interpolated one):
UsageMonitor Interpolation.jpg
The problem with this is that although it's functional and achieves the purpose of providing data at intervals lower than 1 second ... the values are linear approximates of the usage from 1 second earlier. This is unavoidable, as you'd need to know both the T0 and T1 (where T is time) values in order to compute the interpolation, and since the T1 value can only be for the "current second" (because you can't know values from the future, obviously), the T0 value must be from a second earlier.
Even if you're not ok with the approach, that's the best you can do. Who knows, maybe it can give you some other ideas.