interface performance facts and myths


    Nov 13 2013 | 4:28 pm
    hello
    I'm developing a pretty big m4l device (but this
    question should relate to maxmsp in general) with
    an intensive interface and while building I'm
    it's starting to be less responsive.
    About performance and interface, this is what I think
    so far (but correct me if I'm wrong):
    - hidden interface objects are slow (they are sort of still
    drawn)
    - putting bpatchers in bpatchers (etc) is okay, its the content of the bpatchers that counts in performance.
    - interface objects that ore not set hidden but are outside of the screen (like in a bpatcher with stuff out of the frame because of offset) are not drawn and therefore not slowing the patch down.
    - objects not in presentation mode present are not drawn
    any opinions, more info or other tips related to performance and interface?
    (btw, I didn't plan to change scheduler settings because since
    MIDI is still the priority + it should work well on every
    computer out of the box)
    thanks in advance

    • Nov 13 2013 | 4:48 pm
      Check the refresh rates for your objects. Most are set to 1 ms by default.
    • Nov 13 2013 | 5:11 pm
      Can you give me an example of an objects that has that?
      Can't find it in inspector or attribute lists...
    • Nov 13 2013 | 5:30 pm
      It's the "update limit" parameter in M4L controls. Some things may not need to be updated every 1 ms.
    • Nov 13 2013 | 7:24 pm
      @ Yurki said
      "- hidden interface objects are slow (they are sort of still
      drawn)"
      This is incorrect. Hidden interface elements are not drawn. If you can empirically show other wise we would be very keen to see it
      Cheers
      Andrew
    • Nov 30 2013 | 4:38 am
      hey, thanks for the reply's!
      I finally got time to get back into this...
      @peter
      found it! that's a good thing to know
      But now I understand more why the whole interface is
      slow: its actually ONLY the hidden live.dial.
      (combined with an overall busy patch of course)
      I didn't manage to isolate the problem in a patch with the hidden object
      (sorry andrew) because I simply can't get the same cpu load in a simple patch I think.
      Nevertheless I tested a few things so I can say these with some certainty.
      Here's what's going on:
      - I have a subpatch that the user can open in which you have 36 copies
      of the same bpatcher in another bpatcher (so 2 levels).
      the deepest level (which has 36 copies next to each other) has a few objects
      in top of each other (its a way to have the interface function as I want).
      On the top of these objects is a live.dial.
      - since I only want to use the live.dial if the user wants to
      map something internal in live, it stays normally hidden.
      - when live transport is going and the patch is busy (its a sequencer),
      the interface becomes slow. both when live.dial is visible or not.
      and here for the weird part:
      at the moment I move the live.dial in the bpatchers patch so its
      NOT visible in the interface anymore, the patch becomes fast!
      I double checked if data is coming in or out of the live.dial, but
      nothing. also there is no automation in live to send to the live.dial.
      I expected the live.dial not to slow things down both hidden and not hidden
      since it doesn't seem to do anything. when it's hidden I even would more expect
      it wouldn't slow stuff down, but it still does. Now, again, at the moment I
      move the live.dial out of the visual rectangle of the bpatcher, the whole interface
      is fast again.
      whatever is going on prolly came to light because it's copied 36 times,
      so a slight slow down happens 36x times
      hope anyone can shed some light on this one.....it really seems like a m4l bug to me.
      some last things:
      - I tried to put the update limit 1000ms of the live.dial. I noticed a small increase
      in responsiveness of the interface, but not much. I also noticed that
      when the transport is stopped and the patch is not doing stuff, the live.dial
      updates visually super fast, so I guess the update limit only is about
      automation...
      - as to be expected, when I remove 3/4 of the the 36 patches, it becomes fast again.
      it's the total of 36 that's slowing it down...
    • Nov 30 2013 | 10:00 pm
      okay!
      I magically solved it by removing the whole live.dial
      and replacing it by a new one.
      I later checked all the properties of both the old and the fresh
      live.dial, set it exactly the same.
      my guess is that it received some property setting which is not
      in the default inspector list and wasn't there in the patch anymore
      while it still was saved with it, or, it was a max4live bug....
      can't believe the problem was that easy to solve :s, should have tried to reset
      the object before. oh well, happens, Im happy :)