Pigments and CPU use

[sluggo]

I've been trying the trial for Pigments 2. Really like it. Takes a lot of cpu. I have an i5-8250 (1.6 GHz, Kaby Lake). It's not the greatest CPU...

A few patches take my cpu into the red with only a few notes, but that's just eyeballing it with my host's cpu meter. I'm wondering if someone out there has a good feel for how much power this plugin needs for everyday use, like a few instances per project. Of course I'm testing this out but it's taking me a while to build up a large-ish project.

thanks

[planetearth]

Which patches in particular? The granular-based ones will take more CPU cycles, but with that processor, you should be able to run several instances of Pigments 2--assuming your machine is fairly well optimized and you're using an ASIO driver for your audio interface.

Steve

[EvilDragon]

1.6 GHz is really not enough, no matter to how much it turbos.

[Tj Shredder]

Even 10 years ago this wasn’t really fast... Devs don’t expect that...; - )
But simple patches should still work...

[planetearth]

I'd assumed the "1.6 GHz" was a typo, considering that the processor isn't that old and some in that line can reach 4.5 GHz. Maybe it's not....

Steve

[chk071]

No typo. https://ark.intel.com/content/www/de/de ... 0-ghz.html

[buzz1]

What other soft synths do you have and how do they stack up CPU- wise against Pigments? That would give you a reference given your low spec-no offence- processor.

[tony10000]

I have an 8th gen i3 that I have set up to run consistently at 3.4GHz and 3 notes of the pad 5ths Sweep averages at out at about 35% CPU and peaks at around 50%. Pigments can be CPU intensive depending on the patch, the number of notes held, and the release time.

[Ficciones]

Try comparing usage with the GUI showing versus hidden. The graphics use a lot of horsepower, I find.

[ENV1]

Try comparing usage with the GUI showing versus hidden. The graphics use a lot of horsepower, I find.

+100

Ive lost count of how many plugins ive encountered which would take an insane amout of CPU (50% and more) while the UI was open whereas the same plugin with the same settings and same everything would use almost nothing (maybe 2-3%) when the UI was closed.

Its the first thing i always check when a plugin constantly has inexplicably high CPU usage because in so many cases its really just the UI that is consuming all the CPU.

[tony10000]

Try comparing usage with the GUI showing versus hidden. The graphics use a lot of horsepower, I find.

+100

Ive lost count of how many plugins ive encountered which would take an insane amout of CPU (50% and more) while the UI was open whereas the same plugin with the same settings and same everything would use almost nothing (maybe 2-3%) when the UI was closed.

Its the first thing i always check when a plugin constantly has inexplicably high CPU usage because in so many cases its really just the UI that is consuming all the CPU.

Interesting...that is why some plugins allow you to adjust the graphics refresh rate.

[Trancit]

Try comparing usage with the GUI showing versus hidden. The graphics use a lot of horsepower, I find.

+100

Ive lost count of how many plugins ive encountered which would take an insane amout of CPU (50% and more) while the UI was open whereas the same plugin with the same settings and same everything would use almost nothing (maybe 2-3%) when the UI was closed.

Its the first thing i always check when a plugin constantly has inexplicably high CPU usage because in so many cases its really just the UI that is consuming all the CPU.

Interesting...that is why some plugins allow you to adjust the graphics refresh rate.

No, imho that´s why developers should start to use more the GPU rendering for intense animated GUIs instead of letting the CPU do all of the work!!!

[tony10000]

Try comparing usage with the GUI showing versus hidden. The graphics use a lot of horsepower, I find.

+100

Ive lost count of how many plugins ive encountered which would take an insane amout of CPU (50% and more) while the UI was open whereas the same plugin with the same settings and same everything would use almost nothing (maybe 2-3%) when the UI was closed.

Its the first thing i always check when a plugin constantly has inexplicably high CPU usage because in so many cases its really just the UI that is consuming all the CPU.

Interesting...that is why some plugins allow you to adjust the graphics refresh rate.

No, imho that´s why developers should start to use more the GPU rendering for intense animated GUIs instead of letting the CPU do all of the work!!!

True...

[Cooker]

I use a rather old computer and remember it being demanding on cpu. You also have to consider adding fx in the mix stage as for various reasons freezing may be distracting to the creative process.

[ENV1]

Try comparing usage with the GUI showing versus hidden. The graphics use a lot of horsepower, I find.

+100

Ive lost count of how many plugins ive encountered which would take an insane amout of CPU (50% and more) while the UI was open whereas the same plugin with the same settings and same everything would use almost nothing (maybe 2-3%) when the UI was closed.

Its the first thing i always check when a plugin constantly has inexplicably high CPU usage because in so many cases its really just the UI that is consuming all the CPU.

Interesting...that is why some plugins allow you to adjust the graphics refresh rate.

No, imho that´s why developers should start to use more the GPU rendering for intense animated GUIs instead of letting the CPU do all of the work!!!

Agreed.

Considering the features of some of the more modern UIs this could be similar to the difference between running the GFX plugin of say a PlayStation emulator in software mode (CPU) versus running it in hardware mode, (GPU), which would make use of all of the video cards accelleration capabilities and therefore let the CPU 'concentrate' on other stuff. (In this case dealing with the audio processing.)

I hope we will see that eventually because it really could help.