Hey
General question about CPU usage and monitoring.
I've got some fairly busy Audiomulch files which I use live. They'd all been working without dramas, but I've just recently started running Native Instruments Guitar Rig on the same laptop which obviously means the CPU is a little more in demand. As a result I've occasionally hit CPU spikes and glitching has begun to occur. That's all fine, I can understand that. I just need to make sure my AMHs are economical.
However, AM's CPU reporting seems to be a little wacky. The usage indicator in the status bar doesn't get above 15%, and yet if I look at it in Activity Monitor the usage is consistently well above 90%. As a result, it's a little hard to see when I'm risking an overload unless I have Activity Monitor open all the time. Is there an issue here, or is there an explanation?
Also - what methods can I use to squeeze the most juice out of my environment. Is it worth changing the AM process priority? Are there things I can do (aside from lowering the sample rate obviously) to improve performance?
I'm beginning to realise I may need to start bouncing out some sounds and using loops for them instead - which is a little bit of a shame, but that's just the way it goes. Any other tips for making sure the files don't go out of control?
J
Hi
The AM CPU meter only shows audio/dsp CPU usage. So if other things are going on then it won't tell you the whole story. On the other hand, everything else in AM that could be going on should scale to deal with having less CPU. The obvious example is GUI rendering -- if you've got a whole bunch of automation or Metasurface controlling lots of parameters then AudioMulch will be constantly trying to update the GUI to reflect the current parameter state -- it tries to go as fast as it can (up to a limit, 25fps from memory) to stay responsive, so it will soak up as much CPU as it can -- but the GUI thread always runs at a much lower priority than the audio/dsp thread, so GUI rendering should never cause audio glitches, even if the CPU is at 100%.
I'm pretty confident that's why you're seeing a discrepancy between the AM and Activity Monitor CPU readings. One way you could check for sure if it's the AM GUI is try running your patches with all the AM panes (patcher, properties, automation, metasurface) hidden. Then check activity monitor.
In terms of cross-app work, running GR on the same laptop you're probably going to need to be looking at a separate app to monitor what each app is doing. I'm not sure if Activity Monitor is the best tool for this but it sounds like a reasonable approach.
Does that all make sense?
Ross.
Bam! Thanks Ross, that was what I needed.
This helped me identify the major source of the problem: the input/output activity indicators in the patcher screen. also the scrolling time markers in the Arpeggiators were a bit of a problem as well. Once I disabled those, the app went from 95% to 20%.
Yeah, the patcher input/output activity indicators use a lot of CPU. I'm aware of this, hence the ability to turn them off.
this is a very cool and useful tip !
thanks