Visualizer settings makes visualizer disappear

[AnryuKen]

I'm completely new to Rainmeter, just started playing with it yesterday. I tried using Ocean and Frost audio visualizer and at first, they're fine until I tried to tinker with the settings. I wanted to adjust its width so that it is longer, however, upon clicking the supposed slider, it instantly changes the values to -1 and makes the visualizer disappear. I can edit the values in the code but the visualizer is still gone. The only way for me to get it back is to reinstall it.

Since editing the values from the code itself doesn't work, is there a way to fix this problem? I also tried a few other visualizers such as Visbubble and it worked alright but the one I want to use for a specific layout is either Ocean or Frost.

Another followup question, when I tried duplicating Ocean to have another visualizer, the settings to change how the duplicate looks affects the original (i.e. When I duplicated Ocean, the box for "Line Only" for the duplicate changes the original instead of the duplicate). Is there a way to fix this problem?

[eclectic-tech]

Those skins have not been updated in several years to work with Rainmeter.

To get the visualizers working again you need to manually edit the settings in a text editor, save them, and then run 'GenerateBands.ini' to correct the files that "-1" setting corrupted.

As long as you never use the settings skin, you shouldn't have to manually generate bands again.

EDIT: To 'copy' a skin, you need to place it in a new folder. But depending on how the skin is coded, it may also require other editing of the code to match the new location.

[AnryuKen]

Those skins have not been updated in several years to work with Rainmeter.

To get the visualizers working again you need to manually edit the settings in a text editor, save them, and then run 'GenerateBands.ini' to correct the files that "-1" setting corrupted.

As long as you never use the settings skin, you shouldn't have to manually generate bands again.

EDIT: To 'copy' a skin, you need to place it in a new folder. But depending on how the skin is coded, it may also require other editing of the code to match the new location.

Thanks! I was able to change the width and height of the visualizers. But there's this slight problem that's bothering me a bit, the visualizer cuts off at the top as if something is blocking it, is there a way to fix this?

Also this is how I copied Ocean: I went in Rainmeter skins and made a copy of Ocean and named it Ocean 2. At first, the problem where I the settings of the copy affect the original occured so I decided to delete the original Ocean folder and keep Ocean 2 (idk why, just felt like it lol). Afterwards, I made a copy of Ocean 2 and named it Ocean 3, somehow both of their settings are now working independently which is good. However, I kind of wanted to play with it a little more and made a 3rd copy (Ocean 4), the problem occured once again.

I wanted to experiment on having the visualizer upside down, I saw that the Clone 1 folder inside the Oceans' folders contains a "clone.ini" (in this instance, I used the clone.ini in Ocean 4) which is an upside-down version of the visualizer. However, upon changing its settings, it changes the original visualizers instead of the Clone. Is there a way to change the settings of the clone.ini?

[Mor3bane]

I hope I do not come off rude.

But those skins were designed to be difficult to edit - one thing depends on another and several times over this remains true.

I also tried editing those skins, and being a relatively simple user, came up with some ways to mitigate that. But in the end wound up with a skin that would inevitable freeze and a manual refresh was required.

Even though my edits were what I wanted.

eclectic-tech also helped me with those edits, but the less and less occurring freezing was mostly mitigated, I dumped the project since most if not all visualisers are system resource hogs, and my system rarely sits at idle whilst music is playing so the resource 'drains' were not acceptable, thus just not needing a visualiser became my final preference.

[Yincognito]

I dumped the project since most if not all visualisers are system resource hogs, and my system rarely sits at idle whilst music is playing so the resource 'drains' were not acceptable, thus just not needing a visualiser became my final preference.

A bit unrelated to this, but while this is generally true, a lot has to do with how the code is written in those visualizers (or the other active skins, for that matter). Speaking from personal experience, I used to think that my visualizer skin was the culprit for higher CPU usage when dealing with other programs in the meantime, until I found out that the issue was totally unrelated. This erroneous concern had a positive though: I optimized the visualizer's skin code as much as I could, applying one of eclectic-tech advice (or ActiveColors', maybe) of having just one AudioLevel parent per machine. The result after fixing and optimizing everything in both the visualizer and my other skins was more than satisfactory.

