Guitar Amp Sim & CPU Usage

Cool, thanks for the response - imagined that would be the answer but always good to hear from someone who actually knows what they are talking about!

Yeah, absolutely - same here. I find that I tend to drop down the quality a notch or two on those plugins where there is a setting for it (e.g. where the have oversampling settings etc) from what I would maybe use if I was recording something. In a live mix those little nuances that those settings give are basically lost immediately in the overall mix but having pops and clicks from using the higher quality settings are certainly obvious!

Out of interest, what does your GP CPU meter usually run at for a ā€˜gig readyā€™ rackspace? Since switching to S-Gear (which is ace!) I can now comfortably run at about 20% with all FX active (of which in real life not all would be at one time) in a rackspace at 256 samples which seems to work great for me. Previously using Thermionik it was up nearer to 30% which was starting to get on the dangerous side during rackspace switches where it spikes up temporarily as previously mentioned.

S-Gear is an example of a well-built plugin. Just like the audio settings and anything else in my real gigging rig - it all comes down to the fact if it works for me and if it sounds good. I donā€™t care that much how much CPU is used as long as there are no artifacts while playing. Any potential issues are revealed in rehearsals and I tweak them before the show.

Just like thereā€™s no reason, sound-wise, to run your interface at 96k for a live performance or run it with an 8 samples buffer size - you can - if you have the right gear and plugins.

Subjective stuff matters when it comes to performing. We all know that a red guitar sounds WAY BETTER than a blue one :slight_smile: If it matters to YOU - do it. Sometimes just changing the strap on your guitar gives you that extra push you need for your performance so - do whatever feels right, makes you play better and allows you to have more fun on stage.

3 Likes

Maybe this is obvious and goes without saying, but Iā€™ll say it anyway.

Some plugins consume vastly more system resources when their windows are open vs. when they are closed. Off the top of my head I recall many of the Melda plugins will do this. Nothing that happens on your screen happens for free, so if you have a plugin with fancy graphics trying to look pretty with real time depictions of audio transforms or whatever on screen, thatā€™s going to consume resources. How much depends on how well theyā€™re written.

Where I disagree with djogon is that red guitars are for n00bie hacks. I mean, theyā€™re fine for shred metal but definitely not blues. The one exception is if youā€™re doing heavy old school blues based classic rock that used to be called metal. That kind of blues metal on a red guitar can give you a really nice deep purple sound.

3 Likes

That ā€œred guitarā€ reminds me to Dilbert:

2 Likes

Red guitars are limited to drinking beers.

str-mar-dec

1 Like

guitarist here. i still havenā€™t sorted everything out about which of my way-too-many plugins to use and which to avoid, but i use guitar sounds and synth sounds a lot in the same rackspace (using MidiGuitar 2 to drive the synths) and tons of effects because, i canā€™t play like a regular guitarist so why try to sound like one? :wink:

my cpu usage in some gig files gets up into the 50-60% range, but it all still works. several of my gig files are experimental, where i am working out rackspaces that will then be moved to a leaner gig file for performance usage.

iā€™ve only rarely encountered actual processing overloads, usually when running an amp plus maybe 4 synths, one or more of wich may be dodgy. have to sort those out as well. this is on a 2012 MBP, 2.9G dual core i7, 16G RAM. i run GP at 224 samples.

anyway: yes, the NDSP stuff is very cpu-intensive, i can also see that rackspaces containing NDSP amp sims take much longer to load than some other amp sims. that said, the NDSP amps sound frigginā€™ amazing! (the NDSP plugins shut down their usage nicely when their rackspaces are not active, so thatā€™s good.) so, choices to makeā€¦

@tonycore. Interesting. How does Midi Guitar 2 track? Iā€™m looking at that, and Fishman Triple Play and even the new Boss SY1000.

As far as the NDSP plugins go, I noticed they shut down their usage when you switch to a different Rackspace per the GP CPU monitor. However, if you look at the Activity Monitor (MacOs), the Gigperformer3 process is still using a lot of CPU. From what I understand that means those plugins are doing a bunch of other non-audio stuff in the background eating up CPU cycles. I do not see this same behavior with pretty much any other plugin.

For example:
I had a rig with 10 rackspaces and every one had at least one NDSP plugin and activity monitor was reporting ~150% usage for the GigPerformer3 process and GP was reporting ~20% for each Rackspace depending on how many plugins were going. My laptop got really hot and the fans were going crazy. Everything worked, but I donā€™t like to push my machine that hard.

I created another rig with about 10 Rackspaces that did not include any NDSP stuff and Activity Monitor reported no more than ~30% CPU usage and each Rackspace was in the neighborhood of 12% or so. My laptop didnā€™t even feel hot after playing for a few hours.

Donā€™t get me wrong, Iā€™m not bagging on NDSP. They make great sounding products (Plini is my favorite), but the inefficiency Iā€™ve discovered is pretty bad. I canā€™t wait to get my QuadCortex where I can run all of the plugins on the hardware and not have to worry about it.

MG2 isā€¦amazing. i donā€™t know how they do it, but it is unbelievably fast and accurate. i have ditched my vg-99 (i do miss the tuning changes, though, and have to say i am also intrigued by the SY1000). i recommend MG2 highly. takes a little tweaking to get the settings right for oneā€™s guitar and playing style, of course. itā€™s also very sensitive to pitch changes, so i got some help here writing a script to block those, which i use on most patches (need to look into scaling the pitchbend info rather than blocking it).

@tonycore
About MG2 pitchbends, did you adjust the settings in the articulation section according to your synthā€™s pitchbend range, given that each synth can have differents ranges ?

