New Shape Meter

[balala]

No problemo, we all miss the little details sometimes :P

Me for sure...

[Youkai1977]

I hope I can attach my question to this thread, because it's about SHAPE too.

What is or actually makes the difference between:

Code: Select all

Version1:
[Meter1]
Meter=Shape
Shape=Rectangle 0,0,100,100
X=10
Y=10

Version2:
[Meter2]
Meter=Shape
Shape=Rectangle 10,10,100,100
X=0
Y=0

Version3:
[Meter3]
Meter=Shape
Shape=Rectangle 0,0,100,100 | Offset 10,10
X=0
Y=0

In all 3 versions, the SHAPE lands on X & Y = 10

Ultimately, it is already clear to me what options you have by being able to specify the position of the SHAPE in 3 different ways.
However, this confuses me now under the premise that I am currently writing a 2x16 Band incl. 2x16 Delay visualizer.
And in order to save CODE or keep it as optimized as possible, what would be the best version for specifying coordinates?
The 16 bands left channel and 16 bands right channel should simply be next to each other.

Sorry if my question sounds a bit stupid right now, but with all the possibilities to program SHAPEs, I can't see the forest for the trees anymore

Here is a code excerpt as I currently have it:

Code: Select all

;--- DELAY-BAND LEFT & RIGHT BAND CHANNEL 01-16 ----

