I worked up a nifty patch of contraptions - 8 stereo channels into a mixer and then out, with each channel comprising some combo of Drums, Basslines, Arpeggiators filtered through SouthPoles and/or other effects - and was enjoying myself. All sounded fine. But then, while watching a particular SouthPole, I noticed that the moving line (the one that indicates time/beat) was significantly behind the actual sound - by a 1/16th or two at 92bpm. Hmmm. I'd never seen this behavior before.
I knew all along I had wired a good many contraptions together, perhaps my most ever, and I was keeping my eye on the CPU load indicator down at bottom right. It was running at around 7.6, sometimes up to 8.5 - well below what I've seen in other AM setups I've created. But this lag in the graphics made me wonder. So, I went to Activity Monitor, a Mac utility, and there I found AM running at ... 103% CPU.
So, I am puzzled. What does AM's CPU load figure refer to? And what is its relation to the one shown in Activity Monitor? (I know that on my 4-core Mac, CPU can range to 400%, or maybe even 600% - I forget; much more than 100%, anyway. All of which I don;t quite understand.) I notice that AM's CPU load figure goes away entirely when the Enable Audio button is off. Likewise, the Mac monitor shows CPU dropping from 100%+ to 10% or so with Enable Audio off.
And what might be causing this visual delay? I don't have any other cpu-intensive apps running at the same time as AM.
I also wonder if contraptions that are open in the AM Patcher window are actively consuming CPU cycles even when they are not actually connected to others or generating any audible sound. I sometimes leave them there after removing them from a patch, just because I might want to add them back into the mix. The evidence says no, they are not taxing the CPU when alone in AM.
Which is to say, how does AM actually work, I wonder? This may be a trade secret, but I am certainly curious about its internal structure, or functional map, or whatever. Any hints? Like, as we add contraptions to Patcher, does this load additional modules of code into memory and kick into play, or are they there all along, just getting shared, perhaps concurrently processing different streams of data in a multi-threaded way? Admittedly, I may know just enough about this to be asking the wrong questions. But I also admit that I am curious, and I often think about what's going on beneath the covers as I am fiddling with AM. The more I play with it, the more impressed I am and the more curious as to how it can possibly do what it does. Any hints?
thanks in advance.
> What does AM's CPU load figure refer to?
CPU usage for synthesizing/processing audio. When this number gets too high (usually 70-90% depending on your system) audio will start to break up.
> I went to Activity Monitor, a Mac utility, and there I found AM running at ... 103% CPU.
That would be the aggregate of all CPU utilisation .. the main thing other than audio will be rendering the animated GUI.
AudioMulch will work to render the GUI as fast as it can (up to a limit at least) so if there is a lot going on visually it may max out one core on your system.
> And what might be causing this visual delay?
Most likely AM can't render the GUI fast enough to keep up. Without seeing your patch I can't say whether this is unusual. If you email it to rossb@audiomulch.com I can take a deeper look. It might be something else.
>>>>
I also wonder if contraptions that are open in the AM Patcher window are actively consuming CPU cycles even when they are not actually connected to others or generating any audible sound.
<<<<
If they are connected via some path to SoundOut they will consume CPU. Muted signal generators usually consume less CPU than unmuted ones. Effects/processors usually use the same amount of CPU whether they are processing silence or audible sound. This is by design -- the intention is for things to be predictable. You wouldn't want to turn up a fader and suddenly discover you're using too much CPU and have the audio break up.
>>>>
Like, as we add contraptions to Patcher, does this load additional modules of code into memory and kick into play, or are they there all along, just getting shared, perhaps concurrently processing different streams of data in a multi-threaded way?
<<<<
All audio processing happens in one thread at the moment. As I've said here before there are long term thoughts to move to multi-core audio processing but it's not on the short-term roadmap so it may never happen, much as I would like it to some day.
>>>>
Admittedly, I may know just enough about this to be asking the wrong questions. But I also admit that I am curious, and I often think about what's going on beneath the covers as I am fiddling with AM.
<<<<<
I'm happy to answer more specific questions if you have any. But in simple terms: each contraption computes it's output starting at the signal sources, those outputs are processed and consumed by other contraptions, in turn, following the way they are connected, until the audio reaches SoundOut, where it's copied to the operating system/audio driver.
Thanks, Ross, for the info.
I have just noticed that the larger the entire AM window is, the more CPU the program consumes, as measured in Mac OS X - there's no change reflected in AM's load indicator. I have been using the program with a fairly wide display - 27 inch, i think - and with AM occupying virtually all of this large area. That may explain the GUI sluggishness I saw - which, of course, I now am unable to duplicate.
If you do work out a way to duplicate the sluggishness, please let me know.
Improving GUI performance is one of the things I'm working on for AM2.2 so feedback about this will be really helpful.
I'm sending you by email a patch - a different one than the one I cited here - that seems sluggish in the GUI area.
As noted in my email, it seems that zooming OUT in the patcher pane makes for sluggish GUI. The smaller my patch looks, the more my Bassline cursors stutter. Is this to be expected?
One thing: try disabling "Show Contraption Input/Output Activity Indicators" in the View menu and see if that helps. That's a known performance issue.
Anything to do with inefficient GUI rendering on OS X is not particularly surprising either -- it just doesn't perform as well as Windows -- this seems to be an OSX issue since the code is the same.
However, I have been working on this and expect version 2.2 to show some improvements. Thanks for sending the files. I'll look into it.
Ross.