Patrick Keenan

I am writing a patch for a composition which requires max to be processing audio and also generating a score in realtime on screen. Beside each performers part is a metronome made up of [button] objects being controlled by a [metro] cycling through a [counter]. The problem is that when the processing gets too heavy the 'metronome' i have made starts to go out of time. In the DSP cpu monitor in max it is showing about 40% when it starts to falter. I have connected a print object to the metro and the bangs are still coming through exactly in time but the button objects which are lighting up for the performers to be able to stay in time start to speed up and slow down.

Is there anything i can do to stop this? Is it a problem with displaying graphics in max?

I am writing a patch for a composition which requires max to be processing audio and also generating a score in realtime on screen.  Beside each performers part is a metronome made up of [button] objects being controlled by a [metro] cycling through a [counter].  The problem is that when the processing gets too heavy the 'metronome' i have made starts to go out of time.  In the DSP cpu monitor in max it is showing about 40% when it starts to falter.  I have connected a print object to the metro and the bangs are still coming through exactly in time but the button objects which are lighting up for the performers to be able to stay in time start to speed up and slow down.

Is there anything i can do to stop this?  Is it a problem with displaying graphics in max?

cpu-usage-problems

If you are doing any processing that is time sensitive, do not

use metro. Metro uses the scheduler to service timer requests, which

is always subject to the load on the processor. Using an audio

rate timer will ensure that your timing is solid.

If you are doing any processing that is time sensitive, do not
use metro. Metro uses the scheduler to service timer requests, which
is always subject to the load on the processor. Using an audio
rate timer will ensure that your timing is solid.


The processing isn't time sensitive itself. there are a few granulation modules processing sound but they have no relation to any [metro]s, It is merely the blinking of some buttons that needs to stay in sync to the metro. Will this still be affected by cpu load.

Do you suggest using phasor or something similar to guide my 'metronomes'?

The processing isn't time sensitive itself.  there are a few granulation modules processing sound but they have no relation to any [metro]s,  It is merely the blinking of some buttons that needs to stay in sync to the metro.  Will this still be affected by cpu load.

Yes, basically if you need something to keep reliable time, you should

You should also look into syncing the phasor with the global transport

so that you can have tempo/bar/beat support.

Yes, basically if you need something to keep reliable time, you should
use a phasor based implementation.

You should also look into syncing the phasor with the global transport
so that you can have tempo/bar/beat support.


Tried using phasor but still the buttons blink out of sync with the phasor running them when the cpu usage gets to around 40%.

Anyone have any ideas on how this can be fixed?

Can you connect a sound to the blinking button and see if it sounds

out of sync. It maybe that the UI is updated at a different rate.

Can you connect a sound to the blinking button and see if it sounds
 out of sync. It maybe that the UI is updated at a different rate.


You have to switch overdrive on, and eventually scheduler in audio interrupt as well, both in the dsp status settings...

Depending on the amount of scheduler events this still isn't enough. If you have a lot of scheduler event to create your score, you can play with the scheduler settings in the preferences. Scheduler slop, throttle etc. Search for scheduler preferences in the docs...

You might want to thin out scheduler events for the score, look at speedlim, qlim, qmetro. Never ever put [snapshot~ 1] in a patch, the minimum value is 20, better 50... I doubt that an audio based metro would help in this case. Its visual, not audible. Our eyes are fine if its within 20 ms, the ears would not forgive such sloppyness...

You have to switch overdrive on, and eventually scheduler in audio interrupt as well, both in the dsp status settings...
Depending on the amount of scheduler events this still isn't enough. If you have a lot of scheduler event to create your score, you can play with the scheduler settings in the preferences. Scheduler slop, throttle etc. Search for scheduler preferences in the docs...
You might want to thin out scheduler events for the score, look at speedlim, qlim, qmetro. Never ever put [snapshot~ 1] in a patch, the minimum value is 20, better 50... I doubt that an audio based metro would help in this case. Its visual, not audible. Our eyes are fine if its within 20 ms, the ears would not forgive such sloppyness...

I forgot to mention, CPU usage only reports the audio usage, if you are on Mac, open the activity monitor to see how much CPU Max is really eating...

And close your Browser if its running...;-)

You could also try other displaying objects, I usually use a led. A Jitter based display is also possible (OpenGL is rendered directly on the graphics card...)

I suspect that rendering the score is your bottleneck, try to optimize that...

I forgot to mention, CPU usage only reports the audio usage, if you are on Mac, open the activity monitor to see how much CPU Max is really eating...
And close your Browser if its running...;-)
You could also try other displaying objects, I usually use a led. A Jitter based display is also possible (OpenGL is rendered directly on the graphics card...)

I suspect that rendering the score is your bottleneck, try to optimize that...


Thanks so much for your suggestions. Changing the scheduler refresh to 10ms from 33.3333 seemed to do the trick.

Thanks so much for your suggestions.  Changing the scheduler refresh to 10ms from 33.3333 seemed to do the trick.

Cpu usage problems