It is currently March 29th, 2024, 10:03 am

Bell ring clock skin

Get help with creating, editing & fixing problems with skins
User avatar
death.crafter
Rainmeter Sage
Posts: 1399
Joined: April 24th, 2021, 8:13 pm

Re: Bell ring clock skin

Post by death.crafter »

Yincognito wrote: July 18th, 2021, 3:13 pm LOL, yes, of course. But it will still cut out the 22:00 ringing, now won't it? Anyway, what's clear is that it can be done just by slightly altering some little things in whichever approach, so I guess it's not that big of a deal. ;-)
Hmm... I don't see why tho. The Hour measure wouldn't be disabled so you can use that to play the 22nd alarm.
from the Realm of Death
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Bell ring clock skin

Post by Yincognito »

death.crafter wrote: July 18th, 2021, 4:42 pm Hmm... I don't see why tho. The Hour measure wouldn't be disabled so you can use that to play the 22nd alarm.
Yeah, well, the long and short of it is that Disabled=(([Hours]>22) || ([Hours]<7) ? 1 : 0) won't do what the OP wanted, if placed (in my approach, don't know about yours) into [MinuteRings]. Actually, there are even more issues with this kind of approach:
- it won't work for the 07:00 rings either, although in theory it should; what happens is that the measure is indeed activated then, but it won't play because the measure value when disabled (i.e. 0) is the same with the measure value at 07:00 (i.e. also 0), thus the OnChangeAction won't be triggered
- if you change the hour AND the minutes externally while the skin is active and the measure enabled, it will play even if it's not o'clock or half an hour moment, if changed from, say, an under the 30th minute to past the 30th minute time; this happens with my alternative Disabled=((([Hours:]<=6) && ([Minutes:]<=55)) || (([Hours:]>=22) && ([Minutes:]>=5)) ? 1 : 0) placed in [MinuteRings], and it also has to do with the OnChangeAction being triggered
FreeRaider wrote: July 18th, 2021, 1:44 pm1) How can I have two rings of bell2 every 30 minutes. Bell2 currently rings every 15 minutes.
2) I would like to add a time range, let's say from 07:00 to 22:00. How do I create this range?
Therefore, a better - and more compact - approach (probably closer to what jsmorley had in mind when insisting on seconds):

Code: Select all

[Variables]
Wait=2500
MinuteInterval=30
RingsPerInterval=2
MinHours=7
MinMinutes=0
MaxHours=22
MaxMinutes=0

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1

---Measures---

[Ring]
Measure=Plugin
Plugin=ActionTimer
ActionList1=Repeat HourRing,#Wait#,#HourRings# | Wait #Wait# | Repeat MinuteRing,#Wait#,#MinuteRings# | Wait #Wait#
HourRing=[Play "#@#Bell1.wav"]
MinuteRing=[Play "#@#Bell2.wav"]
UpdateDivider=-1
DynamicVariables=1

