interface performance facts and myths

    Nov 13 2013 | 4:28 pm
    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
    • 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 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
      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 :)