Guitar Amp Sim & CPU Usage

Gig Performer on Mac OS X
1

Sorry for the long post.

First off, congrats to the GP guys on the collaboration with Plugin Alliance. I hope it brings a lot more people to the platform.

My current rig is various guitars (lately my go to is my Strandberg Original 6), into a Digitech Whammy DT (for whammy and down tuning), then to an Xsonic Xtone Pro to my MacBook Pro via USB then back to the Xtone which is plugged into a pair of Atomic CLR monitors. The tones are so good, the best I’ve ever gotten.

I use various plugins from Neural DSP, Mercuriall, Nembrini, Line 6 and others. For most rack spaces I run the following signal chain. Helix Native #1 for pre effects —> Amp Sim —> Helix Native #2 for post effects. For the most part I’ll run maybe 5 rack spaces per rig as anything more than that uses a ton of CPU (per Activity Monitor…more on that later). This means for any given rig I’m running maybe 10 instances of Helix native, 5 amp sims, and handful of other plugins. If I need a different combination of rack spaces, I just create a new rig and populate as necessary. The export/import rack spaces feature is really helpful in doing this by the way.

I have my audio in GP set for 44.1 and 256 samples (I read the GP article on latency…:)) on a 2017 13” MBP with 3.5Ghz Dual-Core i7 and 16 GB of RAM.

This brings me to the crux of my observation and question. My main question is if the behavior I’m seeing is normal. If not, what am I doing wrong? Here’s the behavior…

GP generally reports about 10% CPU usage for any given rack space. Except when I use the Neural stuff (Plini is my favorite), the CPU usage goes up to around 20%. I think this is normal as most people generally report the Neural stuff using more CPU. I don’t think there’s an issue here.

MAC OS Activity Monitor typically reports the GP process as around 50% usage if I have around 5 rack spaces. I built a mega rig with about 12 rack spaces the process usage shot up to ~150%. However, there is another CPU usage meter at the bottom called “system” and it generally reports usage around 15% for small rigs and 30% for the mega rig.

For the most part everything works well regardless of rig. The fans on my machine kick on with the mega rig, so I moved to smaller rigs to avoid putting too much stress on the MacBook.

The only issue I have is the Mercriall plugins. They use about half the CPU of the Neural stuff but I get quite a few pops if I run any other apps like YouTube or iTunes. Interesting they use less CPU, but have more problems. I suspect this is a problem with the plugins. I’m going to send an email to the devs to see what they say.

Is this behavior normal? Can someone explain why the process CPU usage is so much higher than the system? I obviously don’t understand what I’m looking at. LOL.

Thanks for the help.

2

I don’t have specific answers, just my own observations as I have a similarly spec’ed MBP. I run at 48kHz and 160 samples in GP and usually don’t hear any issues with clicks/pops till I’m up around 50% CPU reported in GP. I also never really paid any attention to the Mac activity monitor.

From my own understanding, the CPU usage should really only depend on your active rackspace. I’m surprised to hear you’re having issues based on the number of rackspaces.

As an aside, do you use the Predictive Loading feature in GP?

3

The only reason you would have a different CPU usage with more rackspaces is if some of the plugins you use continue to do stuff in the background event when not active.
Most, well developed, plugins will not consume CPU cycles if they are not being used. Others will simply continue to behave as if they’re being fully utilized.

You can see which plugins are doing that by bypassing them and monitoring your CPU usage.

Depending on your situation and how you use GP - try enabling the “Predictive loading” feature under the advanced option. That feature not only unloads the plugins from memory for less memory usage, but it will also remove the bad behaved plugins. Again - not sure what your use case is here. If you are jumping randomly to any given rackspace - this may not be for you, but give it a go.

In general - the activity monitor displays all kinds of utilizations which is useful, but in the context of GP - only the audio engine utilization is really important and that is what you see in the GP CPU display.

Note that while switching rackspaces - there are parts of a second or a few seconds where multiple things are active so anything above 50% of CPU usage in a single rackspace should be avoided.

4

Thanks for the insight. I’m still a little confused. Let me explain more clearly.

I have a rig with 6 rack spaces. Each rack space has 2 instances of Helix Native and 1 instance of an amp sim…in this case 5 are Neural DSP Plini and 1 is the new Nembrini Cali Reverb. Each rack space shows between 12-15% usage in GP. The MacOS Activity monitor shows the “GigPerformer3” task as ~85-90% CPU usage using 1.28GB of my 8GB of RAM, the activity monitor also shows “System” at the bottom of the window as ~21% CPU usage. See the attached screen shot.