[Time]
Measure=Time
Format=%H:%M:%S
IfCondition=((([Time:Timestamp]%(#MinuteInterval#*60))=0) && (([Time:Timestamp]%(24*60*60))>=(#MinHours#*60*60+#MinMinutes#*60)) && (([Time:Timestamp]%(24*60*60))<=(#MaxHours#*60*60+#MaxMinutes#*60)))
IfTrueAction=[!SetVariable HourRings (Trunc(([Time:Timestamp]%(24*60*60))/(60*60)))][!SetVariable MinuteRings (Trunc((([Time:Timestamp]%(24*60*60))%(60*60))/(#MinuteInterval#*60))*#RingsPerInterval#)][!Log "HourRings = [#HourRings], MinuteRings = [#MinuteRings]"][!UpdateMeasure Ring][!CommandMeasure Ring "Stop 1"][!CommandMeasure Ring "Execute 1"]
IfConditionMode=1
DynamicVariables=1

---Meters---

[TimeText]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
MeasureName=Time
Text=%1
The formulas in the IfCondition could have been simpler, but in the interest of consistency I first got the time related values per day, then per hour, then per minute interval. The condition tests whether the time is precisely divisible by the minute interval, as well as whether the time is between the min to max time range. All variables are adjustable. There is also a log there, for convenient display of the critical variables.

P.S. Remind me to avoid OnChangeAction for the future as well. I did it in the past, thought it could work out here perfectly, but eventually it was more feasible to just use the classic methods.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
death.crafter
Rainmeter Sage
Posts: 1399
Joined: April 24th, 2021, 8:13 pm

Re: Bell ring clock skin

Post by death.crafter »

Yincognito wrote: July 18th, 2021, 7:35 pm Yeah, well, the long and short of it is that Disabled=(([Hours]>22) || ([Hours]<7) ? 1 : 0) won't do what the OP wanted, if placed (in my approach, don't know about yours) into [MinuteRings]. Actually, there are even more issues with this kind of approach:
- it won't work for the 07:00 rings either, although in theory it should; what happens is that the measure is indeed activated then, but it won't play because the measure value when disabled (i.e. 0) is the same with the measure value at 07:00 (i.e. also 0), thus the OnChangeAction won't be triggered
I changed it to => and <=.

My idea was more like have a different hour measure. That will disable the measures, and that measure can play the 7th and 22nd alarm.

Well, your way is more feasible. Mine is just dumb. But hey. it's a way. :rofl:
from the Realm of Death
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Bell ring clock skin

Post by Yincognito »

death.crafter wrote: July 19th, 2021, 4:24 am I changed it to => and <=.

My idea was more like have a different hour measure. That will disable the measures, and that measure can play the 7th and 22nd alarm.

Well, your way is more feasible. Mine is just dumb. But hey. it's a way. :rofl:
Nope, your way is not dumb by any means - I never said that. Disabling the measures and at the same time using OnChangeAction will produce slight issues, though (due to same or different 0 value for the said measures). That's not your fault, it was me actually who mentioned disabling first (I had a feeling it was tricky, so I added pausing, just in case, although I'm not sure it would have completely eliminated the drawbacks). Yes, I understood what you meant with disabling the measure from another place / measure the first time, I'm just not a fan of spreading those conditions everywhere, since they are harder to follow. I also thought to do it from one of the hour measures like you said (there were 2 in my case) initially, but I liked your "local" Disabled option idea so much that I didn't want to go back to my original thought anymore. :lol:

Anyway, personally I'm content with my last code, it is superior to my previous ones (I'm only talking about the "evolution" of my approach here, not saying anything about yours) and stuff can be adjusted through variables - which is something I always aim to do, regarding flexibility. Its only shortcoming, if I could say so, it's that is uses longer formulas than the previous "version", but then, one can't do more comprehensive things without formulas anyway. :confused:
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
FreeRaider
Posts: 826
Joined: November 20th, 2012, 11:58 pm

Re: Bell ring clock skin

Post by FreeRaider »

Thanks everyone for the tips and code.
One last thing and I think we're done.
Considering that twenty rings of bells is a little too many, how can I show the time 20:00 but only make 8 rings?

Thanks
User avatar
death.crafter
Rainmeter Sage
Posts: 1399
Joined: April 24th, 2021, 8:13 pm

Re: Bell ring clock skin

Post by death.crafter »

FreeRaider wrote: July 20th, 2021, 12:05 pm Thanks everyone for the tips and code.
One last thing and I think we're done.
Considering that twenty rings of bells is a little too many, how can I show the time 20:00 but only make 8 rings?

Thanks
If you are going by Yin's way,

Code: Select all

[Time]

...

IfTrueAction=[!SetVariable HourRings (Clamp(Trunc(([Time:Timestamp]%(24*60*60))/(60*60)), 0, 8))][...]
If 8 rings is the max you want, I just clamped it between 0 and 8. You can perform any reqired operation when you set the variable.
If you are going, by Yang's way, well... Don't.
from the Realm of Death
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Bell ring clock skin

Post by Yincognito »

FreeRaider wrote: July 20th, 2021, 12:05 pm Thanks everyone for the tips and code.
One last thing and I think we're done.
Considering that twenty rings of bells is a little too many, how can I show the time 20:00 but only make 8 rings?

Thanks
Since death.crafter fortunately took care of the bare limiting of the number of rings irrespective of hour (chuckled a bit at the Yang's allusion), I'll cover dvo's variant, which will still display the 20:00 time, but will ring as if it was an AM/PM number for the hour (meaning 16:30 will result in 4 hour rings and 2 minute rings, and so on). The solution is actually really simple - just add %12 (see modulus or remainder of a division on Wiki) to setting the HourRings from the [Time] measure's IfTrueAction, like:

[!SetVariable HourRings (Trunc(([Time:Timestamp]%(24*60*60))/(60*60))%12)]

This will keep the AM hour rings unchanged, but reduce PM hour rings to be similar with the AM ones. Bear in mind that, unfortunately, this will also result in an unwanted side effect of no sound for 12:00:00 (or 12:00:00 PM) because the modulus / remainder of 12/12 is 0. There are multiple ways one can deal with that, but one of the easiest ways, without expanding the formula too much is to subtract and add 1 from / to the value in the formula, at different stages of the calculation, in order to BOTH get the same result AND avoid the "blank" 12:00:00 rings, like:

[!SetVariable HourRings ((12+Trunc(([Time:Timestamp]%(24*60*60))/(60*60))-1)%12+1)]

Note: I added 12 at the start to make it ring 12 times even at 00:00:00, even though this time does not belong to your 07:00:00 - 22:00:00 time range. You can remove this part if you want and it wil behave the same in your specific case, but I just thought it's better to have it, for consistency. The reason of adding 12 is because subtracting 1 from 0 yields -1, a negative number; adding the value of the divisor (12, in this case) to the result protects against that, without changing the result.

In other words, so you can understand what's happening:
- [Time:Timestamp]%(24*60*60) will get the number of seconds that have passed for the current day, since a day has 24*60*60 seconds
- next, dividing the above with (60*60) gets the number of hours that have passed for the current day, since an hour has 60*60 seconds; since this is plain division, that number will be fractional (i.e. has digits after the dot), so we need to Trunc() it to get its integer part
- considering the two bullets above, we now have the number of hours that have passed for the current day, as an integer number, which is what we want
- the key is obviously getting the remainder (%) from the division of the above number and 12, but we can avoid getting the undesirable 0 if we subtract and add 1 to the result; for example, 16 % 12 = 4, but so is (16 - 1) % 12 + 1 = 15 % 12 + 1 = 3 + 1 = 4, with the added advantage of not ever getting 0 as a result, since unlike 12 % 12 = 0, the alternative (12 - 1) % 12 + 1 = 11 % 12 + 1 = 11 + 1 = 12.

P.S. Apart from this trick of avoiding the 0 result, the MinuteRings formula is more or less using the same approach. It's longer, but not that complicated once you understand what's happening.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
FreeRaider
Posts: 826
Joined: November 20th, 2012, 11:58 pm

Re: Bell ring clock skin

Post by FreeRaider »

Maybe I did not say it clear enough.

Number of ring (bell1): 7 if time is 07:00 or 19:00
8 if time is 08:00 or 20:00
and so on.

Time is in the 24-hours format but bells ring in the 12-hours format
User avatar
FreeRaider
Posts: 826
Joined: November 20th, 2012, 11:58 pm

Re: Bell ring clock skin

Post by FreeRaider »

Yincognito wrote: July 20th, 2021, 3:05 pm Since death.crafter fortunately took care of the bare limiting of the number of rings irrespective of hour (chuckled a bit at the Yang's allusion), I'll cover dvo's variant, which will still display the 20:00 time, but will ring as if it was an AM/PM number for the hour (meaning 16:30 will result in 4 hour rings and 2 minute rings, and so on). The solution is actually really simple - just add %12 (see modulus or remainder of a division on Wiki) to setting the HourRings from the [Time] measure's IfTrueAction, like:

[!SetVariable HourRings (Trunc(([Time:Timestamp]%(24*60*60))/(60*60))%12)]

This will keep the AM hour rings unchanged, but reduce PM hour rings to be similar with the AM ones. Bear in mind that, unfortunately, this will also result in an unwanted side effect of no sound for 12:00:00 (or 12:00:00 PM) because the modulus / remainder of 12/12 is 0. There are multiple ways one can deal with that, but one of the easiest ways, without expanding the formula too much is to subtract and add 1 from / to the value in the formula, at different stages of the calculation, in order to BOTH get the same result AND avoid the "blank" 12:00:00 rings, like:

[!SetVariable HourRings ((12+Trunc(([Time:Timestamp]%(24*60*60))/(60*60))-1)%12+1)]

Note: I added 12 at the start to make it ring 12 times even at 00:00:00, even though this time does not belong to your 07:00:00 - 22:00:00 time range. You can remove this part if you want and it wil behave the same in your specific case, but I just thought it's better to have it, for consistency. The reason of adding 12 is because subtracting 1 from 0 yields -1, a negative number; adding the value of the divisor (12, in this case) to the result protects against that, without changing the result.

In other words, so you can understand what's happening:
- [Time:Timestamp]%(24*60*60) will get the number of seconds that have passed for the current day, since a day has 24*60*60 seconds
- next, dividing the above with (60*60) gets the number of hours that have passed for the current day, since an hour has 60*60 seconds; since this is plain division, that number will be fractional (i.e. has digits after the dot), so we need to Trunc() it to get its integer part
- considering the two bullets above, we now have the number of hours that have passed for the current day, as an integer number, which is what we want
- the key is obviously getting the remainder (%) from the division of the above number and 12, but we can avoid getting the undesirable 0 if we subtract and add 1 to the result; for example, 16 % 12 = 4, but so is (16 - 1) % 12 + 1 = 15 % 12 + 1 = 3 + 1 = 4, with the added advantage of not ever getting 0 as a result, since unlike 12 % 12 = 0, the alternative (12 - 1) % 12 + 1 = 11 % 12 + 1 = 11 + 1 = 12.

P.S. Apart from this trick of avoiding the 0 result, the MinuteRings formula is more or less using the same approach. It's longer, but not that complicated once you understand what's happening.

Thanks.I posted almost at the same time and I hadn't read your answer
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Bell ring clock skin

Post by Yincognito »

FreeRaider wrote: July 20th, 2021, 3:15 pm Thanks.I posted almost at the same time and I hadn't read your answer
No problem, I suspected that was the case. ;-)
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth