GUI chugging hard on OS X, but totally fine on Windows
I've got quite a large synth patch. Everything is in bpatchers - It has 8 LFOs, 4 multi-wave oscillators, 2 filters and a custom Java-based parameter mapping system ( for linking parameters to OSC, MIDI, other parameters - and all other routing shenanigans ). But honestly, it's nothing outrageous.
The system runs perfectly on all the Windows systems I've tested it on. This ranges from basic i5 1.8ghz laptops, all the way to 3.2ghz i7 desktops. No dramas what-so-ever.
Every single Mac I've tried it on, no matter what spec ( even a top notch i7 MacBook Pro, down to a 4 y/o iMac i3 ), the whole GUI interaction chugs to the point where it's basically unusable. But, as soon as I turn the audio system off, it runs fine ( obviously, this isn't really feasible for a synth, but shows it there's something going on with the scheduler and audio processing ).
On ALL of these tests ( both OS X and Windows ), none of the audio processing showed more than 15% CPU at full load, Overdrive was active ( without it all the timing is shot ) and ALL of the audio processing objects/patches are in their own [poly~] patches and are muted until they're needed.
Trying to isolate the problem revealed that it's simply a cumulative effect from all of the bpatchers - so there doesn't seem to be a specific object that is causing the slow-downs.
I suppose my questions are:
- Why is there such a huge difference between OS X and Windows in these tests?
- How does the GUI chug even when the CPU usage is sub-15%?
- Are there known issues with certain objects on OS X that might cause this issue?
Chris.
Perhaps this is a really obvious thing, but have you kept an eye on the signal vector size between machines? Large sizes like 2048 or 4096 seem to make GUI elements look like they're struggling. I noticed this on my laptop the other day, and had always presumed it was because the processor couldn't keep up.
Thanks for the suggestion Mark. I wasn't checking that at first, but I added that to my tests in case the vectors had something to do with it. Unfortunately they don't seem to make a difference with this issue.
Is there anyone that knows a bit more about how the scheduler system works in Max that might be able to explain how the GUI can be sluggish even with very low CPU cycle usage?
maybe something to do with the sound cards (difference btwn win and mac) some sort of bottleneck there perhaps?
I was thinking that. I'm not really familiar with OS X, but it's pretty clear there are major differences in the way Windows and OS X handle their audio processing.
It looks like all the OS X audio processing goes through "core audio". But I have no idea why on earth the efficiency of these idle audio processes would cause the whole patch to chug while the CPU sits at a comfy 8%. If I had have known this was a possibility I would have deved a lot closer with OS X. Lesson learnt.
Has anyone else run into a similar issue when moving a patch over to the other OS?
Just an update on this. I've managed to get much better GUI input responsiveness in this patch by increasing the time between GUI draws ( from 33.3ms to 60ms ), and putting up the "redraw queue throttle" to 10,000. I also made sure to hide any bpatchers that were obstructed anyway using scripts to [thispatcher]. I created a toggle switch for the [scope] and other visualisation objects so that people running on OS X can get better performance out of the interface.
So this begs the question - what is so drastically different between how the Max environment runs under Windows and OS X that causes this massive difference in performance?
Here's a screen cap of the interface. As you can see, there's not that many objects on screen; and this huge performance hit occurs even with a completely static patch with no activity.
I have a different question - I never looked at those scheduler settings before so am playing with them.
What exactly is the difference between "Event Interval" and "Refresh Rate"?
The docs (https://cycling74.com/docs/max5/vignettes/core/scheduler_pane.html) say that "Event Interval" controls how often the interface (GUI, I assume) is updated.
However, there's no explanation of "Refresh Rate" but there is something called "Refresh Interval" which seems to have a similar definition as "Event Interval", at least in terms of results.
Events are your messages, not the GUI. Refresh rate is the GUI draw.