CPU Usage 5 racks
CPU Usage 5 racks942×694 118 KB

I loaded another rig, but this one has 11 rackspaces, again mostly with 2 instances of Helix Native and 1 amp sim. Each rack space shows between 9-15% usage in GP. The MacOS Activity Monitor shows the “GigPerformer3” task between 145-150%, using 1.65GB of RAM. The activity monitor also shows the “system” CPU usage at the bottom of the window as between 33-35%. See the attached screenshot.

CPU Usage 11 racks
CPU Usage 11 racks932×836 111 KB

The CPU usage in GP does not change for a given rack space no matter how many additional rack spaces I add. Based on my understanding this is the expected behavior.

Bypassing plugins lowers the CPU usage for a given Rackspace within GP down to basically 0%, but does not change the Activity Monitor CPU usage number significantly at all. It would seem that the more backspaces you add, the more CPU usage I have (per MacOS Activity Monitor). Again, the per Rackspace CPU usage as reported by GP is constant, no matter how many Rackspaces are added.

If I load a completely blank rig GP is using around 1.5% CPU per MacOS Activity Monitor. Loading just one rack with 3 plugins, takes it up to around 38% per Activity Monitor. Within GP the CPU load is 12%….again, as expected.

As I said everything seems to work fine except for when I’m using Mercuriall plugins (Euphoria and Reaxis). For some reason whenever those plugins are loaded even though they don’t use any more CPU than anything else (as measured either in GP or in Activity Monitor) they cause clicking and popping if I do anything on the system. If all I do is play, they’re usually fine, but as soon as I play a YouTube video or something in iTunes or anything else, I get popping and drop outs. It doesn’t last forever, for example once the YouTube video is playing, the pops and dropouts go away. It seem as if anything that takes away resources from GP is causing issues. It does not do this for other plugins, only the Mercuriall stuff. Which is kind of a bummer, because they sound so good. Like I said originally, I don’t think this is a GP issue, I think it has something to do with those plugins in particular.

My question boils down to whether the CPU usage I’m seeing in Activity Monitor makes sense? Should I even bother looking at it?

Optimally, I’d like to have one rig with all my sounds and amp sims in different Rackspaces so I could just switch to sounds at will. I’m thinking that’s not really feasible unless I get a more powerful machine.

5

The System resources include your drivers. As you add things like YouTube, iTunes or anything else that uses your computer resources like audio driver, video driver etc… the system resource usage will go up and your driver/computer/interface may not be able to cope.

Some plugins are build incredibly well. Optimized both in cpu and memory usage. Others simply aren’t and will use much more resources that they should.

Having said that - every system has its limit. As you keep loading resource intensive plugins - you will reach that imit.

6

Thanks, I think we’re getting closer to answering my question. I understand that other applications use up more system resources. I still would like to know why GP reports usage of 12% in the app, but activity monitor reports the Gigperformer3 process as using between 60-150% depending on the gig I load. Is GP really using other (non audio) system resources that heavily? Or is it the plugins themselves that are using the other system resources?

Either way, I’ll just not build such big gigs. It’s not a big deal, GP has been indispensable to my daily guitar playing. Keep up the great work!

7

The GP CPU meter reports the AUDIO usage in GP. The Activity monitor on your mac reports everything. Graphical painting, file system all the other stuff. Also … If you have a 4-core system - that number in activity monitor can go up to 400%

GP itself is VERY “lean”. If you open it up and don’t att any plugins to it - you will see that the CPU usage is MINIMAL. That’s what GP is using. All the other resources will be consumed by your plugins. Some do better job than others.

8

Thanks so much for the answer. It would seem that many of my plugins are using quite a few resources. Not much I can do about that other than contact the developers to let them know. As you said, when GP is open with no plugins it uses about ~1.5% according to activity monitor. I might just have to move up to a more powerful machine…:slight_smile:

9

Think about adjusting your audio settings a bit and trying the “Predictive Loading” feature in GP. See if that helps. You lose some of the functionality, but you can have thousands of rackspaces if you wanted to :slight_smile:

10

Here is my view

  1. What happens to the GP CPU value when a plugin stops generating sound

For example, here is pianoteq when I play a bunch of notes. The GP CPU is at 10%
screenshot_758
2. And here it is after I have released all notes and the sound has died away

