Jitter in Max5 vs in Max7 - why max5 is WAY better


    Jul 03 2017 | 11:48 am
    Hi
    I am trying to use a jitter patch I made years ago (and which worked, I used in live etc etc). The patch was playing a movie, processing it with some effects.. nothing fancy
    Now when I play it in Max5 all works fine, the FPS are at around 30, or 29.... all good. But in Max7 (latest) it quickly drops to 5 or 6....
    it is on the same Mac, using the latest OS. In max7 I tried 32 and 64 bits, no changes, changed the jit.qt.movie object for jit.movie.... no changes..
    Has anyone an idea as to where to look?
    all the best
    kasper

    • Jul 03 2017 | 12:06 pm
      It is very difficult to say something valuable if we can't check the problematic patch...
      My personal experience leads me to the conclusion that in general Jitter in Max 7 is much more robust than the previous versions, but I can imagine, some constructions made in previous versions may need to be replaced to adapt the patch to today's requirements.
    • Jul 03 2017 | 12:31 pm
      Salut Kasper,
      did you try to use other codecs for your movie? What's the video engine you use?
      Do you use qmetro rather than metro?
      Overdrive off?
    • Jul 03 2017 | 12:34 pm
      I of course can send the patch, but there is not much in it which I would say is a problem or is problematic. Beside we tried the patch on some other computers, including a PC, the same problem is still there. The effect things are Jit.rgb2lume, Jit.brosca, jit.sprinkle, Jit.fluoride and jit.wake.... plus some jit.xfade... to have a similar fps in max7 that i have in max5 i have to throw away all processes (all objects) and then it begins to pay correctly. Of course the idea was to use the FX, in real time....
      So far i don't see the extra robustess of max7.
      many thanks
      kasper
    • Jul 03 2017 | 12:41 pm
      Thanks Patrick !
      we tried viddll, we tried avf, in max7 I tried playing with qmetro and jit.world. Will try the different codecs things
      kasper
    • Jul 03 2017 | 1:15 pm
      changing the codec (to MJPEG) did not changed much - actually nothing.....
    • Jul 03 2017 | 1:36 pm
      It could be useful to attach the patcher so that someone (Rob Ramirez?) of the C74 crew can take a look.
    • Jul 03 2017 | 1:52 pm
      here it is. Apart from maybe one emmanuel Jourdan object there should be no extra-things.
      thanks
      kasper
    • Jul 03 2017 | 3:13 pm
      On my 8-years old MacBookPro your patch works with full framerate when playing 320x240 pixels movies and slows down when playing higher resolutions. This is - in my personal opinion and of course I can be wrong - typical result for matrices-based video processing pipelines.
      I can't figure out why this patch slows down on Max7 (if it slows... maybe the files, you using now are just bigger [in terms of resolution] than files used before, with Max5?). However - to make the patch "future proof" and more friendly for hi-res videos - you may consider rebuild the project using jit.gl. stuff, which is more optimised to work with contemporary graphics cards (actually jit.gl objects are using GPU instead matrices processing objects based on CPU).
    • Jul 03 2017 | 5:41 pm
      hi Yaniki
      many thanks for taking the time. However, 320x240 is of course a poor resolution, and, yes the files I am using are much bigger/heavier. And yes, I am aware that with a heavier file, rendering suffers. However the main question here is why (on the same machine - actually we did teste on a few machines, including Macs and Window), using the very same files, the same patch, the same everything (which also means the same graphic card) we have a difference of some 27-30 fps (on max5) versus 5-6 on Max7.... here the only different thing is Max (same hardwares) So yes, even if you are right, probably about jit.gl - and i will test this - it does not seem to me that the question is about the new architecture (jit.gl) is more optimised, since the old one (using max5) works.
      anyhow - thanks again!!!
    • Jul 03 2017 | 6:40 pm
      Hmmm... lower performance on Max7 with the same video file is really strange. I can't explain this. At least at this moment nothing comes to mind. Maybe someone else will come up with a solution. Usually on this forum we find the solutions to most problems ;-)
    • Jul 04 2017 | 8:38 am
      this exactly the question : using the very same patch on the same machine (and this was tested on a few macs, not all having the same OS and on a window machine running window 10) with probably the same objects except jit.qt.movie (max5) becoming jit.movie in max7 in all cases max5 is better. Better yet, it is the same with another patch NOT using a movie as input but the couple shiva-vishnu for real-time generating... I did send this one patch as it is the one I want to start with on this new project, but I belive more and more that the question is not THIS specific patch......
      I don't know, to tell the truth
      Maybe just stick to max5 ?
    • Jul 04 2017 | 8:42 am
      On my old 2010 iMac, I don't see such a big difference in fps between Max5 and Max7 but there is one.
      The big difference between both Max versions is that even at ±9fps, Max5's interface is still reactive but Max7's is not.
    • Jul 04 2017 | 2:30 pm
      it has been occuring to me numerous times that a large patch, which was behaving correctly under max 5 (even 6 ?) ; begins to stutter unexpectedly and to lag a lot under max 7, expecially when creating new objects or browsing it and maybe especially when Jitter matrices were involved ; iirc it could have had an impact on Jitter performances. I think the "Snap to Objects" option might slow things down, but it's not the only thing.
    • Jul 06 2017 | 7:01 am
      Two things I found that helped increase the fps in max7. The first is to replace send/receive with actual connections. The other more dramatic improvement is to hide everything but the two screens. A difference between 5 and 7 is that in the latter the ui is animated. By setting the Refresh Rate in the preferences to an absurdly high value, it is possible to experience the extent of it. Otherwise I have no suggestions (I hardly use jitter) other than that it might be worthwhile to check out jit.gen.
    • Jul 06 2017 | 4:34 pm
      1. Your patch uses jit.(qt.)movie without arguments. Under Max 5, this will use a resolution of 320x240 no matter what resolution movie file you load, and all processing downstream will use that resolution. Under Max 7 it will adapt to the movie size. If your movie files are much larger than 320x240, you will see much slower framerates at that resolution. You should see this if you select the dim view from jit.fpsgui in your patch. To get Max 5 behavior and corresponding framerates, use jit.(qt.)movie 320 240. To get similar framerates with HD or 4k video under Max 7, output textures and process on the GPU rather than using the CPU based objects as your patch contains.
      2. Max 7 supports retina rendering, while Max 5 does not. Any UI or pwindows require rendering at 4x the number of pixels and similarly 4x the cost. This can slow patches down in order to provide higher resolution patcher graphics. If this is not desired, you can set the application to "open in low resolution", by setting the check box in the finder->get info window.
      In general to do the same thing, Max 7 should not be any slower than Max 5. If you do find performance issues when trying to do the same operation, please let us know.
      Apologies for any confusion due to hidden behavioral improvements of adapting to resolution, but many users requested this and we feel like it leads to a better user experience than the Max 5 default behavior.
    • Jul 08 2017 | 3:58 pm
      "If this is not desired, you can set the application to "open in low resolution", by setting the check box in the finder->get info window."
      i don't see such a check box (i don't have a retina screen), is there any other way to change this option ? And if not is it possible to, i don't know, maybe not have this on by default or make it changeable from within Max ? It feels like this option is activated, even if i don't have a retina screen.
    • Jul 08 2017 | 4:34 pm
      "open in low resolution" is only an option on retina machines, and Max will only encounter the higher costs of rendering associated with the 4x number of pixels On a retina machine. If you have an example where you are experiencing greater UI costs, we can take a look at it.
    • Jul 09 2017 | 3:15 am
      Hey Joshua, this ptch for example is very sloppy (when not in presentation mode)
    • Jul 09 2017 | 5:54 pm
      Sorry @vichug, but something about that patch isn't working for the forums. Maybe you can try again and if not, zip and attach?
    • Jul 09 2017 | 5:56 pm
      oh strange
      i try again :
    • Jul 09 2017 | 5:57 pm
      seems to work this time, maybe i didn't wait long enough for the upload
    • Jul 10 2017 | 10:28 pm
      This now loads and renders fine for me at 33fps in Max 7 with whatever default, but there are errors. I also have no idea to use the patch or what it's supposed to do since the documentation isn't included, or what is behaving differently in Max 7 vs earlier version.
      I'd suggest you take some time to clearly package up your example, and explain what you are experiencing and use a new thread for the discussion rather than this thread.
      text: can't find file help soundstroll.txt dict: file not found: movekeymap.json dict: file not found: movekeymapFlat.json
    • Jul 11 2017 | 12:38 am
      it's part of a max project and useless in itself, but the sluggishness of the interface is perceptible with just this patch (you can ignore the warnings of the console). I will download max 5 to test if it's also sluggish in max 5, because i fyou don't notice anything, maybe that's just me asking too much and my memory tricking me. The problem is not the jitter render btw, but the max patch. edit : sorry indeed for the thread hijacking
    • Jul 12 2017 | 2:15 pm
      @JOSHUA - many thanks, actually the answer you gave me about the difference between the 2 maxes makes sense : I must explain that the inclusion of "jit.(qt).movie" was made only for the exemple as the original patch was not fed by a movie but by a live, Fire-wire camera (I suppose there might be the same trick of adjusting the def in jit.grab or something). now that I made a jit.qt.movie 1920 1080 the max5 is at 3.9 fps and Max7 at 5.1... so it all makes sense (yes I did work on it all since, using open GL, chnaging the codec etc etc...)
      However in another patch I use I still find a better performance in max5 than max7. it is a "generative" (kind of) patch, with no input. on max5 it runs between 16.5 and 22.1 (yes big changes !) when on max7 it was never better than 15.. Ok close but max 5 is better.... in order to run the patch press the ->/ (don't know the name of that key) which inits it all, then the space bar for on-off. As said your explaination makes sense to me, but I would hope for the same or better fps in max7. when checking the fps, now, I did not use an extra screen, even if the patch is designed to run with one. Here it was just the computer's screen - a mac with, yes, a retina screen
      many thanks again
      kasper
    • Jul 13 2017 | 12:07 am
      If you change your main metro to 2ms (500 fps) and the jit.window (or jit.world) to "sync 0" (vsync off), you should see some gains. I've tested your patch and these changes have risen the fps from 15 to almost 25. Not related to the Max 5/7 discussion, but if you draw the lines from the particle system using OpenGL (jit.gl.mesh in line mode for instance) instead of drawing directly to matrix based objects (CPU), you should see significant performance and quality gains higher fps and resolutions).