New Shape Meter

[Yincognito]

What they say makes perfect sense. Especially on old PC systems like mine. I have now set my visualizer to Update = 48 high.
[...]
So I think I have a good compromise for my old system and good graphics for the visualizer.

Ah, so you like the update to be a multiple of 16... That's fine, no worries. If you're happy with how it works, all good - after all, it's this kind of compromise I was talking about as well (i.e. a reasonable balance between visuals and efficiency).

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

Yes, I tried it, and I actually like it - nice job with the delays, the colors and the fading, you managed to do all that in a simple and effective way. As for further optimization, I don't think there is more that can be done, in the skin's current format. I mean, in theory you could use a single AudioLevel parent measure, try to tweak some of the options (e.g. disable either RMS or Peak filtering if you don't use one of them, like in the notes here and here) or selectively disable measures/meters when/if you don't use them, but then, most of these things might have a role in the envisioned functioning of the skin the way you want it, so in practice it might not be desirable (for example, you need the 2nd AudioLevel parent measure for the delays, etc). You could also set an UpdateDivider on the Win7AudioPlugin (and its associate) measure(s), as in my experience this also helps in reducing the CPU usage.

That being said, the CPU usage is still higher than it could be - and even on idle, which is not exactly comfortable. I might take another look at it tomorrow to see if things can be improved in that regard.

[Youkai1977]

Ah, so you like the update to be a multiple of 16... That's fine, no worries. If you're happy with how it works, all good - after all, it's this kind of compromise I was talking about as well (i.e. a reasonable balance between visuals and efficiency).

Yup, I'm a friend of balance. I don't like odd numbers. I hate it when I have to enter crooked numbers in the X, Y coordinates.
But especially with things like update rates, I think that's efficient.
Ok, I am not a CPU now, which I think does not matter whether the "45.275 : 2.13" has to calculate, or "40 : 2"

But you can also see how I set up my skins and provide them with information (; --- Measure Bla Bla ---).
I need it to be clear. Especially with larger skins.
That's why a lot of things at Rainmeter are somehow ... well, how should I put it. When I look at some syntax, I get eye problems and only understand train station

Yes, I tried it, and I actually like it - nice job with the delays, the colors and the fading, you managed to do all that in a simple and effective way. As for further optimization, I don't think there is more that can be done, in the skin's current format. I mean, in theory you could use a single AudioLevel parent measure, try to tweak some of the options (e.g. disable either RMS or Peak filtering if you don't use one of them, like in the notes here and here) or selectively disable measures/meters when/if you don't use them, but then, most of these things might have a role in the envisioned functioning of the skin the way you want it, so in practice it might not be desirable (for example, you need the 2nd AudioLevel parent measure for the delays, etc). You could also set an UpdateDivider on the Win7AudioPlugin (and its associate) measure(s), as in my experience this also helps in reducing the CPU usage.

That being said, the CPU usage is still higher than it could be - and even on idle, which is not exactly comfortable. I might take another look at it tomorrow to see if things can be improved in that regard.

Glad to hear that you like my visualizer.
Yes, I'm particularly proud of the RGB function and the resulting look.
With techno, for example, the rainbow goes off. Where, on the other hand, with calm music the colors come across correspondingly softer.
In short, with my visualizer you can not only hear the music, you can also see it.

As for the removal of certain values ​​such as RMS, I had them out, but only put them back in yesterday because I found many skins from the Internet, where it is (almost) everywhere.
Even if I, I think I have read that, for example, the RMS values ​​are only needed if you are making a simple VU meter.

However, you are of course welcome to take a look at what could be optimized / deactivated / removed / paused without actually having a loss in appearance and function, but saving a little bit of CPU performance.

But now I'm going to bed first. Here in Germany it's just 3:11 a.m.

[balala]

Especially when it came to the update rate. This is often 0 or 16.

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.

Update can't be 0. Its lowest possible value is 16. If you're setting it below 16, Rainmeter uses 16 for it: https://forum.rainmeter.net/viewtopic.php?f=4&t=36699&p=187618&p187616#p187616

[Yincognito]

I don't like odd numbers. I hate it when I have to enter crooked numbers in the X, Y coordinates.

Haha, yes - I understand. I don't like even numbers, except those multiple of 10, obviously, and also use ---Measures--- and ---Meters--- marker lines to order and clarify my code. And yes, I get headaches too when looking at messy code...

However, you are of course welcome to take a look at what could be optimized / deactivated / removed / paused without actually having a loss in appearance and function, but saving a little bit of CPU performance.

Yep, thing is, like I said, that most of those changes I talked about do actually cause a loss in appearance and function, so they are out of the question. What you can do though, is add an UpdateDivider of, say, 20, to [mWin7Audio] and [mAADD], so that they are updated once every second instead of once every 48 ms (this reduced the CPU usage to half in my tests). Yes, there will be a small delay in the skin reacting to changes in audio volume, but it's reasonable, IMHO - after all, one doesn't change the volume so often, or when he does, he usually changes the player volume instead of the audio device volume (Win7AudioPlugin is only reacting to the audio device volume, so the skin reacting to the player volume won't be affected).

Actually, after some testing on my system, the skin is not affected at all by output device volume changes, not even on muting, so if you don't use the measures for changing the volume from the skin (say, on mouse scrolling) you can very well get rid of the 2 measures altogether. Since we're at it, if we talk about the device volume, you have a mistake in the code - [mAADD] should use String=[mWin7Audio:] in order to get the numerical value of [mWin7Audio]. Of course, if you use the measures to detect when the device changed to another one (I'm not sure of that, you know best what you wanted to achieve there), then the way you wrote the code is fine, and the above isn't a mistake, but reacts to the device name instead of its volume. Anyway, you can operate the UpdateDivider change either way - the actual value you give it is your choice, of course.

After making the change suggested above, the CPU usage is closer to what it should be. I use my related skin as a comparison, because I also spent quite a bit of time trying to optimize it to the maximum.

[Youkai1977]

Haha, yes - I understand. I don't like even numbers, except those multiple of 10, obviously, and also use ---Measures--- and ---Meters--- marker lines to order and clarify my code. And yes, I get headaches too when looking at messy code...

I see we speak almost the same language. At least when it comes to the Synatx in Rainmeter.

Currently I'm in the process of completely rebuilding my old SKIN "M.A.R.S.-Terminal" from 2018 (to be found here in the forum). Not only do I try to replace many graphics with SHAPE thanks to SHAPE. no, I write the code of the individual meters in such a way (at least I'm trying to do it) that later all the individual meters that make up the entire skin, e.g. if possible, all access a Variable.inc. Thus, for the sake of clarity, the [variables] part in the individual meters is then omitted. What also has the advantage of changing a variable, this change has a direct effect on all individual meters. With little work, a skin can be quickly changed or corrected later.
Since my skin, which you know here from the forum, has already undergone some changes such as extensions on my PC in the last 2 years, the current conversion is about as complicated as trying to renovate an old building. I think sometimes tearing it down and rewriting it would have been faster.

However, for me there is also real life and family, which despite all my love for Rainmeter have priority for me. So just the side note on my part, should the forum suddenly hear nothing from me for months ... Family is calling ...

Yep, thing is, like I said, that most of those changes I talked about do actually cause a loss in appearance and function, so they are out of the question. What you can do though, is add an UpdateDivider of, say, 20, to [mWin7Audio] and [mAADD], so that they are updated once every second instead of once every 48 ms (this reduced the CPU usage to half in my tests). Yes, there will be a small delay in the skin reacting to changes in audio volume, but it's reasonable, IMHO - after all, one doesn't change the volume so often, or when he does, he usually changes the player volume instead of the audio device volume (Win7AudioPlugin is only reacting to the audio device volume, so the skin reacting to the player volume won't be affected).

Actually, after some testing on my system, the skin is not affected at all by output device volume changes, not even on muting, so if you don't use the measures for changing the volume from the skin (say, on mouse scrolling) you can very well get rid of the 2 measures altogether. Since we're at it, if we talk about the device volume, you have a mistake in the code - [mAADD] should use String=[mWin7Audio:] in order to get the numerical value of [mWin7Audio]. Of course, if you use the measures to detect when the device changed to another one (I'm not sure of that, you know best what you wanted to achieve there), then the way you wrote the code is fine, and the above isn't a mistake, but reacts to the device name instead of its volume. Anyway, you can operate the UpdateDivider change either way - the actual value you give it is your choice, of course.

After making the change suggested above, the CPU usage is closer to what it should be. I use my related skin as a comparison, because I also spent quite a bit of time trying to optimize it to the maximum.

As far as the update divider is concerned, especially for the [mAADD] measure, yes, I can see if I can set that high.
I wasn't aware that it could cause so much CPU load because it should only monitor when I switch the audio output.
But good to know, I'll implement that.

Otherwise, as you suggested, I don't have to change the [mAADD], because it is not used for volume, but only for monitoring which audio output is used.
Because that is a focus of my PC system, which will later be found in the finished SKIN. The audio part.
In my system work a total of 5 sound cards or possibilities to redirect / output the sound.
- Internal APU graphics (HDMI)
- External graphics (HDMI)
- Internal sound card (Realtek analog and digital, as well as front-out & mic)
- Decent sound card (Asus D2x Xonar (analog & digital))
- TurtleBeach USB headset

And even if Windows itself is quite comfortable with audio management, nothing beats a beautifully written meter / skin with which this can be done.

And therefore also the [mAADD] in my visualizer. If I switch the audio output while the visualizer is active, I always had to update the visualizer afterwards, otherwise it would no longer respond.
So back then I was looking for a solution and found it where else * laugh * here in the forum. In the form of the [mAADD] measure

By the way, the Visualizer reacts to volume changes on my system. It doesn't matter whether I change the YT player (webNowPlaying) or the YT (website) itself

[Youkai1977]

Update can't be 0. Its lowest possible value is 16. If you're setting it below 16, Rainmeter uses 16 for it: https://forum.rainmeter.net/viewtopic.php?f=4&t=36699&p=187618&p187616#p187616

I know that an update = 0 does not work, and 16 is the minimum.
Thanks to this forum I came to this knowledge some time ago.

But that does not rule out that I found Visualizer or VU - Skins on the Internet that still had it at 0.

[Yincognito]

I see we speak almost the same language. At least when it comes to the syntax in Rainmeter.

Currently I'm in the process of completely rebuilding my old SKIN "M.A.R.S.-Terminal" from 2018 (to be found here in the forum). [...] What also has the advantage of changing a variable, this change has a direct effect on all individual meters. With little work, a skin can be quickly changed or corrected later.
Since my skin, which you know here from the forum, has already undergone some changes such as extensions on my PC in the last 2 years, the current conversion is about as complicated as trying to renovate an old building. I think sometimes tearing it down and rewriting it would have been faster.

Yep, and you can add the use of [Variables] to create adjustable skins where everything can be tweaked just by changing a few variables to "speaking the same language" as well, I'm a fan of that. I've been through the process of rewriting a skin suite, and I couldn't agree more with the feeling. Luckily I eventually completed my upgrade a couple of months ago, so don't worry, you'll get it done sooner or later - and it will feel good then.

I wasn't aware that it could cause so much CPU load because it should only monitor when I switch the audio output.

I wasn't aware of it either, until I built my audio skin in the last upgrade I mentioned. I kept looking for ways to optimize things in the AudioLevel measures, until I found that a good deal of CPU usage was being eaten by fast updating the Win7AudioPlugin measures as well. It was a surprise, but it made sense, and the fix was easy and acceptable.

If I switch the audio output while the visualizer is active, I always had to update the visualizer afterwards, otherwise it would no longer respond. So back then I was looking for a solution and found it where else * laugh * here in the forum. In the form of the [mAADD] measure

Unfortunately, I don't have multiple (usable) audio outputs, so I can't have a say on this. I am aware though of the fact that AudioLevel parent measures are stuck with the device and port that is initially used in the skin code, not to mention they don't support dynamic variables. This is probably the cause that an update of those values always require a skin refresh.

[balala]

I know that an update = 0 does not work, and 16 is the minimum.
Thanks to this forum I came to this knowledge some time ago.

But that does not rule out that I found Visualizer or VU - Skins on the Internet that still had it at 0.

Yep, I also have seen this many times. But it still is a mistake, which gets correceted by rainmeter, which applies the lowest Update=16 possible in such cases.

[Youkai1977]

Yes, rewriting a complete skin suite is very time-consuming. I've noticed that every time so far. But this time I'm also optimizing on the side. Like the already mentioned [Variables] part. This is really really really time-consuming. A small mistake and the result can be fatal if several individual skins are dependent on the same [Variables] section.

But well, no matter how long it takes, Rainmeter is a hobby, and when you're done, it turns out like they said ... it feels good.

What is still difficult for me is to write my skins in such a way that they can be used by the Rainmeter community without major restrictions or adjustments if I intend to share my creations.
Not so much for individual skins / meters, but for complete suites ...
I haven't succeeded in doing so yet. Therefore, I always first concentrate on making sure that it fits my PC.
Especially because my skin suite runs on an old monitor (secondary screen) with just 1440x900 pixels. This screen is only there for the display of the skin suite mentioned, while my primary screen (my 50" UHD TV) shows me purely the Windows desktop. I don't want anything from Rainmeter to run on it.
And already we have a major scaling problem. Two screens with such different resolutions. Even the most impossible coordinate information comes around in Rainmeter when you slide the individual meters / skins or even the entire suite onto the secondary screen.
As I said, as long as it works ONLY on my PC, everything is fine, but if I do not share a complete suite, I upload it here as a finished * .rmskin file


To the other, the [mAADD] ...
I set the UpdateDivider to 20.
And as you said before, the CPU load drops enormously.
I am now at 4-17% without any real loss.
Whereby 17% are only short-term peaks. The cut is 8-12%
This is the simplest and yet best optimization that my visualizer could experience

Unfortunately, I don't have multiple (usable) audio outputs, so I can't have a say on this. I am aware though of the fact that AudioLevel parent measures are stuck with the device and port that is initially used in the skin code, not to mention they don't support dynamic variables. This is probably the cause that an update of those values always require a skin refresh.

Okay, if you don't have multiple audio outputs, you don't have to worry about this.

But that quickly became a problem for me.
I don't use all audio outputs either, mainly 3 ...
- Dedicated graphics card (HDMI to the primary screen (TV)
- Asus D2x Xonar (SPDIF for home theater)
- Combines TurtleBeach11 USB headset (analog looped through sound of the Xonar D2x and via USB the micro)

... but at least. Switch that every time with Windows board tools, you get the crisis.
Rainmeter was right for me.

[Youkai1977]

Yep, I also have seen this many times. But it still is a mistake, which gets correceted by rainmeter, which applies the lowest Update=16 possible in such cases.

Well, regarding errors in (my) skins / meters, I better keep myself closed. I'm pretty good at this too.
But you're right, you should avoid it, even if Rainmeter can to a certain extent do the same