Driftnote

I recently upgraded to Max 7 and I'm currently using v. 7.0.3

I noticed that when I make any changes to the patcher and Im working with jitter the images freeze and continue to play after I'm done making changes to the patches. The changes could be anything from changing a number in a integer box, making a new object, dragging or moving any object in the patcher. I wrote a Cycling 74 about this issue to which a tech replied "I can reproduce the problem here. I believe it still happens with the arrow keys if you get it moving fast enough. It appears that there are some possible optimizations we could do in the department of object and patch cord redrawing. I will confer with our Engineering team to see if we can improve this for a future update."

I'm curious to know if anyone else besides me has this problem and perhaps if enough of us have this problem this problem can be address sooner than later in the updates.

The problem is not with any particular patch it can been seen even in the example patches for jitter.

This issue dramatically affects my live performances. Max 6 did not have this bug.

MacBook Pro (Retina, Mid 2012)
2.7 GHz Intel Core i7
16 GB 1600 MHz DDR3
NVIDIA GeForce GT 650M 1024 MB

drastic-frame-drop-max-7

i can reproduce frame drops when editing a patcher, but not when changing a number box (or other UI object) in a locked patcher.

if you have a patch that reproduces the latter, please post it.

when i change the dimension size the rendering skips frames

Scrolling inside a patcher window also causes the frame rate drop. It is often by half the frames per second.

in the patch you posted, you are triggering a computationally expensive task every time you modify the number box (banging the jit.bfg object), so this slow down is expected, especially as the bfg dim value increases. this is the same in max 6.

however, we were recently made aware of an fps slowdown when patchers are unlocked when running Yosemite.

That I also get an fps slow when my patcher is unlocked.

hope this help give insight that it's not just Yosemite

Just to mention Rob ,
That I also get an fps slow when my patcher is unlocked.
I'm on Maverick
Mac os X 10.9.5
processor 2.8Ghz i7
Memory 16g 1600 Mhz DDR3
Nvidia 

hope this help give insight that it's not just Yosemite


The fps also drops when the patchers are locked and you begin to scroll the patcher window. It's the case when I have a jit.window on one side of my screen and the patcher on the opposite side and i need to get to an area of my patch that is only reveal through scrolling the fps drop by half.

Thanks God i'm not crazy ! i observed that, and also on Mavericks... it also involved a radical and sudden increase in cpu usage (hm...maybe unrelated ?), when you were actually increasing the size of the patcher canvas - if you reduce the size of the patcher canvas and hence hide some gui elements (even if they are not interactive), the cpu usage would get low drastically.

hi guys. after looking at this issue in detail, i've come to a few conclusions.

1 - running under Yosemite vs Mavericks incurs a slight performance hit for rapidly updating GUI objects. this affects Max 6 and Max 7 the same.

2 - if using jit.world with the default of @displaylink 1, there will be a fps drop when running a patch with rapidly updating GUI objects. (Max 7 only, jit.world doesn't exist in Max 6)

3 - if running on a Retina machine in hi-res mode vs lo-res, there is a significant FPS drop for any GUI activity. so anytime the patch is unlocked, window resized or scrolled, GUI object updated. affects Max 6 and Max 7 the same.

As always, if you want consistent, stable FPS from your Jitter patch, you should minimize GUI activity. if your project requires significant GUI activity (opening windows, updating GUI objects every frame, unlocking the patch during performance(?)), then you have a few options. The best is to separate your GUI patches entirely from your engine patches, and run 2 instances of Max, passing messages using udpsend/receive. a second, much simpler option is to run Max in lo-res mode (get info on the app icon, check the box next to Open in Low Resolution). a third option is to change the Max App preference for Scheduler -> Refresh Rate, to something like 200ms.

last, if using jit.world with lots of GUI activity, try disabling displaylink (@displaylink 0).

As always, if you want consistent, stable FPS from your Jitter patch, you should minimize GUI activity. if your project requires significant GUI activity (opening windows, updating GUI objects every frame, unlocking the patch during performance(?)), then you have a few options. The best is to separate your GUI patches entirely from your engine patches, and run 2 instances of Max, passing messages using udpsend/receive. a second, much simpler option is to run Max in lo-res mode (get info on the app icon, check the box next to Open in Low Resolution). a third option is to change the Max App preference for Scheduler -> Refresh Rate, to something like 200ms. 

Thanks so much for looking into this in more detail. I will give your suggestions a try and get to back to you when I have a chance.

displaylink=0 makes a huge difference, can you tell us what we loss disabling it? the description of displaylink in the reference help at less for me its a bit cryptic.. :|

disabling it helps to stabilize the frame rate in certain circunstances but i also found that the slowdowns due dragging objects around the patch ***almost*** dissapear....

increasing the "refresh rate" also does a huge difference and im wondering if tweaking other scheduler parameters we will be able to increase the Jitter performance. In general i found the description of Scheduler parameters not so "practical" for people without deep computational knowledge, maybe will be good to have a Wiki about "how to tweak Max to get Jitter best performance" ? :)

hey, I've been having the same kind of issues with a heavy GUI + video patch

I've noticed that if I put all GUI objects in a mira.frame on my iPad, and minimize the window with the heavy GUI objects, everything works fine with a good and consistent fps.

Wouldn't work for a live patching situation though. But I definitely noticed that minimizing unused windows helps the fps rate. At least on my system.

Rob, how to you open two instances of Max7?

I tried using Max7 and Max6 with one dealing with the video, and the other with audio and UI objects, but my CPU was not happy at all.

Processor 2.3 GHz Intel Core i7 - Memory 8 GB 1333 MHz DDR3 - Graphics AMD Radeon HD 6750M 1024 MB

hey, I've been having the same kind of issues with a heavy GUI + video patch
I've noticed that if I put all GUI objects in a mira.frame on my iPad, and minimize the window with the heavy GUI objects, everything works fine with a good and consistent fps.
Wouldn't work for a live patching situation though. But I definitely noticed that minimizing unused windows helps the fps rate. At least on my system.
OS 10.8.5 - Max 7.0.3

Rob, how to you open two instances of Max7?
I tried using Max7 and Max6 with one dealing with the video, and the other with audio and UI objects, but my CPU was not happy at all.
Processor  2.3 GHz Intel Core i7 - Memory  8 GB 1333 MHz DDR3 - Graphics  AMD Radeon HD 6750M 1024 MB


@carsol, displaylink simply tells the jit.world to schedule frames using the display's vertical refresh, so that drawing of frames will be synced buffer swapping. otherwise, an internal timing mechanism is used to schedule frames.

@florent, to open two instances of max, simply copy and paste the app, then open both. can't really help you optimizing without knowing the specifics.

I have a patch with six multi sliders in line scroll view and a couple of scope~ objects. I notice quite substantial timing problem unless i hide those objects. this is on 10.10 and max 6 and 7 an in low-res mode. for instance, a metro with 10 ms argument is actually outputting every 40-60 ms unless i shrink the window down so that the multi sliders are not shown- then I get the expected results. seems like a fairly substantial problem.

maybe limit the multisliders update speed with speedlim?

More props to Rob! Very nice procedure for optimization. I wasn't having problems with my current project until I bumped up the resolution in various ways. Worked like a charm to improve frame rate for audio input to affect jitter shapes in hi-def!

Drastic Frame Drop (Max 7)