You can also find some MG2 scripts on jamosapien to get accurate results.
Maybe this topic could help: postpone bending

I use rackspace variations to enable different MG2 bends ranges (or disable), according to wether I bend only guitar or synth or both.

And my GP cpu usage is less than 35% playing MG2 with 3 synths, 6 fx, 1 amp sim with some fx and cabs, 1 audio file player using multitracks. My laptop is a rather old but optimized i5 dual core 2.8 GHz with 8Go ram.

1 Like

Hmmm, I have a license for MG2, I fired it up today and did not find the tracking to be that fast, there was noticeable delay between plucking the string and hearing a synth play

i have no noticeable latency with MG2.

Hermon, thanks for the tips - i will check them out. the main problem for me has been pitchbend when i lift a finger from the string, which then remains as the note decays. a better description of the script i was helped with is that it automatically returns the pitchbend to zero when it receives a note-off message.

@dhj
midi software solutions come with latency due to wave lengths.
Maybe I got used to this latency and it does not bother me anymore.

If you just start on MG2, first look at the latency settings in the audio interface section to have fastest time with no glitchā€¦

Set your audio interface to have the highest and clear guitar signal in with no distorsion.

Then try different settings in MG2 midi velocity section.

Ensure that the sync button in the mixer section is down (used to compensate synth latency by adding delay to the guitar channel).

And first of all, experiment a synth with a very fast attack time such as percussion to hear whether synth sound is more or less delayed.

I know it is obvious but these steps are all needed to get the best result.
My latency in MG2 is set to 96 samples. It is good for all situations and I feel confortableā€¦ But I am easily pleased :slight_smile:

Because I have nothing better do and I was curious I did some test regarding CPU usage, hereā€™s what I found.

I looked at 3 types of CPU usage:

  1. GP audio CPU %
  2. Activity Monitor CPU (the bottom of the windowā€¦I subtracted the ā€œIdleā€™ from 100 to get the actual CPU usage.
  3. Activity Monitor ā€œGigPerformer3ā€ process from the big window with the huge list of processes. My understanding is that this is showing you what % of the active CPU is being taken up by a given process. For examples, Idle reads 80%, so Iā€™m using 20% CPU (between user and system), and the GigPerformer3 process reports 50%. This translates to the GP process actually using 10% (50% of the total 20%) CPU.

With that in mind hereā€™s what I found.

A 13 rack space Rig with Line 6 Helix, ML Audio Amped, Nembrini, Brainworx, Kuassa and SLT:

  • GP CPU is between 9-15% depending on which Rackspace I have loaded.
  • Total CPU usage per Activity Monitor ~20%
  • GigPerfomer3 process ~30%

If I remove one rack space the numbers change to:

  • Individual rack space usage doesnā€™t change
  • Total CPU usage went down to ~17-19%
  • GigPerformer3 process went down to ~29%

I wasnā€™t going to go one by one removing rack spaces so I jumped to having only 8 backspaces left. The numbers changed to:

  • Individual rack spaces didnā€™t change
  • CPU usage down to 10-14%
  • GigPerformer3 process down to ~20%.

Down to 1 rack space:

  • Rack space still ~10%
  • CPU usage ~10%
  • Process usage ~15%

My conclusion is that at a minimum (on my machine) 1 rack space uses a given amount of CPU and goes up minimally the more rack spaces are added. Process usage also goes minimally as you add more backspaces. This means to me that the plugins are not using much resources when not active (in a rack space ā€“ as they should). None of the numbers above were pushing my machine at all. The temperatures were low and the fans never came on. I feel like I could add a bunch more rack spaces and still be fine.

However, none of this is with the Neural DSP plugins. I just want to say up front (again), Iā€™m not bashing Neural. Their stuff sounds great and I will continue to use it. I will probably buy whatever new plugins they come out with and Iā€™m on already on the first pre-order for the QuadCortex hardware floor unit. Clearly, Iā€™m a fan. Iā€™m only providing this information for those that might be interested or are having problems.

4 rack spaces (3 Plini and 1 with Nolly)

  • Rack spaces between 18-22% usage
  • CPU usage ~23%
  • GigPerfomer3 process ~65%

3 rack spaces (2 Plini, 1 Nolly)

  • Rack spaces between 18-22% usage
  • CPU still ~23%
  • GP process ~52%

2 rack spaces (1 Plini, 1 Nolly)

  • No change in rack spaces
  • CPU ~20%
  • GP Process ~40%

1 rack space (Plini)

  • Rack Space 19%
  • GP CPU ~20%
  • Process still around ~40%

My conclusion is the Neural plugins use about double the CPU per rack space as my other plugins. This isnā€™t a surprise as they well known to be CPU hogs. It also seems that at a minimum the process will be 40% and goes up from there as you add more rack spaces. In addition, the plugins apparently continue to use resources even when they are not in the active rack space (bad). A while back I had a Rig with about 10 Neural plugins and the Process was up in the 150% range and total CPU was around 50%. Everything worked, but my fans were going crazy and my machine was pretty hot.

Of course, this wasnā€™t scientific and there are lot of variables because not every rack space was configured with the same plugins, etc. However, I think the general conclusions hold up. None of this is to say I wonā€™t use Neural plugins, I just need to keep the number of rack spaces per gig smaller to avoid my machine running hot for extended periods. As well all know heat kills electronics.

Now Iā€™m going to go back to just playing and becoming a better guitar player. Thanks for reading the long post.

This, you should report to them ā€” it means that they are running a ton of stuff unnecessarily outside of audio processing. If audio processing is bypassed, then they shouldnā€™t run other stuff

Yep. I already did. They said they would look into it. Hopefully weā€™ll see an update itā€™s some point.

1 Like