unbelievable

Jan 12, 2008 at 1:56am

unbelievable

i just removed two number boxes that were still in my patch from
debugging two years ago, and my framerate when using external controls
just doubled.

number boxes kill framerate! this is a reminder from your friendly
neighborhood goldberg. that is all.

j

#35328
Jan 12, 2008 at 2:06am

I wonder if that even affects the speed if the numbers are hidden by the
jitter window (probably yes?) or are in a closed subpatch (probably no?)
do you know anything about that.
otoh, I can’t believe deleting two numberboxes can *double* your
framerate…
marius.

joshua goldberg wrote:
> i just removed two number boxes that were still in my patch from
> debugging two years ago, and my framerate when using external controls
> just doubled.
>
> number boxes kill framerate! this is a reminder from your friendly
> neighborhood goldberg. that is all.
>
> j
>

#120293
Jan 12, 2008 at 2:15am

it doesn’t matter if the numbers are in hidden subpatches or
abstractions or whatever. get rid of them and your framerate will
*soar*.

i had twenty instances of an abstraction with two number boxes that
were being hit by every midi input.

framerate during midi input went from 15 to 30.

On Jan 11, 2008, at 9:06 PM, marius schebella wrote:

> I wonder if that even affects the speed if the numbers are hidden by
> the jitter window (probably yes?) or are in a closed subpatch
> (probably no?)
> do you know anything about that.
> otoh, I can’t believe deleting two numberboxes can *double* your
> framerate…
> marius.
>
> joshua goldberg wrote:
>> i just removed two number boxes that were still in my patch from
>> debugging two years ago, and my framerate when using external
>> controls just doubled.
>> number boxes kill framerate! this is a reminder from your friendly
>> neighborhood goldberg. that is all.
>> j
>
>

#120294
Jan 12, 2008 at 2:36am

what about numbers that are not connected to an outlet. do these also
cause trouble by getting “refreshed”?
marius.

joshua goldberg wrote:
> it doesn’t matter if the numbers are in hidden subpatches or
> abstractions or whatever. get rid of them and your framerate will *soar*.
>
> i had twenty instances of an abstraction with two number boxes that were
> being hit by every midi input.
>
> framerate during midi input went from 15 to 30.
>
>
> On Jan 11, 2008, at 9:06 PM, marius schebella wrote:
>
>> I wonder if that even affects the speed if the numbers are hidden by
>> the jitter window (probably yes?) or are in a closed subpatch
>> (probably no?)
>> do you know anything about that.
>> otoh, I can’t believe deleting two numberboxes can *double* your
>> framerate…
>> marius.
>>
>> joshua goldberg wrote:
>>> i just removed two number boxes that were still in my patch from
>>> debugging two years ago, and my framerate when using external
>>> controls just doubled.
>>> number boxes kill framerate! this is a reminder from your friendly
>>> neighborhood goldberg. that is all.
>>> j
>>
>>
>
>

#120295
Jan 12, 2008 at 3:48am

yes.

On Jan 11, 2008, at 9:36 PM, marius schebella wrote:

> what about numbers that are not connected to an outlet. do these
> also cause trouble by getting “refreshed”?
> marius.
>
> joshua goldberg wrote:
>> it doesn’t matter if the numbers are in hidden subpatches or
>> abstractions or whatever. get rid of them and your framerate will
>> *soar*.
>> i had twenty instances of an abstraction with two number boxes that
>> were being hit by every midi input.
>> framerate during midi input went from 15 to 30.
>> On Jan 11, 2008, at 9:06 PM, marius schebella wrote:
>>> I wonder if that even affects the speed if the numbers are hidden
>>> by the jitter window (probably yes?) or are in a closed subpatch
>>> (probably no?)
>>> do you know anything about that.
>>> otoh, I can’t believe deleting two numberboxes can *double* your
>>> framerate…
>>> marius.
>>>
>>> joshua goldberg wrote:
>>>> i just removed two number boxes that were still in my patch from
>>>> debugging two years ago, and my framerate when using external
>>>> controls just doubled.
>>>> number boxes kill framerate! this is a reminder from your
>>>> friendly neighborhood goldberg. that is all.
>>>> j
>>>
>>>
>

