Anyone know why Max6 is using 12% CPU when it's not doing anything?

    Jun 06 2014 | 11:43 am
    I started Max6 (6.1.7) last night and noted it was using significant CPU cycles, figured it was rebuilding its database or something. This morning, it is still at 8% + another 5% for coreaudiod even though no patchers are loaded and Audio is turned off (see attachment).
    What's it doing?
    I note that if I restart and Audio is disabled, coreaudiod is 0. Turning on Audio causes coreaudiod to go up to about 5% and it then stays there, even if I turn off Audio again.

    • Jun 06 2014 | 12:36 pm
      CPU cycles doesn't mean much in this respect. Max can run on different threads, so if one patch is using a lot of CPU then build another max patch and let the two communicate with each other. My Max CPU "use" can hit a 100% and I run all my live sets without a hitch. Like everything worry about that number when you notice an actual problem ;-)
    • Jun 06 2014 | 12:42 pm
      I understand all that --- but why is it using 12% (consistently) of my CPU when it's (presumably) not doing anything?
      As for dealing with actual problems, I like to try to be proactive so as to avoid actual problems
    • Jun 06 2014 | 5:15 pm
      Well for a program to run it needs CPU, even if Max isn't running it's on standby ready to do what you need it to. Good CPU optimisation has to do with how your patches are created, not the fact that a program is running.
    • Jun 06 2014 | 5:31 pm
      Uhh, yeah, except that plenty of other "good" programs that are on my machine, including such gems as Logic Pro X (which I just loaded out of curiosity) are showing less than 2% when just open. And CoreAudioD which got loaded with Logic is at 1.8%
      Even Firefox (into which I'm typing this) with 6 other tabs open is only slightly over 3% (and it's doing stuff)
      I realize programs have to do some stuff, even when they're quiescent (e.g, processing a few events on the RunLoop) but that doesn't account for 8% + another 5% when there's no (apparent) work to be done and it's in the background.
      I'm not suggesting it shouldn't be using these cycles, but I'm interested to know what it's spending them on.
      If I sample the process, I can see a number of "thread waits" and there are some timers running via JUCE but it also looks like the scheduler is running, even when there are no patchers running.
    • Jun 06 2014 | 5:57 pm
      Didn't mean to come over the wrong way with what I was saying, just trying to help out. Maybe this question is best put towards cycling'74.
    • Jun 06 2014 | 7:58 pm
      Nothing came over the wrong way and I appreciated the help --- I was just looking for more specific details.
      I don't like to bother support directly unless I have a real problem that can't be answered on these forums. I always assume that the cycling74 folks see most of these questions anyway
    • Jun 06 2014 | 8:16 pm
      hm - fwiw, Max is often needy in cpu on my machine, even if it does nothing.
    • Jun 07 2014 | 11:46 am
      i am just guessing, but indeed it might be the scheduler. first because there is no on/off for it as for the dsp chain. secondly, even if you haven't open any of your patches there are the build-in ones such as the audio status menu which might run in the background and will need the scheduler to work. my2GuessingCents
    • Jun 07 2014 | 2:34 pm
      thats more or less just an OSX thing. these cycles are not actually busy, more like "reserved".
      you dont really believe that e.g. windowserver or littlesnitch do actually require these cycles, arent you? if window server and maxmsp 5 would really need 22% of your CPU, they would need 300% on my G4 computers!
      btw, tabs in background (in both, safari and fireforx) are muted totally, just to give you an idea how things are organized on OSX today. :)
      btw, i am not sure, but i believe that all these CPU monitor utils simply show only the peaks, just like when you measure an audio envelope, which has nothing to do with the actual power of the signal.