[DelayBand_LR]
Meter=Shape
X=10
Y=77
;--- LEFT DELAY-BAND ---
Shape=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 0,(#TBZeroLine#-[mBand15DBL]*#TBoverDB#)
Shape2=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 15,(#TBZeroLine#-[mBand14DBL]*#TBoverDB#)
Shape3=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 30,(#TBZeroLine#-[mBand13DBL]*#TBoverDB#)
Shape4=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 45,(#TBZeroLine#-[mBand12DBL]*#TBoverDB#)
Shape5=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 60,(#TBZeroLine#-[mBand11DBL]*#TBoverDB#)
Shape6=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 75,(#TBZeroLine#-[mBand10DBL]*#TBoverDB#)
Shape7=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 90,(#TBZeroLine#-[mBand9DBL]*#TBoverDB#)
Shape8=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 105,(#TBZeroLine#-[mBand8DBL]*#TBoverDB#)
Shape9=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 120,(#TBZeroLine#-[mBand7DBL]*#TBoverDB#)
Shape10=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 135,(#TBZeroLine#-[mBand6DBL]*#TBoverDB#)
Shape11=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 150,(#TBZeroLine#-[mBand5DBL]*#TBoverDB#)
Shape12=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 165,(#TBZeroLine#-[mBand4DBL]*#TBoverDB#)
Shape13=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 180,(#TBZeroLine#-[mBand3DBL]*#TBoverDB#)
Shape14=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 195,(#TBZeroLine#-[mBand2DBL]*#TBoverDB#)
Shape15=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 210,(#TBZeroLine#-[mBand1DBL]*#TBoverDB#)
Shape16=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 225,(#TBZeroLine#-[mBand0DBL]*#TBoverDB#)
;--- RIGHT DELAY-BAND ---
Shape17=Line 0,0,14,0 | StrokeWidth #TBStrokeW#| Stroke Color #TBStrokeColor# | Offset 305,(#TBZeroLine#-[mBand0DBR]*#TBOverDB#)
Shape18=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 320,(#TBZeroLine#-[mBand1DBR]*#TBoverDB#)
Shape19=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 335,(#TBZeroLine#-[mBand2DBR]*#TBoverDB#)
Shape20=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 350,(#TBZeroLine#-[mBand3DBR]*#TBoverDB#)
Shape21=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 365,(#TBZeroLine#-[mBand4DBR]*#TBoverDB#)
Shape22=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 380,(#TBZeroLine#-[mBand5DBR]*#TBoverDB#)
Shape23=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 395,(#TBZeroLine#-[mBand6DBR]*#TBoverDB#)
Shape24=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 410,(#TBZeroLine#-[mBand7DBR]*#TBoverDB#)
Shape25=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 425,(#TBZeroLine#-[mBand8DBR]*#TBoverDB#)
Shape26=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 440,(#TBZeroLine#-[mBand9DBR]*#TBoverDB#)
Shape27=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 455,(#TBZeroLine#-[mBand10DBR]*#TBoverDB#)
Shape28=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 470,(#TBZeroLine#-[mBand11DBR]*#TBoverDB#)
Shape29=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 485,(#TBZeroLine#-[mBand12DBR]*#TBoverDB#)
Shape30=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 500,(#TBZeroLine#-[mBand13DBR]*#TBoverDB#)
Shape31=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 515,(#TBZeroLine#-[mBand14DBR]*#TBoverDB#)
Shape32=Line 0,0,14,0 | StrokeWidth #TBStrokeW# | Stroke Color #TBStrokeColor# | Offset 530,(#TBZeroLine#-[mBand15DBR]*#TBoverDB#)
DynamicVariables=1

;--- DOWN-BAND LEFT & RIGHT BAND CHANNEL 01-16 -----

[DownBand_LR]
Meter=Shape
X=r
Y=r
;--- LEFT DOWN-BAND ---
Shape=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand15MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 0,0
Shape2=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand14MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 15,0
Shape3=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand13MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 30,0
Shape4=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand12MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 45,0
Shape5=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand11MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 60,0
Shape6=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand10MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 75,0
Shape7=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand9MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 90,0
Shape8=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand8MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 105,0
Shape9=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand7MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 120,0
Shape10=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand6MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 135,0
Shape11=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand5MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 150,0
Shape12=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand4MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 165,0
Shape13=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand3MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 180,0
Shape14=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand2MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 195,0
Shape15=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand1MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 210,0
Shape16=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand0MBL])) | Fill LinearGradient RGBLGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 225,0
;--- RIGHT DOWN-BAND ---
Shape17=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand0MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 305,0
Shape18=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand1MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 320,0
Shape19=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand2MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 335,0
Shape20=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand3MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 350,0
Shape21=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand4MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 365,0
Shape22=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand5MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 380,0
Shape23=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand6MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 395,0
Shape24=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand7MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 410,0
Shape25=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand8MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 425,0
Shape26=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand9MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 440,0
Shape27=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand10MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 455,0
Shape28=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand11MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 470,0
Shape29=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand12MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 485,0 
Shape30=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand13MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 500,0
Shape31=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand14MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 515,0
Shape32=Rectangle 0,0,14,(#DBZeroLine#-(#DBHigh#*[mBand15MBR])) | Fill LinearGradient RGBRGradient | StrokeWidth #DBStrokeW# | Stroke Color #DBStrokeColor# | Offset 530,0 
Shape33=Combine Shape16 | Union Shape15 | Union Shape14 | Union Shape13 | Union Shape12 | Union Shape11 | Union Shape10 | Union Shape9 | Union Shape8 | Union Shape7 | Union Shape6 | Union Shape5 | Union Shape4 | Union Shape3 | Union Shape2 | Union Shape
Shape34=Combine Shape17 | Union Shape18 | Union Shape19 | Union Shape20 | Union Shape21 | Union Shape22 | Union Shape23 | Union Shape24 | Union Shape25 | Union Shape26 | Union Shape27 | Union Shape28 | Union Shape29 | Union Shape30 | Union Shape31 | Union Shape32
RGBLGradient=#RGBLDegree# | #RGBColor1LR# ; 0.0 | #RGBColor2LR# ; 0.333 | #RGBColor3LR# ; 0.666 | #RGBColor4LR# ; 1.0
RGBRGradient=#RGBRDegree# | #RGBColor1LR# ; 0.0 | #RGBColor2LR# ; 0.333 | #RGBColor3LR# ; 0.666 | #RGBColor4LR# ; 1.0
DynamicVariables=1

[balala]

In all 3 versions, the SHAPE lands on X & Y = 10

Well yes and no. In all three you see the shape on the same position, however the meters themselvs have different positions. At least [Meter1], against [Meter2] and [Meter3] (the last two are same positioned). You can see the difference with a simple String meter, something like this:

Code: Select all

[Uptime]
Meter=STRING
X=0
Y=0
Padding=15,5,15,5
FontColor=220,220,220
FontEffectColor=0,0,0
StringEffect=Shadow
SolidColor=0,0,0,150
FontSize=8
FontFace=Segoe UI
StringStyle=BOLD
StringAlign=LEFT
AntiAlias=1
Text=Meter1: [Meter1:X] / [Meter1:Y]#CRLF#Meter2: [Meter2:X] / [Meter2:Y]#CRLF#Meter3: [Meter3:X] / [Meter3:Y]
DynamicVariables=1

See that the position of [Meter1] is X=10 and Y=10, while the coordinates of the second and third meters are X=0 and Y=0.
I think there is no such thing as the best solution (version). Which one do you prefer, is a question of personal preferince, none of them is better than any other in my opinion. It's completely up to the author of the code which one does he/she use.

[Youkai1977]

I think there is no such thing as the best solution (version). Which one do you prefer, is a question of personal preferince, none of them is better than any other in my opinion. It's completely up to the author of the code which one does he/she use.

Ok, I thought to myself that there is no optimal or better way here. So it is ultimately a matter of taste for the author.
Then I think that, as far as my visualizer is concerned, the version posted here is probably okay without the experts falling from their chairs laughing when they see what I've got there.

I'm slowly noticing again, now that after more than a year I'm working more intensively with Rainmeter, as I'm currently modifying / adding to my skins, how Rainmeter is really simple and partly self-explanatory in some things. Even if, as in my case, there is a language barrier.

In other things, on the other hand, they are so (at least that's how I think) so extensive or there are so many ways to achieve the same result that I sometimes think it's easier to do a doctorate in Chinese.

A simple example for "many ways = same destination":

Code: Select all

1= (#DBZeroLine#-(#DBHigh#*[mBand15MBL]))
2= (#DBZeroLine#-([mBand15MBL]*#DBHigh#))
3= (#DBZeroLine#-#DBHigh#*[mBand15MBL]) 
4= (#DBZeroLine#-[mBand15MBL]*#DBHigh#)

And like in my example, I'm doing many things with Rainmeter ... where depending on the case, we would probably be back to the author's taste.

[balala]

Ok, I thought to myself that there is no optimal or better way here. So it is ultimately a matter of taste for the author.

Exactly.

without the experts falling from their chairs laughing when they see what I've got there.

NO ONE never laugh of you or any other author, I hope. The purpose of this forum is exactly to help each other to find the best possible solution in different circumstances. Don't worry, we are not laughing at all.

In other things, on the other hand, they are so (at least that's how I think) so extensive or there are so many ways to achieve the same result that I sometimes think it's easier to do a doctorate in Chinese.

There definitely are many way to do the same thing. This is one of the beauties of Rainmeter, in my opinion.

[Youkai1977]

Because of the different ways, I only asked because I thought that it could e.g. optimize the CPU load, depending on how you try to achieve your goal when writing the skin.
Especially with skins like my 2x16Band, plus 2x16 Delay-Band Visualizer, which I'm currently writing.
I think that one or the other formula or syntax might be better than another. Because with one of "Update = 32" for the skin and then a total of 64 measures, plus 4 measures for the RGB color calculation, things can get tight for the CPU. At least with my old PC key (AMD A10-7850K 4 cores). That's up to my visualizer, when it runs at a total load of 18-40% and runs at high speed.

Where we would be laughing at my comment. It wasn't meant to be mean or derogatory. It was meant rather casually if I would open a thread here, for example, because my visualizer was blowing up the CPU, and if a specialist would then see my code here, then just clap their hands over the head because I, for example, complicate the Skin, and then I don't have to wonder if a skin is CPU-heavy.

Anyway, all in all I feel very well cared for here in the forum. Even if I always have to translate everything first.
The help here so far has always been great and "above all" quick

[Yincognito]

Because of the different ways, I only asked because I thought that it could e.g. optimize the CPU load, depending on how you try to achieve your goal when writing the skin.
Especially with skins like my 2x16Band, plus 2x16 Delay-Band Visualizer, which I'm currently writing.
I think that one or the other formula or syntax might be better than another. Because with one of "Update = 32" for the skin and then a total of 64 measures, plus 4 measures for the RGB color calculation, things can get tight for the CPU. At least with my old PC key (AMD A10-7850K 4 cores). That's up to my visualizer, when it runs at a total load of 18-40% and runs at high speed.

If you want to optimize meters, you could have it all (or almost all) in a single meter of type Shape->Path. It would be all about formulas there.
If you want to optimize measures in a visualizer, you should make sure that the various values set on the options of the AudioLevel measures in the visualizer skin are reasonable (the manual mentions which options have an impact on the CPU). Also, that the number of AudioLevel parent measures in the visualizer skin is preferably as low as possible (e.g. 1 or maximum 2).

An update rate of 50 ms is generally enough for a visualizer. A visualizer will take some CPU anyway because it uses both OS resources and does some math behind the scenes, so the rest of the code and the external environment should be as light as possible.

[Youkai1977]

Ok, so far I've oriented myself to the visualizers that can be found on the net. Especially when it came to the update rate. This is often 0 or 16.
I've already set mine to 32. But 50 or more ?!

Well, I teach myself to write the skin by looking, copying and testing it. Then there will be times (1 year or longer) when I don't do anything with Rainmeter and have forgotten a lot.

I have added my visualizer, which is almost finished, to this answer.
If you like, you can take a look at the code to see what could be optimized. And if you like, you can also use the visualizer for yourself.

Note: This is a visualizer, which I found ages ago at DeviantArt, and which was originally based on "Meter=Bar" and 2x24Band, with Update=0.

In the meantime I have modified it many times.
1.) From 2x24 to 2x16 tape
2.) Then 2x16 delay tape added
3.) The RGB Measure Calc changed
4.) Miscellaneous ...

The current and last major change was that the Visualizer is now based on "SHAPE"

[Yincognito]

Ok, so far I've oriented myself to the visualizers that can be found on the net. Especially when it came to the update rate. This is often 0 or 16.
I've already set mine to 32. But 50 or more ?!

Well, visually, for the human eye, there isn't much difference between updating once every 32 ms or once every 50 ms. However, for the CPU there is, at least in my case:
- for 32 ms, the CPU usage is 6.65% on average over 1 minute
- for 50 ms, the CPU usage is 1.39% on average over 1 minute
Note: these percentages vary from measurement to measurement, but the percentage ratio between the 2 update settings stays largely the same.

Point is, those tiny milliseconds really matter for the CPU - the difference from updating your skin every 50 ms to updating every 32 ms is a whopping 400% increase in the CPU usage. Now, for better computers or lighter environments it won't matter so much, but since you mentioned optimization, these are the results...

In the end, it's up to you and your usage scenario which choice you make - you're the author and you know best.

P.S. Personally, I wouldn't consider the update rate of most internet visualizers as a rule or as something worth taking into account. Most visualizers on the internet are more about nice visuals than optimization.

[Youkai1977]

What they say makes perfect sense. Especially on old PC systems like mine. I have now set my visualizer to Update = 48 high.
For me this is just the pain threshold or a good compromise for my merciless eye and torment my CPU.
With the 48 update, my average CPU load drops from 22-40% to 10-25%.
And even the clock goes down from 4.1GHz to 1.70Ghz in between.
I didn't have that with the 32 update.

However, if I go to a 50 or 64 update, my merciless eye will scold me. Because then I can already see significant delays in rendering the individual bars. Then works like a jerk in games where there are too few FPS per second.

In addition, my entire skin is written in such a way that the visualizer deactivates itself when it is not needed. In other words, it only works for me when I call up YouTube in my browser. So controlled by the WebNowPlaying.dll

So I think I have a good compromise for my old system and good graphics for the visualizer.
And if I should make my entire skin available to other users (if it is ever finished), everyone can change the timing as they wish.

What do you say about my visualizer, insofar as you have tried it?
Useful? Can be optimized?