CPU ISSUE

[Marcel.Sperrhake]

Hi Arturia Team,

I got a massive problem with cpu usage when using pigments.
When I use it as VST Plugin in Ableton live and open it via plug-in-editor the CPU usage goes up to around 70%.
If I close it its about 16%. This happens without playing a sound or live playing.
GPU (NVIDIA Quadro P5000) usage around 6% and it seems that its not used for displaying the graphics.

Any ideas??

Setting:
Windows 10
Ableton Live 10.0.6
FIREFACE UCX via USB
HP ZBook 17 G4 (i7-7820HQ@2.9GHz, 32GB RAM)
Pigments v.1.1.1.503

[LBH]

Hi and welcome to Arturia Forums.

Does Pigments use the same CPU power when used as standalone application?
Do you have any Latency features ON in Ableton?
It's normal the CPU usage go high at the time of loading, and then go down afterwards, if that's what you mean.

Which samplerate and buffers do you use? Both in your DAW and your Pigments standalone application.

Have set your PC to High Performance mode? If not, then i suggest you do so.
Have you tweeaked other settings on your PC?

The latest version of Pigments is version 1.1.2.539. So you are not updated. Can't tell if updating will make a difference.

I'm not sure Pigments CPU usage is messured correct in Windows. But it can use a lot of CPU power. 70% in idle however does seem very high.

FYI. If you wan't to be sure to reach Arturia support, then you have to contact them through your Arturia account.

[zerocrossing]

I’m also getting a lot of pops and crackles in the latest version of Bitwig. Almost all the factory patches show this. Turning down the voice count and unison voices helps, but I have a hard time imagining why such simple patches are killing my i7 running at 3.4 with 16 gigs of ram. I do run at 64 samples for a buffer, but I need it at that setting for my guitar to feel right.

[LBH]

I’m also getting a lot of pops and crackles in the latest version of Bitwig. Almost all the factory patches show this. Turning down the voice count and unison voices helps, but I have a hard time imagining why such simple patches are killing my i7 running at 3.4 with 16 gigs of ram. I do run at 64 samples for a buffer, but I need it at that setting for my guitar to feel right.

What is the name of your i7 CPU?
At which buffer size can you run Pigments?
What samplerate do you use?
How many voices do you play?
Are your computer running in high performance mode and optimized for Audio production?
Have you changed any settings in BIOS?
Which soundcard and driver are you using?
Do you use any features in your DAW, that claim to help CPU perfomance?

I can run Pigments playing many voices at a samplerate of 48000 Hz and a buffer of 64 samples with my i7 3770 3.4 GHz base frequency CPU (3.9 GHz Turbo) from the year 2012. It's on a tower PC.
But off course how much i can do depends on what else is going on and other things including which sound i use.
Pigments is'nt the most demanding plug-in i have, but it can be quite demanding. It also have a good sound.

I assume you don't play guitar at the same time, so in case it's needed, then can't you change buffer while using Synths like Pigments?

[cseder]

I also have some annoyingly high CPU usage numbers when using Pigments in Studio One 4.5 Professional.
S1 has this functionality that it gives plugins a separate process with separate block-size settings for instruments and audio while still managing to keep the latency low.

This gives Pigments its own process with a 1024k block-size, and I'm using 44.1kHz and some times 48kHz sampling with 24 bit-depth, 64bit processing on a modern MacBook Pro (Intel i7).
This works fine with most other plugins, but Pigments in particular makes the CPU meter jump around and spikes all the time with this setting enabled, causing crackles and pops.

I manage to get by with turning off the Studio One "Native Low Latency" feature when I'm using Pigments, but it would be nice if it behaved like my other synth plugins, as turning off this feature means I'll also have to change my audio interface block size to keep getting low latency which is a PITA in the middle of a session.

I've tried using both the AU and the VST3 versions of Pigments, but same result. The default patch that loads when Pigments activate ("Synthwave Reverses") totally makes my CPU catch fire.
Using a simple patch helps a little, but hey, I have other synths for that!

Using Pigments in Stand-Alone mode demands around 20% CPU at most, even with the heaviest patches loaded.
Something fishy going on with the VST/AU versions.

It's gotten to a point where I rather load a different synth when using Studio One, because Pigments is such a rude boy.

Now I mostly use Pigments in Stand-Alone mode for playing around, which is a shame, as I hoped this would be my new go-to synth for most things.
 

[LBH]

I also have some annoyingly high CPU usage numbers when using Pigments in Studio One 4.5 Professional.
S1 has this functionality that it gives plugins a separate process with separate block-size settings for instruments and audio while still managing to keep the latency low.

This gives Pigments its own process with a 1024k block-size, and I'm using 44.1kHz and some times 48kHz sampling with 24 bit-depth, 64bit processing on a modern MacBook Pro (Intel i7).
This works fine with most other plugins, but Pigments in particular makes the CPU meter jump around and spikes all the time with this setting enabled, causing crackles and pops.

I manage to get by with turning off the Studio One "Native Low Latency" feature when I'm using Pigments, but it would be nice if it behaved like my other synth plugins, as turning off this feature means I'll also have to change my audio interface block size to keep getting low latency which is a PITA in the middle of a session.

