help with time counter

[CarlotaN]

Me alegra haberte ayudando aunque sea un poco, ojalá comparta el Whiskey de vez en cuando jajaja.

Jajaja! no me gusta el alcohol! Pero igual si pruebas el crono unos minutos verás las curvas como van
Ha ha ha! I do not like alcohol! But maybe if you try the time for a few minutes you will see the curves as they go

So, as far as I could tell, the issue has been COMPLETELY solved, correct? Using an Update of 1000 and a corresponding max value in the formula, that is. I don't like to let stuff half done, if by any chance that's the case.

The truth is that it fits quite well... until it has a few rounds of whiskey, but it is more than enough! Millions of thanks to everyone!

[Yincognito]

The truth is that it fits quite well... until it has a few rounds of whiskey, but it is more than enough! Millions of thanks to everyone!

Haha, yeah, that is normal. Any measure based on Rainmeter's internal update rates will gradually be out of sync with the actual time, see the note here:
https://docs.rainmeter.net/manual/skins/rainmeter-section/#Update

That is why Time measures should be used for that counting as well, so that things are based on precise system time instead of updates depending on how busy that system is. Once that is done, there won't be any out of sync situations anymore, especially since you use a more suited Update of 1000 now.

[RicardoTM]

So, as far as I could tell, the issue has been COMPLETELY solved, correct? Using an Update of 1000 and a corresponding max value in the formula, that is. I don't like to let stuff half done, if by any chance that's the case.

P.S. Forgot to say earlier but the "960" value I suggested for the Update of 60 will vary from computer to computer, depending also on how busy the CPU is. This is why it was an approximation. Of course, neither Update nor the max value are set in stone, but they MUST suit / relate to one another, so that the timing math checks out.

Not completely, she's still having problems with the roundline desynchronizing after some time. To me, this might be due to the counter [MeasureBar] not starting from 0, it quickly jumps to 1 after clicking on the play button. Which makes the math incorrect. I don't really know how to make it start from 0 to be honest, maybe you could help with that.

Captura de pantalla (60).png

Actually, now that I say that, the fix should be changing MinValue=0 to MinValue=1 on [MeasureBar].

Carlota, intenta cambiando MinValue=0 a MinValue=1 y MaxValue=60 a MaxValue=61 en [MeasureBar] a ver si eso le quita lo ebrio.

Ya lo dejé andando un rato así y funciona bien:

Captura de pantalla (62).png

Olvidalo, causa problemas al pausar, ya encontré la solución, no me había percatado de el measure [CalcElapsedSeconds]. Se puede usar el valor de ese measure en lugar del counter. Haz lo siguiente:

Remplaza MeasureName con MeasureName=CalcElapsedSeconds en [MeterSeconds]. Esto hará referencia al valor de el calculo del measure [CalcElapsedSeconds]. Te queda así:

Code: Select all

[MeterSeconds]
Group=Meters
Meter=Roundline
MeasureName=CalcElapsedSeconds
X=r
Y=r
StartAngle=(-PI/2)
RotationAngle=(2*PI)
LineStart=54
LineLength=58
LineColor=f9932e
Solid=1
AntiAlias=1

Ahora agrega MinValue=0 MaxValue=60 a [CalcElapsedSeconds], debe quedar así:

Code: Select all

[CalcElapsedSeconds]
Group=Meters
Measure=Calc
Formula=Floor(MeasureElapsedTime / 10) % 60
RegExpSubstitute=1
Substitute="^(\d)$":"0\1"
MinValue=0
MaxValue=60

y borra [MeasureBar] por completo, ya no es necesaria.

También borra los bangs relacionados a [MeasureBar] en las variables ActionPlay y ActionPause ([!EnableMeasure MeasureBar], [!UnpauseMeasure MeasureBar] y [!PauseMeasure MeasureBar])

Esto lo debe resolver de una vez por todas.

I didn't notice the CalcElapsedSeconds measure, the fix was just to use the Update=1000 and that measure instead of the counter for the roundline.

[Yincognito]

I didn't notice the CalcElapsedSeconds measure, the fix was just to use the Update=1000 and that measure instead of the counter for the roundline.

If that measure is based on data from Time measures, then the fix will certainly work indeed, like I mentioned in my previous reply. A Calc based counter will never be able to be as precise as a Time measure when measuring time. Didn't check the code too much, given that I only intervened occasionally in this thread.

[balala]

After two pages of replies most in Spanish, which I don't speak (I often say: the only thing I know in Spanish is 'Bonjour", which means Goodbye), I am not sure at all if finally the issue has been fixed. Now I see what time mismatch does mean, previously I didn't even realize there is such a problem, but now I see there definitely is. So, has it been fixed in meantime? Because I don't work with it, if it got a fix.

[Yincognito]

So, has it been fixed in meantime?

Up for CarlotaN to answer it. For me, using the approach in RicardoTM's last reply does the job in my brief tests, albeit with a small (and probably understandable) delay at the start. If the OP is happy with the solution after more extensive testing, I guess the matter would be settled.

[balala]

If the OP is happy with the solution after more extensive testing, I guess the matter would be settled.

Alright, let's see...

[CarlotaN]

Thanks guys! Tomorrow I will do the tests and tell you how it goes. I apologize to Balala for the Spanish. Bon jour is French and means good morning so I wish you all bonne nuit (good night). See you tomorrow

[balala]

I apologize to Balala for the Spanish.

Don't apologize. Just didn't want to translate all the discussion, to realize if the issue is fixed.

Bon jour is French and means good morning

See you tomorrow

Ok, let us know what's going on.

[Yincognito]

Bon jour is French and means good morning so I wish you all bonne nuit (good night).

I think that was a small joke by balala: not knowing the language, he'd just skip those parts. A pretty good joke, in my view - not necessarily related to Spanish itself, but to any language one is not familiar with.

Google can help with that most of the times, but not always, and when you have a lot to translate it becomes more difficult. That's why using a lingua franca understood by most people is a good choice for forums like this. It becomes more difficult for people with poorer English abilities, but it helps overall, since other users that might have similar problems in the future can understand how to reach a solution for their case.

Looking forward to hear from you tomorrow - all the best.