unbelievable


    Jan 12 2008 | 1:56 am
    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

    • Jan 12 2008 | 2:06 am
      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
      >
    • Jan 12 2008 | 2:15 am
      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
      >
      >
    • Jan 12 2008 | 2:36 am
      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
      >>
      >>
      >
      >
    • Jan 12 2008 | 3:48 am
      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
      >>>
      >>>
      >
    • Jan 12 2008 | 5:26 am
      > 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
    • Jan 12 2008 | 5:38 am
      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
    • Jan 12 2008 | 10:42 pm
      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.
    • Jan 12 2008 | 11:12 pm
      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?
    • Jan 13 2008 | 1:44 am
      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)
      "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
    • Jan 16 2008 | 1:23 am
      are there the same issues with prepend set to a message box?
    • Jan 16 2008 | 1:53 am
      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?
    • Jan 17 2008 | 8:18 pm
      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???
    • Jan 17 2008 | 8:29 pm
      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?
    • Jan 17 2008 | 8:32 pm
      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???
      >
      >
    • Jan 17 2008 | 8:38 pm
      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 :<
    • Jan 17 2008 | 10:27 pm
      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
    • Jan 18 2008 | 2:36 am
      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 :<
      >
    • Jan 18 2008 | 3:29 am
      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 :<
      > >
      >
      >
    • Jan 18 2008 | 4:33 am
      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 :<
      > >
      >
      >
    • Jan 18 2008 | 4:35 am
      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?
      >
    • Jan 18 2008 | 12:47 pm
      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 :<
      > > >
      > >
      > >
      >
      >
      >
      >
      >
      >
    • Jan 18 2008 | 2:23 pm
      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
      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?
      >>
      >
    • Jan 18 2008 | 3:34 pm
      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.
    • Jan 18 2008 | 3:42 pm
      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.
      >
    • Jan 18 2008 | 5:00 pm
      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
    • Jan 18 2008 | 5:42 pm
      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
      >
    • Jan 18 2008 | 5:50 pm
      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.
    • Jan 18 2008 | 6:27 pm
      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
    • Jan 18 2008 | 9:57 pm
      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