yurki

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

About performance and interface, this is what I think

- hidden interface objects are slow (they are sort of still

- 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

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

(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)

interface-performance-facts-and-myths

Check the refresh rates for your objects. Most are set to 1 ms by default.

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...

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.

It's the "update limit" parameter in M4L controls.  Some things may not need to be updated every 1 ms.


"- hidden interface objects are slow (they are sort of still

This is incorrect. Hidden interface elements are not drawn. If you can empirically show other wise we would be very keen to see it

"- hidden interface objects are slow (they are sort of still
drawn)"

I finally got time to get back into this...

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.

- 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.

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

whatever is going on prolly came to light because it's copied 36 times,

hope anyone can shed some light on this one.....it really seems like a m4l bug to me.

- 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

- 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...

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 

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...


I magically solved it by removing the whole live.dial

I later checked all the properties of both the old and the fresh

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 :)

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 :)


interface performance facts and myths