super slow maxmsp

Aug 9, 2013 at 6:52am

super slow maxmsp

Hello everybody!
It has been now some time that my MaxMSP is super slow.
I bought a new macbook Pro Retina Display last summer and whenever I put some simple things like splays playing fast or one vst, the computer/processing becomes super slow and it seems the buffer does not manage this. It has happen that I turn off the sfplay~ and the audio keeps playing and stops after some seconds. The previous MacBook I had could do much more (and I mean, a lot more) processing handling… Everything is updated so I don’t understand this issue. It is annoying.

Anyone has the same problem? Is it due to retina computers cpu stuff or could it be because I am running Mountain Lion?
Any advice will be appreciated.

Thanks in advance and good luck.

Aug 9, 2013 at 7:04am

I found this in the Max help which may solve your issue…

MacBook Retina GUI Redrawing Issues

On a Retina Macbook, if you have a patch that is performing a lot of user interface drawing, such as rapid updates to JSUI, you are possibly backlogging the queue, which can have an effect on scheduler performance. On these machines, GUI rendering costs are roughly 4x expensive, unless you disable high resolution support (patchers will look worse). To turn off high resolution support for Max, go to the Finder, and Get-Info (cmd+i) on the Max application icon and check the “Open in Low Resolution” box.

Aug 9, 2013 at 11:21am

If it’s not the retina rendering cost affecting your performance. Often times, audio preferences either being manually or corrupted somehow in machine migration to have a low signal vector size is an issue. Check your Options -> Audio Status -> Signal Vector Size, and make sure that it is something reasonable like 32 or higher. If this value is set to something low like 16 or less, CPU can be expensive as the overhead for per vector operations begins to outweigh the sample operations that happen within processing a single signal vector of audio.

If neither of these seem to be the issue for you, please contact support.

Aug 10, 2013 at 4:08am

Thanks for your comments!
I had already change the signal vector size to high values such as 1024 and I was having the same problem.
For instance: playing sfplay~ + seek $1 with random values triggered from a metro = 10 ms, seems to clog the buffer. If I change the metro it will take some time for to 1) update the value in the number box controlling metro, it keeps stuck for some time 2) the audio takes seconds to update to the new values. The patch is just this… there no more msp processes or objects…

I will do more tests.


Apr 17, 2014 at 3:33am

Did you solve this?
I am having maybe similar slowness issues, that disappear when I turn of Audio DSP processing.


You must be logged in to reply to this topic.