fading trough 3 colors... how to do it?

[Yincognito]

there is a detail that I don't understand, you write a lot of expression like this (([#Range]+1)/[#IdMax]), where is missing the character "#" at the end of the variable name.
The skin is running without errors or warnings so it seems that is not a problem, so does it means that the end # is not needed or in this case is a kind of "operator"?

The explanation is here. It's about the nested form of referencing variables and measures, basically. I had to nest things when using [#R[#EIndex]] or [#R[#SIndex]], i.e. #R<EndIndex># and #R<StartIndex>#, so I figured why not using that notation everywhere I could (at least in the formulas), so that everything is made using the same "standards".

If you don't like that, you can revert to the normal notation, where [#Variable] becomes #Variable# and such, but only for things that are not nested.

[brax64]

The explanation is here. It's about the nested form of referencing variables and measures, basically. I had to nest things when using [#R[#EIndex]] or [#R[#SIndex]], i.e. #R<EndIndex># and #R<StartIndex>#, so I figured why not using that notation everywhere I could (at least in the formulas), so that everything is made using the same "standards".

If you don't like that, you can revert to the normal notation, where [#Variable] becomes #Variable# and such, but only for things that are not nested.

No that's ok with me, only because it never happened to me before to have seen that notation so that's why I asked... my learning curve is still going uphill
Thanks also balala and jsmorley for promptly guide me to the source, appreciated!

[Yincognito]

No that's ok with me, only because it never happened to me before to have seen that notation so that's why I asked... my learning curve is still going uphill
Thanks also balala and jsmorley for promptly guide me to the source, appreciated!

Yep, it appears so. Asking such nice questions about colors seems to bring additional benefits...

[brax64]

Yep, it appears so. Asking such nice questions about colors seems to bring additional benefits...

Yep, throw myself in a rabbit hole

[Yincognito]

Yep, throw myself in a rabbit hole

Become a lion then, and walk your way up from the hole.

[brax64]

Become a lion then, and walk your way up from the hole.

I'm trying..., I'm trying... slowly... one color at the time...

[Yincognito]

I'm trying..., I'm trying... slowly... one color at the time...

If you don't understand something, ask.

For example, the #Interval# (or [#Interval], in the nested form) is the the interval at the end of which the indexes in R<index>, G<index>, B<index> change, i.e. the 50 used in balala's IfCondition and division (that was just one of them, as in the case of 3 colors there are 2 such intervals, aka 0-50 and 51-100, but the number of intervals increases based on the number of transition colors used, hence the formulas for them).

The starting index, i.e. #SIndex# (or [#SIndex]), is the lower value index in balala's code. It is obtained by getting the integer part of Value/Interval, so accordingly in the 3 color scenario, once Value gets to 51, the starting index becomes 1 after previously being 0 (and so on, for the more colors scenario). The ending index is just the starting index incremented by 1, that is simple.

As for the R, G, B formulas I just replicated balala's formulas with the only (and important) difference that they don't need any kind of modification if the Range or the number of colors changes, as they are all based on the above values, instead of hardcoded ones in IfConditions and IfTrueActions / IfFalseActions.

Bottom line, the code is no big deal, it does pretty much what balala's code does, but dynamically and not hardcoded. This is of great help if the user dynamically modifies the parameters, as no rewriting or modification of the transition code is required whatsoever.

[balala]

I'd like everything to work just from the formulas, no IfConditions involved.

Didn't follow closely everything posted in this topic, but here is it:

Code: Select all

[Rainmeter]
Update=1000

[Variables]
R1=255
G1=0
B1=0

R2=0
G2=255
B2=0

R3=0
G3=0
B3=255
Range=0

