Yincognito wrote: ↑January 29th, 2021, 1:09 pm
Haha, yes - I understand. I don't like even numbers, except those multiple of 10, obviously, and also use ---Measures---
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