I've tried using both the AU and the VST3 versions of Pigments, but same result. The default patch that loads when Pigments activate ("Synthwave Reverses") totally makes my CPU catch fire.
Using a simple patch helps a little, but hey, I have other synths for that!

Using Pigments in Stand-Alone mode demands around 20% CPU at most, even with the heaviest patches loaded.
Something fishy going on with the VST/AU versions.

It's gotten to a point where I rather load a different synth when using Studio One, because Pigments is such a rude boy.

Now I mostly use Pigments in Stand-Alone mode for playing around, which is a shame, as I hoped this would be my new go-to synth for most things.
 

Hi and welcome to Arturia forums.

Your problem is'nt about Pigments but about Studio One.

I have Studie One 3. I'm afraid you are misunderstanding the so called Drop out Protection system. That's why i ask the OP about that in my previous post in this thread.
If it worked the way you seem to think i does, then you should be able to run CPU hungry applications on bad CPUs. Such magic wand does'nt excist.

If the 1048 samples buffer you mention actually was added to your real time performance, then it would be high latency and not low latency.

You does'nt tell some very important things, like what's the buffer you use for your soundcard? That is the buffer you have for your real time performance. And because of the way the dropout protection system works, then it actually put even more load on your CPU for a real time performance than this buffer actually would without using the system, if you use it.

You say this system work great for other plug-ins. Which plug-ins?
If you take an empty song, and then load one of those plug-ins, then what is your CPU reading with and "without" the dropout protection system on? My guess is you have higher CPU usage with the system on, but you have just not come into a situation where you hear it.

Presonus actually recommend to disable "Use native low latency monitoring for instruments", if you use virtual instruments with high CPU usage. Why should they recommend this, unless the system actually add to the CPU load for the real time performance, like it actually does?

Have you read and understood Presonus informations about this?
There are other issues with the so called dropout protection system, but no need to go into that in this forum. Presonus also have forums.

I recommend to do this:
1. Disable "Use native low latency monitoring for instruments"
2. Set the Dropout protection to "Minimum" as you unfortunately can't disable it. I wish you could totally disconnect it, so you did'nt have the code in use at all for this system.
3. Set you soundcard buffer to a setting, that work. You actually confirm this works.

This will make Studio One work as closely as possible to what you in any system can expect to be the lowest CPU load at any given soundcard settings for a realtime performance.

How should it be Pigments that's the culprit?

BTW: Why do you use 64bit processing? Can you hear a difference form 32bit? If this seting give you issues, then change it.  And perhaps read something about it, if you don't know about it. In my Studio One the default setting is 32bit processing. (It has nothing to do with 32 and 64 bit applications.)

There are many i7 CPUs, so it's allways a good thing to specify which one and it's specifications.

[cseder]

Yeah, I guess the dropout protection isn't a magic bullet unless all you do is use native PreSonus plugins.
I've used it with both IK Multimedia Syntronik and the Propellerhead Europa VST and it works a lot smoother with these plugins.


But, I don't mind turning off the dropout system (or setting it to minimum). I've really only found it useful when recording audio anyway, so I'll try deselecting "Use native low latency for instruments" and only leave it enabled for audio inputs / inserts. I think you actually do disable the whole system for instrument channels by doing this, at least according to the Studio One 4.5 manual.

[LBH]

I've used it with both IK Multimedia Syntronik and the Propellerhead Europa VST and it works a lot smoother with these plugins.

What excactly do you mean by smoother?
I think you get at least the same realtime CPU performance or better without using the drop out protection system. Right?

Simplyfied:
The idea for the dropout protection system is, that if you give the recorded tracks a high buffer, then it will put less load on the CPU, and then you can lower the buffer/ latency for the real time performance.
There are especially two serious problems about this:
1. When you lower the buffer for the real time performance, then you put more load on your CPU for this performance. And in this case we are talking about load on individual CPU cores. If you overload a single CPU core, then you have trouble, no matter you have lots of power on other CPU cores. You only get issues if one or more CPU cores are overloaded.
2. When you have different buffers for playback and realtime performance, then this give timing issues.

[cseder]

Nitpicking are we?

Comparing CPU usage, the mentioned plugins (take Syntronik as an example) runs smoother, as in not spiking or dancing up and down the meters all the time when in use, but seems to settle on a lower average while still offering no noticeable latency while I'm playing using a MIDI keyboard.


Also, using the dropout protection gives me an overall lower CPU usage with plugins loaded on tracks that aren't actively in use, e.g on tracks not actively being recorded onto or monitored for input, compared to having dropout protection disabled. So it does provide some form of benefit in certain scenarios.


When dropout protection for instruments is disabled, I still see some CPU activity being generated on tracks with plugins loaded even if they're not record / monitor enabled, but when using the dropout feature S1 seems to make better use of the VST3 interface's possibility to deactivate unused plugins after loading and reactivate those when needed.


This is slightly speculative and I haven't done proper research / benchmarking to give you any detailed analysis right now, but I will look into it.


Meanwhile I'll just disable the feature while using Pigments on record enabled tracks, no big deal.

[LBH]

Nitpicking are we?

About what?