Reusing and changing skins without changing its previous appearance in a layout

[balala]

fountain of colors has a option to duplicate it self many times ... if all loaded could give a overload...
if it's only one or two will give not a overload...

General recommendation is not to use more than one visualizer skin, no matter which one are those. Not recommended to load more instances of Fountain of Colors at a time. They'll overload the processor.

[Yincognito]

Yes, but that's any extreme case. Usually most skins aren't so large.

True that, but then I had no idea what skins the OP installed, so I mentioned the disk space just in case it was a concern. Probably not, as you pointed out, but a side of the problem nevertheless, at least in theory.

[CodeCode]

The fountain of colors skin's duplicate feature is somewhat 'bloaty' and the variant method like Yincognito suggested is the simplest NB as long as the variation in settings does not affect the major features like how many bars or if there are any custom effects on the bars (some recent folk have been doing this).
The the Layout can just load the variant blindly and happily according to the Rainmeter.ini like Jsmorley has been clarifying on.

The variant 'main.ini' would of course need a new name which is minimally impactful in a barely worth mentioning kind of way.

[AnryuKen]

Beside dvo's reply I think that duplicating the config is the only solution. For instance rename the Skins\Fountain of Colors config to Fountain of Colors Red, create a new config and rename it to Fountain of Colors Blue. Make the appropriate settings on both. Now you have to include one of this configs into the first layout and the the other into the second layout. Whenever are you loading any of these layouts, the appropriate config will be loaded.
Try out this solution if you are interested and let me know if it does work. I'm not sure it will, but maybe worth a try.

So I experimented again and found a problem. I tried to get a 3rd one which is I guess a huge mistake, anyways, long story short, I can't edit the variables, more specifically the angle.

I can't edit it in both the options and by editing the variables manually in the code. And it seems it also happened in the original one too.

I did try to load 2 at one point to see if the settings of the duplicate would affect the original. At this point, I had 3 (RED, BLUE, WHITE), I loaded BLUE and WHITE to see if they'd affect each other and Rainmeter's performance dropped devastatingly, I can use other programs fine but Rainmeter was just loading so slow - it felt like I had a potato pc (I kind of do compared to avg PCs lol but Rainmeter worked perfectly fine before, this is a first). I deleted BLUE because I didn't necessarily need it and experimented on RED and WHITE. At first they were working independently fine, but the problem I mentioned above occurred - I can't change some variables of for both types.

[CodeCode]

Possibly a visualiser alternative that is still appealing but not as resource demanding.

I found Monstercat more flexible, and at one point had two running just fine.

Monstercat is also a smaller group of files and no lua iirc.

But, it has less options but there is an angle setting although I might be remembering incorrectly.

[Yincognito]

Visualisers are an expensive thing in terms of CPU usage, even more so if more than one is active in a specific moment of time. Add to that the fact that these Lua powered visualisers rewrite stuff in the skin in order to replicate meters in an automated process, and you get what you just got.

The best option in these cases would be to rewrite the skins to display the equivalent of spawning another visualiser instance (e.g. more meters, colored differently), but within the same skin and using the same measures, in order to not have redundant stuff that basically does the same thing at the expense of CPU usage. Obviously this is going to be difficult for these types of skins, because of their apparent complexity, but it's pretty much the only choice for not turning your computer into a potato. Even so, it takes some careful coding to make the "merged" variant efficient, so you don't have many guarantees that it will work as well as expected. It should work better though.

[AnryuKen]

Visualisers are an expensive thing in terms of CPU usage, even more so if more than one is active in a specific moment of time. Add to that the fact that these Lua powered visualisers rewrite stuff in the skin in order to replicate meters in an automated process, and you get what you just got.

The best option in these cases would be to rewrite the skins to display the equivalent of spawning another visualiser instance (e.g. more meters, colored differently), but within the same skin and using the same measures, in order to not have redundant stuff that basically does the same thing at the expense of CPU usage. Obviously this is going to be difficult for these types of skins, because of their apparent complexity, but it's pretty much the only choice for not turning your computer into a potato. Even so, it takes some careful coding to make the "merged" variant efficient, so you don't have many guarantees that it will work as well as expected. It should work better though.

I'm not very familiar with meters in visualizer. I did manage to fix my problem slightly, instead of using the settings for my WHITE Fountain of Colors, I edited the Angle variables from the .ini of WHITE itself (also, it seems only the Angle variable is affected, I can edited other variables using the settings just fine). Also, yes, it seems running 2 FoCs (Fountain of Colors) makes Rainmeter slow for me (although other programs worked just fine and task manager says CPU usage isn't overloaded or anything). But from my experience with other Visualizers, this didn't seemed to be the case, I was running 2 Variants of VisBubble and it worked smoothly, no lag.

I'm not very familiar with "merged" variant method, currently I am relying on duplicating the entire folder to have 2 types of the same skin. Also, I'd like to thank all of you for putting up with a noob like me lol, I appreciate it and I'm learning stuff bit by bit.

[balala]

But from my experience with other Visualizers, this didn't seemed to be the case, I was running 2 Variants of VisBubble and it worked smoothly, no lag.

Weird, because visualizer skins are using a lot of resources. Not recommanded to have more than one loaded. These visualizer skins have a low Update (most of them well below 100 milliseconds) and this fact makes them extraordinary resource-hungry.
See for instance Yincognito's reply above.

[Yincognito]

I'm not very familiar with meters in visualizer. I did manage to fix my problem slightly, instead of using the settings for my WHITE Fountain of Colors, I edited the Angle variables from the .ini of WHITE itself (also, it seems only the Angle variable is affected, I can edited other variables using the settings just fine). Also, yes, it seems running 2 FoCs (Fountain of Colors) makes Rainmeter slow for me (although other programs worked just fine and task manager says CPU usage isn't overloaded or anything). But from my experience with other Visualizers, this didn't seemed to be the case, I was running 2 Variants of VisBubble and it worked smoothly, no lag.

I'm not very familiar with "merged" variant method, currently I am relying on duplicating the entire folder to have 2 types of the same skin. Also, I'd like to thank all of you for putting up with a noob like me lol, I appreciate it and I'm learning stuff bit by bit.

Yeah, don't worry - "merging" (or, if you like, "moving" the meters used by 2 skins in a single skin so that they can use the same measures in that skin) such skins is not an easy job anyway. As CodeCode mentioned, some visualisers are nicer or more efficient than others, it depends on how optimized their code is. Also, a lot depends on whether you have other skins doing intensive work (of fast update rates) at the same time while displaying the visualisers.

In the end, everyone probably settles on the scenario that looks best and has the fewest drawbacks in terms of efficiency. It depends on many factors, but as a general idea, the arrangement must consider the resource hungry nature of these types of skins and the level of optimization in the code to alleviate that.

[AnryuKen]

Possibly a visualiser alternative that is still appealing but not as resource demanding.

I found Monstercat more flexible, and at one point had two running just fine.

Monstercat is also a smaller group of files and no lua iirc.

But, it has less options but there is an angle setting although I might be remembering incorrectly.

I tried Monstercat and you were right lol. I didn't have that much lag in running 2 Monstercats while running 2 Fountain of Colors made my rainmeter lag (Dragging the Rainmeter Manager was laggy and stuttering). Monstercat was also not as buggy like FoC when I duplicated it. I always thought Monstercat was a bigger and more resource-demanding skin because it was pretty famous and had a lot of features - guess I judged it by its cover.