[Mor3bane]

A bit unrelated to this, but while this is generally true, a lot has to do with how the code is written in those visualizers (or the other active skins, for that matter). Speaking from personal experience, I used to think that my visualizer skin was the culprit for higher CPU usage when dealing with other programs in the meantime, until I found out that the issue was totally unrelated. This erroneous concern had a positive though: I optimized the visualizer's skin code as much as I could, applying one of eclectic-tech advice (or ActiveColors', maybe) of having just one AudioLevel parent per machine. The result after fixing and optimizing everything in both the visualizer and my other skins was more than satisfactory.

Agreed. I totally see it that way as well, and multiple audio level skins or instances is and was a culprit I identified as well, however given that was changed to suit - I found rainmeter lagging and building up some kind of pointer backlog and that inevitably caused more grief than was worth following through to get those things tidied up. I also have to be honest, my rainmeter is running in excess (I havent counted in a wile.. ok I'll count them now...) 54 skins. SO blaaaaargh! Visualisers arent a priority.

[Yincognito]

Agreed. I totally see it that way as well, and multiple audio level skins or instances is and was a culprit I identified as well, however given that was changed to suit - I found rainmeter lagging and building up some kind of pointer backlog and that inevitably caused more grief than was worth following through to get those things tidied up. I also have to be honest, my rainmeter is running in excess (I havent counted in a wile.. ok I'll count them now...) 54 skins. SO blaaaaargh! Visualisers arent a priority.

Wow, 54 skins! And I thought my 15+ was a bit too many...

Yeah, it's quite difficult when some skins are not easily editable or adjustable. Some of the more complex skins are like that, indeed.

[mak_kawa]

Hi Yincognito and Mor3bane

I have 55 skins at work in my Rainmeter. 29 skins are always and continuously working, and the rest 26 skins are launched as the need arises.

My happy surprise is... Rainmeter doesn't consume a lot of CPU process, it is about 1.9 - 3.2 %, sometimes 6 - 7 %, even with numerous redundant IfConditionMode=1 and DynamicVariables=1 inserted as my too cautious "insurance".

BTW, recently I noticed that Rainmeter sometimes uses private memory more than 500 MB, up to 2 GB (!!). No need to worry, it is caused by my slideshow skin showing randomly 9 photos simultaneously, really crazy skin...

[Yincognito]

Hi Yincognito and Mor3bane

I have 55 skins at work in my Rainmeter. 29 skins are always and continuously working, and the rest 26 skins are launched as the need arises.

My happy surprise is... Rainmeter doesn't consume a lot of CPU process, it is about 1.9 - 3.2 %, sometimes 6 - 7 %, even with numerous redundant IfConditionMode=1 and DynamicVariables=1 inserted as my too cautious "insurance".

BTW, recently I noticed that Rainmeter sometimes uses private memory more than 500 MB, up to 2 GB (!!). No need to worry, it is caused by my slideshow skin showing randomly 9 photos simultaneously, really crazy skin...

Ouch! Curious though ... 1.9 - 3.2 % or 6 - 7 % of what CPU frequency? These percents mean nothing if there isn't a reference CPU frequency alongside it - for example, 2 % of my old 2.3 GHz CPU (active frequency) might be 1.25 % on a newer 3.5 GHz CPU. That's something I noticed due to Rainmeter, actually - lways on top monitoring has its benefits, as you learn things along the way.

[mak_kawa]

Hi Yincognito

Oh really...?! I didn't know that process% depends on CPU frequency... shame.

My CPU is, as wrote somewhere, really old and obsolete Sandy Bridge i7, its frequency is 1.6 - 3.5 GHz. And... memory is DDR3-1333!!. I am eager for new generation CPU and memory, but... money & effort?!

BTW, 6-7% process value appears when multiple RunCommand are launched to get Exif data from photo... probably because of my "non-optimized" measure structure.