Max 7 super slow, even after closing large patch

madjax's icon

Okay...so I know my computer is not the greatest ("Early 2009 iMac, OSX 10.9.5, 3.06 GHz Core 2 Duo, 4GB ram, ATI Radeon HD 4850 w/ 512 MB vram). I understand why my matrix based video patch bogs down, drops frame-rate, and slows the patcher interface down while adding new objects when the patch is running. What I don't understand is why after I stop the qmetros and even close the patch entirely, the patching interface continues to be slow even when I create a new patch. After I run any large patch for a few minutes, even if I close it, the patching interface on an new patcher will be extremely slow until I quit and relaunch max. I'm talking reaaaaallly slow - e.g. you type an "m" for a new message and you get a beach ball for 2 or 3 seconds before the object spawns. Typing an object name into a new object, a message into a message object, or characters into a text box will hang any processes running in max and will be displayed o...n...e......c...h...a...r...a....c...t...e...r at a time every 2 or 3 seconds until the message is completed. It makes patching impossible and is really annoying.

Max is the only app hanging like this. Other apps run fine, even with a patch running in the background. Max did not used to run like this on this computer in the past. I tried resetting the pram but that didn't help.

Any ideas?

Roman Thilenius's icon

that is the behaviour i would exspect when your patch had about 1 million send/receive namespaces or audio buffers in it. (because this stuff survives the closing of the patcher window) but thats not the case, right?

madjax's icon

no audio in the patch. I have a fair number of send/receive, but I wouldn't say an excessive amount (18 sends 30 receives).

Ullstein's icon

same problem here,

Hi, I am working on a relatively complex patch in the moment - quite some send/receives, but not too many. Yes with audio and video in it, but the funny thing is, when I run it, it works fine, only when I am patching it gets very slow after a short time and I cannot see any rule why it does. I add one object and suddenly it gets slow - as described by MADJAX.
Yes, this Mac is also not the youngest 2009 MacPRO OS X 10.10.5, 2x2,93 GHz Quad-core Intel Xeon, 8 GB RAM. ATI Radeon HD 4870 512 MB.

Any idea?

Ullstein's icon

I forgot to say that I worked on that patch in MAX 6.1 and it never got slow

Byron Lahey's icon

I'm experiencing some variation of this issue. The worst thing, as MADJAX described, seems to be typing (in a message or comment box for example) while editing patches. I type a few letters, wait a few seconds for them to appear, then type a few more. It takes forever to do simple edits. It seems to be worse with any video elements in the patch, but I've had trouble with simple audio only patches as well. Even just running a small (120 x 160) jit.pwindow seems to bog Max7 down. I see a significant performance increase just by toggling this pwindow off. This is an Early 2011 MacBook Pro with 16GB RAM. The same patches in Max6 worked great. I really hope there is an easy fix to this problem. If not I will have to revert to Max6, which is a major problem when all the computers that my students are using are running 7.

metamax's icon

If you are processing a lot of symbols, memory can be an issue (at least it used to be). I had similar behavior on a newer Mac recently but it was only after generating several hundred thousand lines of data using a bunch of regexp and sprintf objects.

Byron Lahey's icon

This problem is definitely not simply a matter of heavy processing. I've certainly built patches that eventually got bogged down with serious processing overload (in Max 6 and earlier). I'm very familiar with this sort of slowing down. This current problem with Max 7 is very different. My CPU load is generally very low when I'm having this issue. I'm wondering if it is related to recent OS updates (I'm running 10.10.5 Yosemite). I've tried running only Max to make sure the problem is not related to some other software taking too many resources or otherwise causing a conflict, but it still happens when I'm only running Max.

I just did this test. I restarted my computer. Opened Max 7. Opened the reference and opened "Tutorial 4: Controlling Movie Playback". When I unlock this patch and type a comment, the playback pauses and the letters I type appear after long delays. When I lock the patcher, things seem to run normally. Obviously this example patch should not be a problem for my computer.

Any help would be greatly appreciated!

vichug's icon

hey guys, i used to experience something very similar with earlier versions of max 7. Did you get the last update ?

Byron Lahey's icon

Thanks for the suggestion Vichug, but I'm on 7.0.6 (the latest as of today).

vichug's icon

ok...well, all i can say is that indeed patching in 7 is significantly slower than in 6, just like patching in 6 was slower than in 5, just like 5 was slower than 4 (or was it ?) because of added patching help (like the "snap to object" or the database search for autocompletion) and nicer UI (hence more expensive to draw)
or maybe a lot of externals cause a large database for autocompletion and hence the lag ?

Jdudeo's icon

Max 7 on Windows 7 here, I'm seeing similar behavior..

Ben Bracken's icon

If anyone on this thread has specific steps to reproduce, and a patcher, please send it in to Support. Be sure to send your Support Info too so we know what OS, version of Max, and other various settings you are using.

-Ben

vichug's icon

Hey Ben,
For my part, i think i reported this to the support a long time ago (or did i ?...)
but after testing what Byron Lahey says in his patch : jitter tutorial 4, and comparing max 7 and 6, it was immediately obvious : creating a new object in 7 does induce a bit of lag in video that isn't there under the same condiitons in max 7. Even if it's not very strong in this case, it is a very simple patch.

Byron Lahey's icon

I just sent a report to Max Support. Hopefully we can get this resolved soon.

Wax's icon

Same experience here. Nothing in my patch and typing/auto-complete in the name of objects is super slow.

Using 10.10.5, Early 2009 Mac Pro Dual 2.26Ghz, with 32gb RAM and a GTX980 card.

metamax's icon

Okay.. I have to add my name to the list.

MacBook Pro (Retina, Mid 2012)
2.6 GHz Intel Core i7
16 GB 1600 MHz DDR3
Intel HD Graphics 4000 1024 MB
Yosemite 10.10.5

Extremely slow..constant pinwheels, several large patches are unusable. Restarting Max doesn't help. Occasionally I get a warning that Max interrupted my computer restart as well.

Should I revert to a previous install or get the latest Mac OS?

Ullstein's icon

Hi Metamax,
a similar thing: I experience Max stopping the shut down of the computer. When Max 7 is running and I turn of the machine, each time I get the message that Max was interrupting the process of the shutdown and I get asked if I want to repeat the shutdown. Never happened before nor with any other app.

Kephyr's icon

Also experiencing very slow performance with large patches as well as the message saying MAX is interrupting shut down (it goes away automatically after a second though). On both a 2012 Quad i7 Mac Mini and a mid-2013 MacBook Air. The patches I were working on were some midi editors for some hardware. No audio or video processing at all.

metamax's icon

Whatever the problem may be, I have been testing more of my work and several large projects are now unusable. Everything just slows to a crawl. I am officially very concerned now. I may contact Cycling74 directly to see if I should revert to an older version of Max or.....? :(

btw.. to the good folks at Cycling.. I have enough trouble debugging my patches - I can't imagine debugging a system wide problem in a full scale application... **thank you**

dhjdhjdhj's icon

I've just started experimenting with Max 7 and I've noticed that autocomplete gets very slow after a while (Max 7.0.6)

mizu's icon

maybe old-newbie lambda user constat: a ssd in my MBP i7 early 2011 - Mavericks Max 7.06 - has solved the unusability of a big old patch. Strange thing, the sound recorded from adoutput~ was clean, but after the core audio, not. (Motu or built-out ): samples zeroed. Windowserver or coreaudio cache overload ? I don't know, but seems OSX now needs a ssd...
zzz

Pascal Champagne's icon

I don't know if this can help but I had this issue for a fair amount of projects. The longer the patch was opened the slower it would get. In this case, I had to many print events going to the console window. Just disconnecting the print objects and emptying the console window did the job and I was back to normal. I'm not saying it will resolve that "super slow" issue in all cases, but i'm sure it will for some of you.

enricopietrocola's icon

Hey there old thread, is there any solution to this yet?

My patch (pretty big) runs perfectly in my windows 7 Bootcamp install, using 40% cpu, when I open it on my macOS Sierra install, same max msp version, it's incredibly slow.

The same goes for standalones, the difference in performance (the computer is the same) between mac and windows is huge.

My specs:

MacBookPro 7.1
2.66ghz dual duo cpu
nvidia 320m
16gb ram
Everything running on SSD

Byron Lahey's icon

For me the solution ended up being a new computer. Max was just the canary in the coalmine. Not long after my last post here the computer started having routine kernel panics and other (clearly hardware related) crashes. This computer (a Late 2011 15" MBP) was really defective from the start. It was on it's 3rd logic board when it finally "self retired". Sorry for casting doubt towards Max as the culprit.

Pietrocola, my guess is this info is not helpful in your case, but I wanted to close the loop for others who might read this and be looking for answers.