#120296
Jan 12, 2008 at 5:26am

> number boxes kill framerate! this is a reminder from your friendly
> neighborhood goldberg. that is all.

I apologize, Joshua. I thought you were full of it. Now this big patch works.

Keith

#120297
Jan 12, 2008 at 5:38am

The only thing Joshua is full of is THE AWESOME. And uh, the insane
too… and wait, also LOTS OF CRAZY MANIC ENERGY.

ok he is full of a lot of stuff but not ‘it’.

On Jan 12, 2008, at 12:26 AM, keith manlove wrote:

>> number boxes kill framerate! this is a reminder from your friendly
>> neighborhood goldberg. that is all.
>
> I apologize, Joshua. I thought you were full of it. Now this big
> patch works.
>
> Keith

#120298
Jan 12, 2008 at 10:42pm

number boxes really are a mixed blessing, aren’t they? I mean, debugging tool, quick visualizer, and total flow killer, source of endless rounding errors.

I remember trying to make a matrix mixer that had about 100 number boxes going on… then the change of efficiency when I involved jit.cellblock!!! wow.

#120299
Jan 12, 2008 at 11:12pm

If I want to have PATTR control of a bunch of variables, what is the best way to implement that. What is the still pattr-able substitute for a number box?
Simple example would be 10 objects with editable xposition, yposition, xscale, yscale type information for each object that is then saved as presets with pattrstorage. Would Jit.cellblock still allow me to crossfade between presets smoothly?

#120300
Jan 13, 2008 at 1:44am

pattr works well for this.

b

On Jan 12, 2008, at 3:12 PM, Leo Mayberry wrote:

>
> If I want to have PATTR control of a bunch of variables, what is the
> best way to implement that. What is the still pattr-able substitute
> for a number box?
> Simple example would be 10 objects with editable xposition,
> yposition, xscale, yscale type information for each object that is
> then saved as presets with pattrstorage. Would Jit.cellblock still
> allow me to crossfade between presets smoothly?
>


Barry Threw
Media Art and Technology

San Francisco, CA
Work: 857-544-3967
Email: bthrew (at) gmail (dot) com
IM: captogreadmore (AIM)

http://www.barrythrew.com

“The greatest of the changes that science has brought us is the acuity
of change; the greatest novelty the extent of novelty.”
- J. Robert Oppenheimer

#120301
Jan 16, 2008 at 1:23am

are there the same issues with prepend set to a message box?

#120302
Jan 16, 2008 at 1:53am

Yes – to some extent. Use v or value, or pattr. Anything with GUI
updates, hidden or not = DO NOT WANT.

On Jan 15, 2008, at 8:23 PM, Parag K Mital wrote:

> are there the same issues with prepend set to a message box?

#120303
Jan 17, 2008 at 8:18pm

I laughed so hard last night…
For some time I have been struggling with Jittery video from
Jitter…

All I wanted to do was to very rapidly playback very short clips (and extract ALPHA) via triggering from GPI, MIDI, or whatever…

When I create my patches I always use KEY object instead of
NOTEIN (NOTEIN to be used with GPI to MIDI converter) because I
dont want to carry MIDI keyboard everywhere while testing
trigger interactivity… so I test interactivity with keyboard input.

Long story short – Qwerty KEYBOARD triggering (via KEY obj) of
clips results in jittery playback… if I replace the KEY
objects with NOTEIN objects… playback is smooth!!!

I guess KEY object screws with scheduler or something…
much more so than NOTEIN object.

Yes, yes, yes, I am aware of VADE’s recent posts to minimize
jittery playback… tips like QMETRO, UNIQUE, etc…
all awesome tips indeed – I use’um :>