screenshot_759
As you can see, the audio processing time drops dramatically to 2%. That, to me, is good behavior.

On the other hand, if CPU stays high when there’s no audio being produced, then the plugin is doing a lot of unnecessary work inside the audio processing area, which is not a good thing, particularly for live performance.

The PA plugins are remarkably good as well, at least their effects plugins. I haven’t tried their synths yet.

1 Like
11

As this is for guitar, there is ALWAYS audio coming in even if not playing so plugins will always be processing sadly.

12

@speed12 I was about to say the same. My CPU usage in GP does not change whether I’m playing or not. It’s not a big deal to me to have multiple rigs for different uses. I’m not playing live so waiting for different rigs to load is fine.

I just wanted to confirm that everything is performing as it should. The answer appears to be yes.

13

@djogon I’ll give Predictive Loading a try and report back on the results. I suspect others who use GP for guitar will have this same issue. Hopefully, you’ll get more guitar users with all of the Plugin Alliance folks coming on board.

14

My sense is that in guitar situations, there are often effects that are being turned on and off so bypassing is another useful technique. You might want to ask Trey Gunn what he’s doing since he seems to have tons of plugins loaded but hasn’t run into any issues. I know he’s running at 128 buffer size.

15

I did a little experimenting and I think part of the reason for high CPU usage is the Neural DSP plugins. While they sound great, they use a ton of DSP whether they are in the active rack space or not.

For example, a created a rig with just the ML Sounds Amped and Helix Native. GP reported CPU usage of ~10% and Activity Monitor reported usage of ~14%…not a big difference.

I then loaded a rack space with NDSP Plini and Helix Native and the GP reported usage was about 20%, but the Activity Monitor usage went up to ~50% — a big jump.

I then replaced Plini with the PA Diezel VH4 plugin and the GP usage went down to ~10% and the Activity Monitor usage went to around 14%.

My conclusion for my admittedly non-scientific test is that NDSP plugins use about twice the audio DSP and cause the overall DSP to go up significantly in this examples from 14% to 50%.

In the end I’m only having two “issues”: 1) Mercuriall plugins popping every now and then, and 2) Laptop fans working overtime when I have a rig with a lot of rack spaces going. I can work around both issues easily enough. I was just trying to understand what the different CPU monitors were telling me. I’m going to email Mercuriall to see if they have any suggestions or if this is a known problem. Of course I could just buy a new iMac or Mac Mini and probably have no issues. I don’t gig, so portability is not an issue. The only issue is convincing my wife I need another computer basically just to play guitar through…not sure that will go over well. :wink:

16

I think Mercurial are quite CPU heavy as well (like Neural) so maybe that’s why?

My fans go nuts as well - I wouldn’t worry too much if there is lots of air around the laptop; that’s what they are there for! There are ways of cranking the fans to max to start with which means the cooling stays a bit more consistent if you wanted.

Yeah, absolutely - although for some FX like reverb and delay you have to (depending on the plugin of course) mute the input rather than bypass otherwise you lose the tails when bypassing (if you guys can find a way of getting round this it would be INCREDIBLE!)

17

Thanks for the video, good stuff!

18

I don’t know about that. From what I see on my system the Mercuriall stuff uses about 1/2 the CPU of NDSP. Oddly enough, I don’t have any issues with the NDSP stuff popping…despite the higher CPU usage. I only have issues with Mercuriall. I wonder if something else is going on.

19

Ah ok, interesting. @djogon, @dhj is there anything else in a plugin apart from CPU usage that can cause audio issue? (I appreciate the answer might well be LOTS!)

20

A plugin can do whatever it really wants and I know I am repeating myself, but some are better and more efficient than others.

I did personally try some of the plugins you are mentioning here (I don’t want to name names) and I noticed immediately that some are unnecessarily CPU intensive. The sound was not better in any way.

I’s all good if all you want is that ONE plugin to run and nothing else. It unfortunately seems that that’s how some developers approached their plugin design. Some also spin all kinds of threads doing lots of work on empty data without checking if any processing should be done.

Everyone has to make a choice for themselves. In my book - sound is the king, but I refuse to run any plugins that seems to be wasting a lot of resources. I’d rather have that little bit of “CPU headroom” when performing as hearing pops or clicks through the PA is probably not fun (never happened to me so I wouldn’t know :slight_smile: )