xMonsta

Just wondering is there any thing that could cause Max to slow down when using lots of MSP objects?

I've got 2 or 3 snapshot and sig objects - could this be causing the problem?

I'm also getting the following error with msp objects in the max window "adding more than one perform routine to dsp chain is not recommended"

The patch is completely slow, a number box wont even update, unless I disconnect all the MSP cords (then it comes back after a while). when I disconnect the cords also all audio stops for a few seconds and then comes back again. I also cant print anything or send any messages to message boxes. When I try to connect objects with patchcords, the patchcords look as if they're connected, but also look pretty strange.

I've tried restarting, so pretty sure it's not a strange crash or anything

patch-with-msp-object-in-slows-down

Kind of hard to troubleshoot without seeing the patch. Snapshot~ shouldn't be slowing you down that much, no. My patch has 6 snapshot~ (meters for my lemur setup) and I saw absolutely no slowdowns. Sig~ is really lightweight too.

"lots of msp objects" could do it, but again, how much are we talking?

Kind of hard to troubleshoot without seeing the patch. Snapshot~ shouldn't be slowing you down that much, no. My patch has 6 snapshot~ (meters for my lemur setup) and I saw absolutely no slowdowns. Sig~ is really lightweight too. 

"lots of msp objects" could do it, but again, how much are we talking?


Thanks Wetterberg, yes, patch is very big and hard to isolate the problem - though I will try to post a patch. Good to know that snapshot and sig shouldnt cause these kind of problems.

Try to avoid having too many GUI elements on the screen like floating number boxes, message boxes etc.. Redrawing a lot of them really can slow max down.

3 snapshot~ can become a real problem – but only if your CPU is 

have you already used the cpu usage profiling tool in Max? it will give you hints wich parts of your patch are resource intensive.

If I'm understanding you correctly, Jan, then you're referring to the tools built into the Max6 audio window. They're not in the Max7 window at all, BUT you can still get the data from the adstatus object, IIRC.

I meant switching on "View->Show CPU usage" to quickly identify if there is a "hot spot" in the dsp chain

ahhhh right. Such a graphically simple and lovely feature.

yea, i tend to forget about it, then I remember it again and love it ;) It does not give much infos (not a profiling tool) but it's good for a fast overview.

Thanks for the CPU visual tip Jan. This is really interesting.

However, I'm not seeing any red objects, but still the patch is really sluggish.

It's really strange, I've attached an image to show:

1st image - When trying to connect a patchcord, it's seemingly able to connect anywhere and doesnt appear attached to the object

2nd image - all the red/green bobbles are missing from the patchcords when they're touched.

This happens with both MSP and Max objects.

2nd image - all the red/green bobbles are missing from the patchcords when they're touched. 

This happens with both MSP and Max objects.


maybe it is time to post the whole patch. :)

Or at least start chipping away at the patch, to narrow down the problem.

FWIW I've had similar strange slowdowns with max two different times. Turns out to be udpsend lagging up the place, and a memory leak in regexp.

Or at least start chipping away at the patch, to narrow down the problem. 

FWIW I've had similar strange slowdowns with max two different times. Turns out to be udpsend lagging up the place, and a memory leak in regexp.


It's a pain tracking these things down. Interestingly, there is this strange error appearing the max window for every MSP object.

"adding more than one perform routine to dsp chain is not recommended"

Can't post the whole patch, because it's not all mine. However, I'll try and narrow down an example. Although narrowing it down is really the hardest part.

Just really wondering if anyone has seen this before. It doesn't really cause an error in the patch (it works flawlessly). However, it means the patch can't be edited which is a real pain.

Since it's in M4L, the patch behaves differently in the editor vs closed, so it's a case of constantly having to close-reopen the patch for testing it.

If the offending parts of the patch are deleted, the clogging seems to be reduced, but it's a case of waiting for a long time before editing can be resumed. This also makes it very time consuming to test fixes.

"adding more than one perform routine to dsp chain is not recommended"
Can't post the whole patch, because it's not all mine. However, I'll try and narrow down an example. Although narrowing it down is really the hardest part.

If the offending parts of the patch are deleted, the clogging seems to be reduced, but it's a case of waiting for a long time before editing can be resumed. This also makes it very time consuming to test fixes.


This is actually turning out to be a problem with Max 7. This works fine in Max 6. Submitting a bug report now...

Are you still having a problem with max7? Now I have the same problem.

I have very similiar problem with max 8. The patch is really glitchy and it crashes when copying some objects or switching ezdac~ on, or saving a patch when some other patches are opened. I reinstalled Max 2-times and it is doing the same. I thought that it is because of too many objects in one patch, so I rebuilt it to individual patches into one folder, but it makes no difference...

Patch running slow (msp objects - snapshot?)