[MeterColor]
Meter=Image
SolidColor=((#Range#<50)*(#R1#+(#Range#/50)*(#R2#-#R1#))+(#Range#>=50)*(#R2#+((#Range#-50)/50)*(#R3#-#R2#))),((#Range#<50)*(#G1#+(#Range#/50)*(#G2#-#G1#))+(#Range#>=50)*(#G2#+((#Range#-50)/50)*(#G3#-#G2#))),((#Range#<50)*(#B1#+(#Range#/50)*(#B2#-#B1#))+(#Range#>=50)*(#B2#+((#Range#-50)/50)*(#B3#-#B2#)))
X=0
Y=0
W=100
H=50
DynamicVariables=1
MouseScrollDownAction=[!SetVariable Range "(Clamp((#Range#-1),0,100))"][!UpdateMeter "#CURRENTSECTION#"][!Redraw]
MouseScrollUpAction=[!SetVariable Range "(Clamp((#Range#+1),0,100))"][!UpdateMeter "#CURRENTSECTION#"][!Redraw]

Still for just three colors.

[Yincognito]

Didn't follow closely everything posted in this topic, but here is it:
Still for just three colors.

Yeah, the idea was to eliminate all the hardcoded values from the code (like 3 as the number of colors, 100 as the upper limit of your "Range" variable, etc.) and make everything configurable just by editing the variables in the [Variables] section. Like inputing the parameters to a program and let it run based on those parameters, without having to edit the code itself each time one of those parameters changed.

In other words, it wasn't necessarily about not having IfConditions per se, but about having the skin react automatically to the parameters and not needing subsequent editing of the code. It just happened that your IfConditions made used of hardcoded values (like -50; /50; R, G and B indexes in the form of 1, 2 and 3, that kind of things) so I mentioned them to make my idea easier to understand.

For example, in the code I posted here, one can just change the variables and the skin will run accordingly, without needing code adjustments based on the new values of those variables - I hope I'm clear in my explanation and you understand what I wanted. In that code, you can add or remove any number of colors, change the upper limit of what is "Range" in your code (I named your "Range" as "Value" and in my code "Range" became the upper limit of "Value", as it made more sense from a logical point of view) and no modification in the measures or meters is required.

I really don't know how to call this concept. Parametrization, or softcoding, maybe (that wiki article is a bit questionable though, as it implies softcoding to be a bad practice towards the end of it, just because some incompetent folks in some software companies can't code their products to avoid the increased maintenence due to softcoding - pfff).

[Yincognito]

Here is my adapted code for a Color Wheel transition. It behaves exactly like my "old" String based Color Wheel skin here, but it's MUCH more configurable. The only drawback, if I can call it this way, is the fact that it needed two measures instead of just one, but that's just because one cannot use the updated values of the changed variables inside the same option (i.e. same option bangs don't act based on their predecessors in the case of variables). I won't delete my old color transition code as I put some effort into it, but it's clear that it's superseeded by the new one and became pretty much obsolete. Thank you, brax64, balala and mak_kawa for making me improve my previous attempt.

The code:

Code: Select all

[Variables]
; Color 0
R0=255
G0=0
B0=0
A0=255
; Color 1
R1=255
G1=0
B1=255
A1=255
; Color 2
R2=0
G2=0
B2=255
A2=255
; Color 3
R3=0
G3=255
B3=255
A3=255
; Color 4
R4=0
G4=255
B4=0
A4=255
; Color 5
R5=255
G5=255
B5=0
A5=255
; Color 6
R6=255
G6=0
B6=0
A6=255
; The maximum of Value
Range=384
; A variable that ranges from 0 to Range
Value=0
; The maximum index of the colors used in the transition
IdMax=6
; The step by which Value changes
VStep=1

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

[Value]
Group=ColorGroup
Measure=Calc
Formula=((#Range#+Value+#VStep#)%#Range#)
OnUpdateAction=[!SetVariable Interval (([#Range]+1)/[#IdMax])][!SetVariable SIndex (Trunc([Value]/(([#Range]+1)/[#IdMax])))][!SetVariable EIndex (Trunc([Value]/(([#Range]+1)/[#IdMax]))+1)]
DynamicVariables=1

[Color]
Group=ColorGroup
Measure=Calc
OnUpdateAction=[!SetVariable R ([#R[#SIndex]]+(([Value]-[#SIndex]*[#Interval])/[#Interval])*([#R[#EIndex]]-[#R[#SIndex]]))][!SetVariable G ([#G[#SIndex]]+(([Value]-[#SIndex]*[#Interval])/[#Interval])*([#G[#EIndex]]-[#G[#SIndex]]))][!SetVariable B ([#B[#SIndex]]+(([Value]-[#SIndex]*[#Interval])/[#Interval])*([#B[#EIndex]]-[#B[#SIndex]]))][!SetVariable A "255"][!UpdateMeter "Image"][!Redraw]
DynamicVariables=1

---Meters---

[Image]
Meter=Image
SolidColor=#R#,#G#,#B#,#A#
X=0
Y=0
W=200
H=100
DynamicVariables=1
MouseScrollDownAction=[!SetVariable VStep -1][!UnpauseMeasureGroup ColorGroup][!UpdateMeasureGroup ColorGroup][!PauseMeasureGroup ColorGroup][!UpdateMeter "#CURRENTSECTION#"][!Redraw]
MouseScrollUpAction=[!SetVariable VStep 1][!UnpauseMeasureGroup ColorGroup][!UpdateMeasureGroup ColorGroup][!PauseMeasureGroup ColorGroup][!UpdateMeter "#CURRENTSECTION#"][!Redraw]
LeftMouseUpAction=[!UnpauseMeasureGroup ColorGroup][!ToggleMeasureGroup ColorGroup][!UpdateMeasureGroup ColorGroup][!UpdateMeter #CURRENTSECTION#][!Redraw]
MiddleMouseUpAction=[!TogglePauseMeasureGroup ColorGroup]
DynamicVariables=1

Preview:

ezgif.com-optimize (1).gif

The top rectangle is my old String based skin transition, and the bottom one is the current code. One can transition automatically by default, manually through scrolling, can "reset" things and start over on left click, or pause on middle click (I'm always reluctant to use the right click for anything in the case of a "one piece" skin in order to avoid having to press CTRL for the skin context menu).

P.S. I believe that the Value variable is not needed in this code anymore, as I only use the similarly named measure instead, but I let it there just in case.