interface performance facts and myths
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
Check the refresh rates for your objects. Most are set to 1 ms by default.
Can you give me an example of an objects that has that?
Can't find it in inspector or attribute lists...
It's the "update limit" parameter in M4L controls. Some things may not need to be updated every 1 ms.
@ 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
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...
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 :)