MaxMSP: Reduce CPU load by avoiding excessive GUI updates

By vb, 24/12/2016

In MaxMSP it’s very easy to create relatively good looking graphical user interfaces (GUIs) quickly, which no doubt can be very helpful in a lot of situations (user guidance, performance, teaching etc.). But it’s also true, that the display of (especially dynamic) graphics taxes the CPU quite a lot.

Here is an example: spectroscope~ displays the spectrum of an input signal. You might think, that taking the short term Fast Fourier Transform of a signal is not the cheapest action to handle in a computer, but as it turns out, drawing the magnitude shape of a dynamically changing spectrum costs much more than actually doing the FFT analysis of the input signal.

In this simple test, with spectroscope~ at its default dimensions, displaying the magnitude of a static sinusoidal input from a cycle~ object clocks the CPU on my computer with an average of about 13%. Not going deeper into FFT size and overlap etc. and how these parameters affect the CPU load, this looks quite ok to me.

Compared to a not so static noise~ input, there is already a significant difference of almost 10%.

And things really get bad, if we change the size of the spectrum display…

With the size being only slightly bigger than the default, the CPU load really starts to go through the roof.

Similar issues occur with other frequently updated GUIs like signal meters. To be fair, most of these objects have an update interval or polling rate parameter, which again can have a big influence on the overall CPU load. If set to a low update rate, movements can look jaggy quite quickly, of course. But personally I prefer that over bringing the whole system to its knees.

So, the first rule in performance critical patches seems to be:
simply avoid (unnecessary) GUIs, or at least check if their respective size on the screen affects performance.
Secondly, adjust the update/polling rate to an acceptable minimum value.

There might be cases where this is still not enough: in a project with various sound modules, where I needed to quickly see, if a module outputs sound or not, I finally replaced all the signal meters with a custom made solution, a signal LED. This is a minimal GUI object, that lights up as soon as the input signal power has gone past a user defined threshold value and goes off, after input falls below again. The goal was to get away with a minimum number of drawing actions. So if the state doesn’t change, i.e. if the input power stays above or below the threshold, nothing is redrawn.

If you want to try it, you can find a version for osx here. Don’t be confused by the name (vb.meter~) – I started out to do an efficient meter~ object, but kept slimming it down, until I ended up with an LED.
Now, if I could only add Mira-support for this little thing…