Help - Show Tonight, New Problem


    Feb 22 2006 | 10:16 pm
    I've been running the latest versions of Max/MSP/Jitter on my XP machine for a while now.
    I'm working only with QT (no OpenGL stuff).
    I have a problem that didn't exist before. Don't know when it started. I think a few days ago, but I didn't really catch it until now.
    I run any of my Jitter patches.
    When I grab a window's title bar to move it or close a window(main patch, subpatches, Max's preferences window, etc.) or open a menu from Max's menu bar, the video output pauses.
    I pauses both in my pwindow and the output of jit.window.
    The video motion returns when I release the window, move it around, or it finishes closing.
    I've played around with all the performance options (including the "default" positions.)
    I've played around with all preferences I can think of.
    It happens with the following very simple patch.
    Any advice appreciated.
    Adam
    max v2;

    • Feb 22 2006 | 10:32 pm
      not much help, but I can confirm that drawing pauses when the title bar is
      clicked. has been reported to me by a few XP users. my solution: don't
      click the title bar or only do so when freezing the video looks
      appropriate. some solution, huh?
      p.
    • Feb 22 2006 | 10:37 pm
      Would be a brilliant solution except it doesn't address the the output pausing when I close subpatches or move them out of the way.
      I can accept this has been the behavior all along and I haven't noticed it before. Probably something to do with *my* behavior changing, and I'm noticing something that was always there.
      Cycling74, any help with this issue?
      Adam
      Quote: pnyboer wrote on Wed, 22 February 2006 15:32
      ----------------------------------------------------
      > not much help, but I can confirm that drawing pauses when the title bar is
      > clicked. has been reported to me by a few XP users. my solution: don't
      > click the title bar or only do so when freezing the video looks
      > appropriate. some solution, huh?
      >
      > p.
      >
    • Feb 23 2006 | 12:18 am
      Hi Adam,
      I can confirm this behavior on Windows. I recommend creating a top
      level interface that doesn't require you to move windowd around, if this
      is going to cause problems.
      Cheers,
      Andrew B.
    • Feb 23 2006 | 6:22 am
      Andrew,
      That's not a practical suggestion. My patches have a few dozen subpatches with multiple controls each. I don't think that's out of spec when programming with Jitter.
      Are you following up just on this post or the additional info I supplied to tech support over the phone? i.e., I elaborated on my post, stating there are window-interaction scenarios where all video processing stops, not just drawing/output.
      Is that also expected behavior?
      What can be done about this? I don't know how I missed it for so long, I think it has to do with my style of video when playing live (in the studio, I use midi automation so am not usually touching windows).
      This behavior is a serious limitation for someone trying to create a performance patch they need to interact with.
      Adam
      Quote: andrewb@cycling74.com wrote on Wed, 22 February 2006 17:18
      ----------------------------------------------------
      > Hi Adam,
      > I can confirm this behavior on Windows. I recommend creating a top
      > level interface that doesn't require you to move windowd around, if this
      > is going to cause problems.
      >
      > Cheers,
      > Andrew B.
      >
    • Feb 23 2006 | 9:16 am
      > This behavior is a serious limitation for someone trying to create a performance patch they need to interact with.
      Hi Adam,
      Although I agree that the situation is not optimal, I think any user
      interface that requires you to click and move windows around in a live
      performance context could be vastly improved. Don't you agree?
      Ben
    • Feb 23 2006 | 9:34 am
      Adam Kendall wrote:
      > This behavior is a serious limitation for someone trying to create a performance patch they need to interact with.
      I also had this problem... this is a little abstraction i built to move
      my windows. It doesn't solve your problem when you open a menu from
      Max's menu bar, but it could be a solution for moving or closing window
      patches/subpatches
      Marco
      ----
      max v2;
    • Feb 23 2006 | 4:05 pm
      To get around this problem in Grid Pro we made some of our windows
      docked to the bottom of the screen with a little button on them that
      when clicked makes them popup so you can edit them. One more click and
      it collapses back down. It's a lot like the way you could make folders
      into tabs on the bottom of the screen in os 9. Man, I sure miss that
      feature. Anyway, this reduces the need to drag window around. Good
      luck.
      -=jack turner
    • Feb 23 2006 | 4:44 pm
      Hi Adam,
      As several people have confirmed, this is a known behavior in Windows.
      There is really not much else to suggest besides optimizing your control
      system. It is generally best practice for a performance setup to locate
      all pertinent controls in your top-level patch, and make use of some
      message routing scheme to manage hierarchical states. You can also make
      use of thispatcher to open,close, and move windows around if needed.
      In performance, it pays greatly to have a simple and accessible interface,
      as you don't want to be fumbling around with subpatches when the moment
      comes. I generally subscribe to the notion of reducing possible pitfalls
      before going onstage, but I imagine others will feel differently.
      Good luck,
      Andrew B.
    • Feb 23 2006 | 6:47 pm
      Ben and Andrew,
      If this is an unavoidable fact, I'll live with it.
      I've been developing business applications for over 14 years, have been writing Max/MSP/Jitter performance applications for about 3/4 years, and have performed live with a laptop dozens of times over the past few years. I know how user-interface works. My situation requires my solution.
      I can get some critical patch controls to top level, but, as one example, I can't get controls for 4 video channel-strips * about 12 filters each * about 2-8 controls each into top level. On top of that, some of my filters are actually sub-chains -- several filters working in concert, each having their own set of controls.
      I know there are techniques for genericizing controls, etc. For my stuff, that becomes impractical. At some point, I need to hide objects. I can find ways to expose some, but not all.
      Anyway, seems like this is a fact of life with Windows -- I knew my pwindows froze, I somehow missed that my output froze too. I'll deal with it.
    • Feb 23 2006 | 7:01 pm
      Hi, Jack,
      That's an interesting solution. Will have to sort something out for my situation. Minimizing windows causes the same problem as closing them for me.
      What I'm toying with is some insanity of two laptops and OSC -- One as the controller, one as the processor. This is why I never throw away computers.
      Adam
      Quote: turner@vidvox.com wrote on Thu, 23 February 2006 09:05
      ----------------------------------------------------
      > To get around this problem in Grid Pro we made some of our windows
      > docked to the bottom of the screen with a little button on them that
      > when clicked makes them popup so you can edit them. One more click and
      > it collapses back down. It's a lot like the way you could make folders
      > into tabs on the bottom of the screen in os 9. Man, I sure miss that
      > feature. Anyway, this reduces the need to drag window around. Good
      > luck.
      >
      > -=jack turner
      >
    • Mar 02 2006 | 4:37 am
      Hi,
      I want to follow up on this problem.
      As alot of people pointed out, there will be a frame dropped when handling windows. My problem was more extensive than that.
      I found several things causing my problem:
      1. Biggest Culprit - A combination of multiple exposed pictsliders, hsliders and usliders, all buried in several layers of exposed bpatchers. When moving windows out of the way or closing them, these objects were causing a big hit on the screen redraw. Solution - Need to keep them hidden in patchers, not exposed in bpatchrs. Or, detach the controls from the patches they manage and put them in the master patcher. (Haven't tried that, might still cause redraw problems.)
      2. I have many "benign" objects like patchers exposed in several single-layer-deep bpatchers. If my open windows are over them, they cause a redraw hit when closing or moving. Solution is to have windows open over less populated parts of the patch, i.e., parts where they won't cause too many objects to redraw when closed. Not always practical, but can be done up to a point.
      3. Refresh Rate in Performance Options. With Item 1. above happening, nothing helped. But, after moving the bpatcher sliders out of the way, reducing my Refresh Rate to 5 (from the default 30) helped.
    • Mar 07 2006 | 4:49 am
      This may be a bit late and inappropriate given yr time constraints, but flashserver
      provides a way to interface that is not too heavy on the processor.
      Only dilemna is it requires building a parallel interface.
    • Mar 07 2006 | 11:18 pm
      Andrew,
      Has anyone figured out WHY this is happening on Windows, and that it is indeed Windows-specific? I got an inquiry from Jim Aikin that was similar to this, but with MIDI, wondering if it's a similar issue.
      Would be very interested in learning more about this. No, I don't think it's ideal to be dragging windows around in a performance, but having some of visual feedback is important.
      Here's another question: anyone tried using VNC as a remote control? Does that use host or client resources to draw the interface?
      Peter
    • Mar 08 2006 | 12:26 am
      Hi Peter,
      This issue is related to the way we handle user events in the main
      thread on Windows. For an interesting experiment, browse to a website
      with a Quicktime movie, and click hold the title-bar on your browser
      window while the movie plays.
      The stalling appears to only crop up when closing windows, and
      click-holding the title-bar without moving the cursor. As soon as the
      mouse is moved, processing is resumed.
      You can easily work around this issue by sending windows offscreen
      instead of closing them, and by sending messages to thispatcher to move
      the windows around.
      Adam's issue was also in part due to his use of nested bpatchers in his
      UI, which will certainly slow things down.
      Cheers,
      Andrew
    • Mar 08 2006 | 12:34 am
      Yeah, I've noticed in Windows in general that there seem to be a lot of UI bottlenecks, and that they tend to adversely impact QuickTime. I've talked to Windows users about this, and they act like I'm crazy. This makes me very interested to see what happens with Aero in Vista.
      That said, I'm all for optimizing patches . . . would be great to compile a performance bible for Jitter users on squeezing the most performance out of your patches, including tweaks specific to Windows and Mac. I'm especially impressed, for instance, by the JavaScript examples in the Jitter documentation watching the framerate on the same operation (JS being much faster).