This most simple patch uses METRO2 and does not use UNIQUE
(unique = message or atttribue (I forget) of Jit.movie.

I will test this further but my point is that triggering clips
via qwerty-keyboard input may be yet another culprit in
Jittery playback…

Anyone else know about this???

#120304
Jan 17, 2008 at 8:29pm

Like the existence of any key object is the problem? Interesting, because I always have at least one in there for taking my window output to fullscreen. Or do you specifically mean a key object tied into triggering of quicktime?

#120305
Jan 17, 2008 at 8:32pm

can you send a very simple patch demonstrating this? because i am
extremely skeptical.

On Jan 17, 2008, at 3:18 PM, robert vanrhyn wrote:

>
> I laughed so hard last night…
> For some time I have been struggling with Jittery video from
> Jitter…
>
> All I wanted to do was to very rapidly playback very short clips
> (and extract ALPHA) via triggering from GPI, MIDI, or whatever…
>
> When I create my patches I always use KEY object instead of
> NOTEIN (NOTEIN to be used with GPI to MIDI converter) because I
> dont want to carry MIDI keyboard everywhere while testing
> trigger interactivity… so I test interactivity with keyboard input.
>
> Long story short – Qwerty KEYBOARD triggering (via KEY obj) of
> clips results in jittery playback… if I replace the KEY
> objects with NOTEIN objects… playback is smooth!!!
>
> I guess KEY object screws with scheduler or something…
> much more so than NOTEIN object.
>
> Yes, yes, yes, I am aware of VADE’s recent posts to minimize
> jittery playback… tips like QMETRO, UNIQUE, etc…
> all awesome tips indeed – I use’um :>
>
> This most simple patch uses METRO2 and does not use UNIQUE
> (unique = message or atttribue (I forget) of Jit.movie.
>
> I will test this further but my point is that triggering clips
> via qwerty-keyboard input may be yet another culprit in
> Jittery playback…
>
> Anyone else know about this???
>
>

#120306
Jan 17, 2008 at 8:38pm

yes –
i mean using key object to trigger quicktime playback via
jit.movie…
..assuming your metro2 object never stops.

I’m at work now but when I get home I will make most simple
test patch then upload for others to test… it was very late
when I came across this… I will test on MAC and PC

I just started to laff then went to bed :<

#120307
Jan 17, 2008 at 10:27pm

Hi Folks,

Since I’ve heard conflicting information in the past on this subject, I’d like to be perfectly clear on this.

Is it correct that any lowly number box, even if hidden in some unopened sub-patch whose state has not been changed since the Babylonians, will still be updated by the Max scheduler and thus drain CPU?

I can understand how using [value] and/or [pattr] to display numbers via [prepend set] to a messages boxes would be less prone to GUI updates, but how does this help one with data that needs to be changed by the user as in the previous post? Does dropping an [autopatter @autoname 1] into that same sub-patch cause its state to only be updated when it changes?

BTW, I have noticed significant reduction in frame rates using signal level meters, multi-sliders, pwindows, and all the usual suspects. My solution is to use a ‘GUI switch’ which is a gate (and gate~) for all of the above so that you can use the GUI’s to view all those things you would like to in your patch, but if the frame rates drop too low, you can cut them off and watch the frame rates soar. This is why I’m skeptical that number boxes whose states are not changing will eat up CPU, but I’m no expert.

Christopher

#120308
Jan 18, 2008 at 2:36am

your problem is metro 2 and no @unique 1.

Metro does not drop frames at low priority like qmetro.

This will output matrices AS FAST AS POSSIBLE. Metro 2 is EXCEEDINGLY
fast. 60fps is metro 16(ish). Most likely your screen does not redraw
faster than 60 hz vertically.

I suggest unique 1
Qmetro 16

I too am very skeptical, cause I use key in my max patch in multiple
places to no detriment that I can measure.

On Jan 17, 2008, at 3:38 PM, robert vanrhyn wrote:

>
> yes -
> i mean using key object to trigger quicktime playback via
> jit.movie…
> ..assuming your metro2 object never stops.
>
> I’m at work now but when I get home I will make most simple
> test patch then upload for others to test… it was very late
> when I came across this… I will test on MAC and PC
>
> I just started to laff then went to bed :<
>

#120309
Jan 18, 2008 at 3:29am

this thread is full of voodoo, voodo and caps-lock

On Jan 18, 2008 4:36 AM, vade wrote:

> your problem is metro 2 and no @unique 1.
>
> Metro does not drop frames at low priority like qmetro.
>
> This will output matrices AS FAST AS POSSIBLE. Metro 2 is EXCEEDINGLY
> fast. 60fps is metro 16(ish). Most likely your screen does not redraw
> faster than 60 hz vertically.
>
> I suggest unique 1
> Qmetro 16
>
> I too am very skeptical, cause I use key in my max patch in multiple
> places to no detriment that I can measure.
>
> On Jan 17, 2008, at 3:38 PM, robert vanrhyn wrote:
>
> >
> > yes -
> > i mean using key object to trigger quicktime playback via
> > jit.movie…
> > ..assuming your metro2 object never stops.
> >
> > I’m at work now but when I get home I will make most simple
> > test patch then upload for others to test… it was very late
> > when I came across this… I will test on MAC and PC
> >
> > I just started to laff then went to bed :<
> >
>
>

#120310
Jan 18, 2008 at 4:33am

you keep saying voodoo, and I keep asking why, and get no response. :P
punk!

On Jan 17, 2008, at 10:29 PM, yair reshef wrote:

> this thread is full of voodoo, voodo and caps-lock
>
> On Jan 18, 2008 4:36 AM, vade wrote:
> your problem is metro 2 and no @unique 1.
>
> Metro does not drop frames at low priority like qmetro.
>
> This will output matrices AS FAST AS POSSIBLE. Metro 2 is EXCEEDINGLY
> fast. 60fps is metro 16(ish). Most likely your screen does not redraw
> faster than 60 hz vertically.
>
> I suggest unique 1
> Qmetro 16
>
> I too am very skeptical, cause I use key in my max patch in multiple
> places to no detriment that I can measure.
>
> On Jan 17, 2008, at 3:38 PM, robert vanrhyn wrote:
>
> >
> > yes -
> > i mean using key object to trigger quicktime playback via
> > jit.movie…
> > ..assuming your metro2 object never stops.
> >
> > I’m at work now but when I get home I will make most simple
> > test patch then upload for others to test… it was very late
> > when I came across this… I will test on MAC and PC
> >
> > I just started to laff then went to bed :<
> >
>
>

#120311
Jan 18, 2008 at 4:35am

No.

The thing is, if the number box is constantly being sent updates, then
it will be part of the scheduler, and max will take time to re-draw it.

If a numberbox is not a UI element meant for interaction, remove/
replace it, or use [qlim] and limit the amount of updates per second
the objects get.

On Jan 17, 2008, at 5:27 PM, Christopher Keyes wrote:

>
> Is it correct that any lowly number box, even if hidden in some
> unopened sub-patch whose state has not been changed since the
> Babylonians, will still be updated by the Max scheduler and thus
> drain CPU?
>

#120312
Jan 18, 2008 at 12:47pm

some of this thread content is speculations at best, with no patch worthy
proof behind it.
i understand the logic behind qlimiting ui objects but that key statement
needs more then caps lock to make it a sticky.
and i like the v word.

On Jan 18, 2008 6:33 AM, vade wrote:

> you keep saying voodoo, and I keep asking why, and get no response. :P
> punk!
>
>
>
>
> On Jan 17, 2008, at 10:29 PM, yair reshef wrote:
>
> this thread is full of voodoo, voodo and caps-lock
>
> On Jan 18, 2008 4:36 AM, vade wrote:
>
> > your problem is metro 2 and no @unique 1.
> >
> > Metro does not drop frames at low priority like qmetro.
> >
> > This will output matrices AS FAST AS POSSIBLE. Metro 2 is EXCEEDINGLY
> > fast. 60fps is metro 16(ish). Most likely your screen does not redraw
> > faster than 60 hz vertically.
> >
> > I suggest unique 1
> > Qmetro 16
> >
> > I too am very skeptical, cause I use key in my max patch in multiple
> > places to no detriment that I can measure.
> >
> > On Jan 17, 2008, at 3:38 PM, robert vanrhyn wrote:
> >
> > >
> > > yes -
> > > i mean using key object to trigger quicktime playback via
> > > jit.movie…
> > > ..assuming your metro2 object never stops.
> > >
> > > I’m at work now but when I get home I will make most simple
> > > test patch then upload for others to test… it was very late
> > > when I came across this… I will test on MAC and PC
> > >
> > > I just started to laff then went to bed :<
> > >
> >
> >
>
>
>
>
>
>

#120313
Jan 18, 2008 at 2:23pm

i made a little test patch with plenty of numboxes in it, 150 to be
precise. i didn’t optimize anything in the playback on purpose.
there is absolutely no difference in the framerate when i delete the
number boxes, it stays around 14fps (macbook pro 2.33ghz core2duo).
only if i update them using the additional metro or by changing
values the framerate goes way down. looks like it isn’t the sheer
existence but only the rate at which they’re updated.

best, dominik

#P toggle 402 44 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 402 69 46 196617 metro 2;
#P message 32 341 124 196617 ff 0.1 , fb 0.6 , bleed 0.15;
#P message 32 381 103 196617 x_step 44 , y_step 0;
#P message 31 217 30 196617 read;
#P newex 289 410 42 196617 jit.plur;
#P message 31 297 169 196617 glow 0.33 0.74 1. , lum 0.2 , tol 0.1;
#P toggle 268 195 15 0;
#P newex 289 370 45 196617 jit.wake;
#P user jit.fpsgui 380 339 60 196617 0;
#P newex 289 467 129 196617 jit.window @size 640 480;
#P newex 289 339 55 196617 jit.fluoride;
#P newex 268 220 46 196617 metro 2;
#P newex 268 260 105 196617 jit.qt.movie 640 480;
#P number 764 553 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 534 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 515 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 496 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 477 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 458 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 439 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 420 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 401 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 382 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 363 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 344 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 325 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 306 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 287 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 268 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 249 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 230 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 211 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 192 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 173 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 154 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 135 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 116 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 764 98 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 553 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 534 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 515 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 496 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 477 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 458 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 439 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 420 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 401 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 382 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 363 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 344 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 325 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 306 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 287 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 268 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 249 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 230 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 211 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 192 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 173 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 154 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 135 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 116 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 719 98 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 553 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 534 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 515 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 496 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 477 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 458 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 439 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 420 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 401 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 382 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 363 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 344 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 325 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 306 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 287 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 268 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 249 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 230 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 211 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 192 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 173 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 154 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 135 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 116 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 674 98 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 553 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 534 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 515 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 496 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 477 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 458 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 439 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 420 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 401 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 382 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 363 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 344 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 325 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 306 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 287 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 268 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 249 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 230 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 211 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 192 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 173 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 154 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 135 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 116 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 629 98 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 553 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 534 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 515 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 496 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 477 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 458 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 439 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 420 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 401 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 382 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 363 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 344 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 325 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 306 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 287 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 268 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 249 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 230 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 211 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 192 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 173 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 154 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 135 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 116 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 584 98 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 553 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 534 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 515 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 496 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 477 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 458 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 439 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 420 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 401 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 382 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 363 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 344 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 325 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 306 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 287 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 268 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 249 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 230 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 211 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 192 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 173 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 154 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 135 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 116 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 539 98 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 2;
#P comment 161 262 100 196617 just some filters to stress the cpu;
#P fasten 151 0 153 0 273 302 294 302;
#P fasten 151 0 155 0 273 293 385 293;
#P connect 149 0 150 0;
#P connect 148 0 149 0;
#P connect 147 0 148 0;
#P connect 146 0 147 0;
#P connect 145 0 146 0;
#P connect 144 0 145 0;
#P connect 143 0 144 0;
#P connect 142 0 143 0;
#P connect 141 0 142 0;
#P connect 140 0 141 0;
#P connect 139 0 140 0;
#P connect 138 0 139 0;
#P connect 137 0 138 0;
#P connect 136 0 137 0;
#P connect 135 0 136 0;
#P connect 134 0 135 0;
#P connect 133 0 134 0;
#P connect 132 0 133 0;
#P connect 131 0 132 0;
#P connect 130 0 131 0;
#P connect 129 0 130 0;
#P connect 128 0 129 0;
#P connect 127 0 128 0;
#P connect 126 0 127 0;
#P connect 125 0 126 0;
#P connect 124 0 125 0;
#P connect 123 0 124 0;
#P connect 122 0 123 0;
#P connect 121 0 122 0;
#P connect 120 0 121 0;
#P connect 119 0 120 0;
#P connect 118 0 119 0;
#P connect 117 0 118 0;
#P connect 116 0 117 0;
#P connect 115 0 116 0;
#P connect 114 0 115 0;
#P connect 113 0 114 0;
#P connect 112 0 113 0;
#P connect 111 0 112 0;
#P connect 110 0 111 0;
#P connect 109 0 110 0;
#P connect 108 0 109 0;
#P connect 107 0 108 0;
#P connect 106 0 107 0;
#P connect 105 0 106 0;
#P connect 104 0 105 0;
#P connect 103 0 104 0;
#P connect 102 0 103 0;
#P connect 101 0 102 0;
#P connect 100 0 101 0;
#P connect 99 0 100 0;
#P connect 98 0 99 0;
#P connect 97 0 98 0;
#P connect 96 0 97 0;
#P connect 95 0 96 0;
#P connect 94 0 95 0;
#P connect 93 0 94 0;
#P connect 92 0 93 0;
#P connect 91 0 92 0;
#P connect 90 0 91 0;
#P connect 89 0 90 0;
#P connect 88 0 89 0;
#P connect 87 0 88 0;
#P connect 86 0 87 0;
#P connect 85 0 86 0;
#P connect 84 0 85 0;
#P connect 83 0 84 0;
#P connect 82 0 83 0;
#P connect 81 0 82 0;
#P connect 80 0 81 0;
#P connect 79 0 80 0;
#P connect 78 0 79 0;
#P connect 77 0 78 0;
#P connect 76 0 77 0;
#P connect 75 0 76 0;
#P connect 74 0 75 0;
#P connect 73 0 74 0;
#P connect 72 0 73 0;
#P connect 71 0 72 0;
#P connect 70 0 71 0;
#P connect 69 0 70 0;
#P connect 68 0 69 0;
#P connect 67 0 68 0;
#P connect 66 0 67 0;
#P connect 65 0 66 0;
#P connect 64 0 65 0;
#P connect 63 0 64 0;
#P connect 62 0 63 0;
#P connect 61 0 62 0;
#P connect 60 0 61 0;
#P connect 59 0 60 0;
#P connect 58 0 59 0;
#P connect 57 0 58 0;
#P connect 56 0 57 0;
#P connect 55 0 56 0;
#P connect 54 0 55 0;
#P connect 53 0 54 0;
#P connect 52 0 53 0;
#P connect 51 0 52 0;
#P connect 50 0 51 0;
#P connect 49 0 50 0;
#P connect 48 0 49 0;
#P connect 47 0 48 0;
#P connect 46 0 47 0;
#P connect 45 0 46 0;
#P connect 44 0 45 0;
#P connect 43 0 44 0;
#P connect 42 0 43 0;
#P connect 41 0 42 0;
#P connect 40 0 41 0;
#P connect 39 0 40 0;
#P connect 38 0 39 0;
#P connect 37 0 38 0;
#P connect 36 0 37 0;
#P connect 35 0 36 0;
#P connect 34 0 35 0;
#P connect 33 0 34 0;
#P connect 32 0 33 0;
#P connect 31 0 32 0;
#P connect 30 0 31 0;
#P connect 29 0 30 0;
#P connect 28 0 29 0;
#P connect 27 0 28 0;
#P connect 26 0 27 0;
#P connect 25 0 26 0;
#P connect 24 0 25 0;
#P connect 23 0 24 0;
#P connect 22 0 23 0;
#P connect 21 0 22 0;
#P connect 20 0 21 0;
#P connect 19 0 20 0;
#P connect 18 0 19 0;
#P connect 17 0 18 0;
#P connect 16 0 17 0;
#P connect 15 0 16 0;
#P connect 14 0 15 0;
#P connect 13 0 14 0;
#P connect 12 0 13 0;
#P connect 11 0 12 0;
#P connect 10 0 11 0;
#P connect 9 0 10 0;
#P connect 8 0 9 0;
#P connect 7 0 8 0;
#P connect 6 0 7 0;
#P connect 5 0 6 0;
#P connect 4 0 5 0;
#P connect 3 0 4 0;
#P connect 2 0 3 0;
#P connect 1 0 2 0;
#P fasten 163 0 1 0 407 94 544 94;
#P connect 164 0 163 0;
#P connect 159 0 154 0;
#P fasten 161 0 159 0 37 406 294 406;
#P connect 156 0 159 0;
#P fasten 162 0 156 0 37 362 294 362;
#P connect 153 0 156 0;
#P fasten 158 0 153 0 36 327 294 327;
#P connect 152 0 151 0;
#P fasten 160 0 151 0 36 247 273 247;
#P connect 157 0 152 0;
#P window clipboard copycount 165;

Am 18.01.2008 um 05:35 schrieb vade:

> No.
>
> The thing is, if the number box is constantly being sent updates,
> then it will be part of the scheduler, and max will take time to re-
> draw it.
>
> If a numberbox is not a UI element meant for interaction, remove/
> replace it, or use [qlim] and limit the amount of updates per
> second the objects get.
>
> On Jan 17, 2008, at 5:27 PM, Christopher Keyes wrote:
>
>>
>> Is it correct that any lowly number box, even if hidden in some
>> unopened sub-patch whose state has not been changed since the
>> Babylonians, will still be updated by the Max scheduler and thus
>> drain CPU?
>>
>

#120314
Jan 18, 2008 at 3:34pm

exactly.

On Jan 18, 2008, at 9:23 AM, dominik busch wrote:

> looks like it isn’t the sheer existence but only the rate at which
> they’re updated.

#120315
Jan 18, 2008 at 3:42pm

FWIW, if you still want a nice pretty GUI with numberboxes, use OSC
or some other form of network-based communication and open your GUI
patch in the runtime, your video drawing patch in another version of
the runtime, and watch your framerate SOAR. On my macbook pro, I
gained 25-30fps by taking a complex GUI and audio analysis patch and
opening it in he max runtime. It also had the added advantage that
when/if it crashed, or if I added an audio device, I din’t have to
restart the main video drawing patch.

Cheers
Evan

On Jan 18, 2008, at 3:34 PM, vade wrote:

> exactly.
>
> On Jan 18, 2008, at 9:23 AM, dominik busch wrote:
>
>> looks like it isn’t the sheer existence but only the rate at
>> which they’re updated.
>

#120316
Jan 18, 2008 at 5:00pm

Just one small clarification to this thread. Vade is almost correct,
however to be precise, the number object does not actually have the
cost of *drawing* when hidden, but rather what happens is that it
schedules a “qelem” (which fights for the same number of queue slots
as jitter), and that qelem checks to see if the object is visible
before actually drawing. It is the number of objects that have been
added to the queue that in effect reduce framerate. So eliminating
hidden UI objects which are rapidly updated is important still, even
though technically they don’t render themselves.

Of note, we’ve changed the way UI updating works in Max 5, so
hopefully some aspects of this will improve.

Evan’s suggestion of separating the video engine from UI in two
different processes is *highly* recommended for complex UI with
faster and more accurate movie playback. Not always the easiest thing
to do, but for those of you looking for maximum performance, it may
be worth the effort.

-Joshua

#120317
Jan 18, 2008 at 5:42pm

Thanks for the clarification!

On Jan 18, 2008, at 12:00 PM, Joshua Kit Clayton wrote:

>
> Just one small clarification to this thread. Vade is almost correct,
> however to be precise, the number object does not actually have the
> cost of *drawing* when hidden, but rather what happens is that it
> schedules a “qelem” (which fights for the same number of queue slots
> as jitter), and that qelem checks to see if the object is visible
> before actually drawing. It is the number of objects that have been
> added to the queue that in effect reduce framerate. So eliminating
> hidden UI objects which are rapidly updated is important still, even
> though technically they don’t render themselves.
>
> Of note, we’ve changed the way UI updating works in Max 5, so
> hopefully some aspects of this will improve.
>
> Evan’s suggestion of separating the video engine from UI in two
> different processes is *highly* recommended for complex UI with
> faster and more accurate movie playback. Not always the easiest
> thing to do, but for those of you looking for maximum performance,
> it may be worth the effort.
>
> -Joshua
>

#120318
Jan 18, 2008 at 5:50pm

i am indeed working on a patch with a complex interface. taring it
apart to separate the interface would be quite some effort. do you
think it’s still worth it given the improvements to come in max 5?
would be a bit annoying to go through it and then to find out it’s
obsolete with the new version.

best, dominik

Am 18.01.2008 um 18:00 schrieb Joshua Kit Clayton:

> Of note, we’ve changed the way UI updating works in Max 5, so
> hopefully some aspects of this will improve.
>
> Evan’s suggestion of separating the video engine from UI in two
> different processes is *highly* recommended for complex UI with
> faster and more accurate movie playback. Not always the easiest
> thing to do, but for those of you looking for maximum performance,
> it may be worth the effort.

#120319
Jan 18, 2008 at 6:27pm

On Jan 18, 2008, at 9:50 AM, dominik busch wrote:

> i am indeed working on a patch with a complex interface. taring it
> apart to separate the interface would be quite some effort. do you
> think it’s still worth it given the improvements to come in max 5?
> would be a bit annoying to go through it and then to find out it’s
> obsolete with the new version.

It would still be worth it to do for Max 5. Even with any
improvements we’re making, sharing heavy UI and video processing in
the same thread (which is still the case in Max 5) will be slower
than separating into multiple processes.

-Joshua

#120320
Jan 18, 2008 at 9:57pm

ok, i see. thanks for clarification + info, joshua!
dominik

Am 18.01.2008 um 19:27 schrieb Joshua Kit Clayton:

>
> On Jan 18, 2008, at 9:50 AM, dominik busch wrote:
>
>> i am indeed working on a patch with a complex interface. taring it
>> apart to separate the interface would be quite some effort. do you
>> think it’s still worth it given the improvements to come in max 5?
>> would be a bit annoying to go through it and then to find out it’s
>> obsolete with the new version.
>
> It would still be worth it to do for Max 5. Even with any
> improvements we’re making, sharing heavy UI and video processing in
> the same thread (which is still the case in Max 5) will be slower
> than separating into multiple processes.
>
> -Joshua

#120321

You must be logged in to reply to this topic.