Adam Kendall

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.

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.

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.

help-show-tonight-new-problem

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

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?

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.

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

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.  

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


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 

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.

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.

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.

Quote: andrewb@cycling74.com wrote on Wed, 22 February 2006 17:18

> 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 

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.

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

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


> This behavior is a serious limitation for someone trying to create a performance patch they need to interact with.

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?

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?

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 

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

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

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.

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.

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.

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.

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.


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.

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

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.

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
>


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.

As alot of people pointed out, there will be a frame dropped when handling windows.  My problem was more extensive than that.

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.


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.

http://www.nullmedium.de/dev/flashserver/

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.
http://www.nullmedium.de/dev/flashserver/


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?

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 

The stalling appears to only crop up when closing windows, and 

click-holding the title-bar without moving the cursor. As soon as the 

You can easily work around this issue by sending windows offscreen 

instead of closing them, and by sending messages to thispatcher to move 

Adam's issue was also in part due to his use of nested bpatchers in his 

UI, which will certainly slow things down.

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.

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

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


Help - Show Tonight, New Problem