Forums > MaxMSP

Reducing CPU load

Sep 08 2012 | 8:57 pm

Hi there,

We developed a synthesizer with MSP for the use with our hardware. Basic concept is like "modding everything with everything". So every parameter of a voice can be modulated by any of the available mod sources. These are Velocity, Key-Position and … All signal based lfos and envelope-generators.

The Oscillators are the ones out of msps library and also seem to use a certain amout of cpu resources, i think because of the really good anti aliasing…

This complex voice structure however leads to a cpu load of 50% when playing 8 voices in a Max For Live Runtime on a Core i7 2.3 GHz retina mac machine …

Quite a lot, but i havent seen any other max synthesizers yet.


What to do to reduce cpu load? I tried replacing the signal envelope gens with control-rate generators, that helped but the ended in poor sound quality … Modulation quality.

So at this time i think i have to deal with that.

Anyone else got some tricks or tips for me to reduce cpu load?



Sep 08 2012 | 9:54 pm

hard to tell without the patch. but when i read the description i think this is what would need about
50% CPU on my ten years old computer, so there is probably some room left for optimisation. ;)


Sep 08 2012 | 10:28 pm

Any chance you’ve got a lot of GUI objects in there to monitor signals and parameters? Loads of these updating in (near) realtime can eat a lot of performance.

Sep 08 2012 | 11:45 pm

I recently found that GUI elements were eating up about 80% CPU in my patch (Max was saying about 30% but looking at activity monitor told a much different story, up in the 120% range). I slowly started pulling GUI elements away (meter~, waveform~ etc.. and now it’s down to 50% in activity monitor). I actually kept meter~ but moved them to a super slow polling rate.

I didn’t realize the massive hit it would have, but it’s worth keeping in mind (and checking activity monitor too as Max only tells you MSP object CPU usage, and not GUI/max/total usage).

Sep 09 2012 | 7:09 am


I seperated the gui from the rest right at the beginning. The gui isnt a problem at all. In idle state it takes only a few cpu cycles. But the realtime modulation of every parameter with every mod source is quite expemsive.

I will post the patcher later,


Sep 09 2012 | 9:37 am

1) what versions of maxforlive and live are you running? you need at least 5.1.8 and 8.2.2 respectively, preferably higher.

2) from your description it sounds like you might be using lots of live.remote~s? if so, you need to downsample the modulation signals.

3) in general, downsample all modulation signals.

4) and all voices are inside a properly managed poly~ instance, yes?

Sep 09 2012 | 1:24 pm


1) Both, latest versions …

2) i am not. At all… We wrote externals in c to communicate with our hardware, a keyboard which uses an ethernet connection – with our own protocol – 16 bit velocity and touch sensitive keys –

The externals run in a seperate low priority thread, tested and implemented proper. And not cpu intense in any way

3) hmm … I think controlling is done with a polling rate of 20ms …

4) yes of course, i also inplemented dsp chain management and begin~ network management of some sub-signal-chains (switching osc waveforms).

I just checked my voice once again, did some refactoring and tested one situation: i removed all the controlling and just left the signal path in a default configuration.

Well there it is … Now i know that most of the cpu cycles are lost in the signal path … And i think that optimization just can be done with more writing externals … Which will be done … But in later releases …

Currently i am on my way back to my office and will finally upload the voice patcher to let you get more into it!


Sep 09 2012 | 1:29 pm

Ah! And the begin~ signal management doesn’t seem to work within a poly~ instanciated patcher … Leaving just the begin~ objects out, cpu load goes a little bit down…

Sep 10 2012 | 10:46 am

May be I’m wrong…but with your new MBP and may be you just dump a tons of soundlibrary,from your ex laptop…may be spotlight do something and may be iPhoto trying to faces your photos ….. but hey 50%load on production is acceptable right ….

Oct 01 2015 | 4:53 am

Do GUI elements that are not visible, in subpatchers for example, also consume unnecessary amounts of CPU?

In many of the unseen subpatchers of a project I’m working on I have float and message boxes so things look clearer when I open it up to look at what’s going on, and I’m wondering if I should delete these.

Oct 01 2015 | 7:14 am

chris muir’s benchmark test is always a good approach to find these things out. i use it constantly. running the following, you’ll see that there’s no difference between seemingly "hidden" and visible GUI elements. avoid them when you can.

-- Pasted Max Patch, click to expand. --

Oct 01 2015 | 7:19 am

ha! this is crazy! – as for my observation: only after opening the (2nd) patcher with the numbox inside, it starts increasing in CPU load. i’ll post that to a new thread as i can’t explain this (:

Feb 04 2017 | 7:57 am

Hi! I realized a multiconvolver patch and I am having the same problem with the waste of CPU in realtime. It increases in a crazy way, sometimes having some very unusual peaks, as 90-95%. In average it takes 20-30% but it takes some peaks of 96 and 100% for a pair of second. Something must be wrong. I am using 12 convolvers, and yes, I realize that its a big number of realtime processing. I used the mute and pass objects to close the subpatches reducing the processes, but it keeps eating the memory up in a such terrible way, so it doesnt work. Can anyone help me to optimize the memory?

Viewing 13 posts - 1 through 13 (of 13 total)

Forums > MaxMSP