Drastic Frame Drop (Max 7)
Is anyone else experiencing this issue?
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
Max 7.0.3 (1caa69f) (64-bit mac)
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.
-- Pasted Max Patch, click to expand. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 2457.3oc2aksjihiE8YmeEDD0iY6.I1mmp46niNbvhrspBiXPhrxZ5n+2Gsg Mfgz.F6gLiHSuHIKc0QWc24ueYiYL4cD0z3eY7mFa172urYirIQCazeei4on 2SxhnxgYli9EI9Glup5hgdmIa9GX11CYaOFkmlgL9dTEirqjvhXHCP8fyqNg yyPL4DAzMVDwRNhyOrqDkvTDBv0Yq0qFN11h2.9Vh2f7uX7W5eDNUtnbB4OZ N6jJV8zC0sRY+NCIGb83TCh86BjZ03cv+23uD89Ou7h3kWGIVbBQoQGPWAFj 86oHlw2.FeCZ7M6WMhixOzKJ.GFEbsCja+Pe4a1vqPg8jbFE+ek6Cf.qtBbf NlMFadzIET7uKwQY8iafIfayByRHmNgxYWgYB.Kd+ACE1MUVFGN73xQIGfDr rTfk6sAq3p3X0FEzCuU3TgOqAgO0BQwoxlsWXjilDkgZuTEDbtb.VagfIBm1 tx6b.nj2yyUdcz5dQyfGEZBWZ9vHJlZruJOggI4SkWDZ2D7..ukA87+rfdoX dWTNvYH2iCwTZELU0BVsvUHXQvUu0DrxWoXTo4LAFuPwatVyPQg8sQghnRd6 LT4NTdjFOsVBcuRkiyRWhvnihegySI+ZxWR0vTfjKJP9EOq9MwvE9w1XLjEE 0+nZ3rxOzyxBBbsLWvqbonLVjQLh8KDhekK5TAmGbpvgKPowTIpG34rH5OcA KvkqkT5TU49nDjAWFDpjhlkz8ZjRabpyxXogS3JCo36b9RaPqhSwugkRy4W9 ORRmLdYADVlA0lwFrLbVNAqK7JgjQJMNfxQkQLopO4xLOrx1UxTAbcWFrxes gUmNwQHRrcpQDiUhiqXyQhUf.qbrBUNIBVFrx6+OXk.Gpv0qf3apqgmHD1wc ziQo3A7fDzfdEB2ZRS8YYen1XdErAkJ9b7ljwBNivqRwo8tegSYGkyCHbq0G 5uIoDy4Uj2cltanMfs83LtrccWonBN5oMW40qgSCyL7giLABcYPEjreu6DQX D2brIYf3iTThJP4oFxIdpdioNyrgRYmpuLQ66b.qt.ATwENTMSn.FpXes9vP C4.GisqEB1F048kktMVXWO2LzIcvxLSphEBsLLeU7BCwJitvINBPS3Gzq2Sv mtAilHBbRsRykayOrg6qSjcC70hcyVEPxawtY+.Y2xIkmDXmleSYl+ykgann cx82WFpSweyKTm0NvpuUCmiDN60WnN2mQ3q3MzZyOVknf2siDri878u25SoC 9KEB5wgN26CAgAeJQvgzRD8SCqsp+5EdsuM6nu07usB8+5daMDbu2VgteJ40 FRAgL4D2oJh5LRTmMrYwzY+kkoqFdtiP.CAeoDvoMCVlJm4lAGEyVn8br.18 qgEv0Pg2Xb3B38Ps.FSQaSPYWrBV0TJlxHkLTZm1OTxcyGor5sQyuQJI7O0s 0nrJ9rWEiSnEY3bT+8SxeijUohabq9o7cLs8.VCdCJxPRRFtXlG6PckXLKos SNTZSPlAeesiKUrD+9CAxDEh.vfKbNhYCMp+atfnNgktf4fhgedQwK0CDlR9 iD16FeuYD4tTXPh6aIjJUlggyKSd1Jwz5HZJLQcBnrq0CDkeTXKGTEIz5B3x +PF5MTF2ld2tPsw2aG7SQKcB94RcdXqiorTzgMvcFmG9qct9gL0ceUVFMoTj I1uAldXPTAdS9VPvbr5.t5r5fQNbX5YBSCEZEON0u1qQG1S25TvzzLunFlZf nI8BGV2DN.Ap5hbNbFOxviosduI8qxAylyXCecwBgSkz1Y3YiYTQQil2z3mH .zePjSj+qmaBmqZx5bSkHUFpaX4nXdK4nHiCgUkJx+cuZLPLMb6OKyqvRRQ0 H+n8k5I7hxEYggHM90yQIXKnQYhvYBNjQR9IJsIIYR39dfy49fPalTqycmh1 GUkw105XCts296jSu1c1643FyCk3TtMtbhnERKZtd4DUYqxpjlaF4HxiJ54G yYh3nx.cR4axJZbTo3fPeyCV2IiPxZ204eWFZOS2cANOuCJxHEC2YoP40vcG S3cd5ilaYOzcU4pd2wu3x1QidqMZyhxxz2jaO8uGki4ZQPLr5H.ZctSkzmib 8.DtyJM2upddqmdR47vInyIL0pIy.e33hZlHyymxo3CHJqcarnCz1sb00WdS Uw56n639WUjw2EsGPqhBu4Exlx7Z0dGYeJIDmusMff+AsfPWjHvy0JR6L62U 1VPmE55ryO.RHZstJENm49M0h50xDlIDzR7e2hjLy3b.PGzBgafN.a+FJCr5 fNCHYoqyElc9I8KOYPqs9.XsecDWr25wix+D86AgXqwAwJ0ttgxBXZdPLXtP ryzgXcPDt9sdg7KR8El6Ov0cI3HCGRumETRUYR8xq4nLZCSbwWbeLNqC7OOe ksy3NhSSQ4cObRwTgDSkr6Qw2LUJFLRJFtPTbSKG3lDkIyQ+t5SQyKAspmQI eEnHJqsN1tvPmWEexC563J+TXfkcHm0ssIJclBX8T.Cs.gdhensE+W5n9DuI vslh6ZF3hBz1H32PQWyQTTRJHkmMbZqc3KMMQyTnmNcmxljcMJhrN1bNIcmb C4hixzZFOeM8iTjdQa6KWNkWNe7UU1bs+8yzEJUEL..yI3SfGYXQ5nPXQCMR IJmad+8gbv.OExENCjK7yFvwLhMPkQzY5oNDpbQZNtlF7DvJ0V6oG.CcZS93 .X3+oJ9E+GNEVRLtTPISK5V5Z7weNhibe7gvXNODJzKEt6D4NTO0IttmM17L XDSJSQMCyQelsyW5nxChz5wnWhsYiPCaJlV2KHLNCcF1NhxJRQrHbFc6Onig EDeHmv2BY3jeNbl6.KazCGntnqiz8BVQzPa8wfybJuJ+oVQzxDqc+AjsNf8D 8YxxAwnBJN6FOdLSDg87uCDNX8gvxNa68jBv65ChF1+XeOFvuCQpPZLnqb53 ZGNt57erjSvHHmmK0.VMTi+HvF2mF0HxW4ZhywcDjSvSiZDOeJqIzQTX32jU F.tA8bBmJe5o0xZbbzkou9wK2Q9ji427I4YA2AvQrCbl4Nn9A4VsCffGyNXk Iq0NXkQO9qL5w4SH8.ehzyXz..8edzyHHmNX3ijb5bRL.7387nmfwdbAeNzy XttCehmWdqqq6ihdbgOO5wcr7OfmC8rxDGBsWYzyXL2nCQ+HoGQkYeaSPcml Abv.cH8zNzKySp7aO.C3.tqqSXvXtA.dhmvi4F.34IwpyRM.8X87nmGpC.pP A0oT1DjRmRXqS4qccoqMbYq0sj03q7+7x+CPhparl -----------end_max5_patcher-----------
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.
are you running under 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
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.
yes i am currently using Yosemite
however, we were recently made aware of an fps slowdown when patchers are unlocked when running Yosemite.
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).
hope this helps.
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.
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!
Forums > Jitter