Help – Show Tonight, New Problem

Feb 22, 2006 at 10:16pm

Help – Show Tonight, New Problem

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;
#N vpatcher 11 31 1273 729;
#P origin 51 121;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#N vpatcher 486 258 1086 658;
#P pop;
#P newobj 618 398 81 9109513 p test_subwindow;
#N comlet clock in;
#P hidden inlet 543 183 15 0;
#P newex 508 139 36 9109513 r clock;
#P newex 491 170 27 9109513 gate;
#P number 775 109 31 9 0 0 32 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname nbox_frame;
#P hidden message 902 172 50 9109513 frame $1;
#P flonum 715 109 31 9 0 0 32 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname fnbox_rate;
#P hidden message 848 171 42 9109513 rate $1;
#P message 580 108 28 9109513 read;
#P message 637 108 27 9109513 stop;
#P message 607 108 31 9109513 start;
#P message 663 108 31 9109513 clear;
#N comlet to jit.qt.movie;
#P hidden inlet 584 184 15 0;
#P toggle 564 109 15 0;
#P objectname toggle_clock;
#P hidden newex 625 273 103 9109513 jit.qt.movie 320 240;
#P comment 693 109 26 9109513 rate;
#P comment 745 109 33 9109513 frame;
#P hidden newex 554 483 38 9109513 s clock;
#P toggle 554 431 15 0;
#P hidden newex 554 451 45 9109513 qmetro 1;
#P user jit.pwindow 94 194 322 242 0 0 0 1 0 0;
#P connect 6 0 0 0;
#P fasten 7 0 17 0 569 135 496 135;
#P connect 18 0 17 1;
#P connect 19 0 17 1;
#P hidden connect 2 0 1 0;
#P hidden connect 1 0 3 0;
#P connect 17 0 6 0;
#P hidden connect 13 0 6 0;
#P hidden connect 9 0 6 0;
#P hidden connect 11 0 6 0;
#P hidden connect 10 0 6 0;
#P hidden connect 12 0 6 0;
#P hidden connect 8 0 6 0;
#P hidden connect 15 0 6 0;
#P hidden connect 14 0 13 0;
#P hidden connect 16 0 15 0;
#P pop;

#24568
Feb 22, 2006 at 10:32pm

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.

#71281
Feb 22, 2006 at 10:37pm

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

#71282
Feb 23, 2006 at 12:18am

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.

#71283
Feb 23, 2006 at 6:22am

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

#71284
Feb 23, 2006 at 9:16am

> 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

#71285
Feb 23, 2006 at 9:34am

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;
#N vpatcher 64 68 540 567;
#P origin -95 -106;
#P window setfont Verdana 10.;
#P hidden message 447 57 80 13303818 clean , wclose;
#P window setfont Verdana 12.;
#P comment 369 28 97 13303820 close window;
#B frgb 129 71 36;
#P objectname window.name[1];
#P button 447 3 15 0;
#P window setfont Verdana 10.;
#P window linecount 2;
#P hidden message 165 347 203 13303818 window flags nogrow , window
notitle , window exec , savewindow 1;
#P window linecount 1;
#P hidden message 180 385 258 13303818 window flags grow , window title
, window exec;
#P hidden newex 74 309 60 13303818 loadbang;
#P hidden message 74 387 90 13303818 window getsize;
#N vpatcher 281 145 874 822;
#P window setfont Verdana 10.;
#P newex 260 188 117 13303818 unpack 0 0 0 0;
#P newex 260 73 79 13303818 route window;
#P newex 260 99 63 13303818 route size;
#N comlet list – window getsize;
#P inlet 260 46 15 0;
#P message 55 546 220 13303818 window size $1 $2 $3 $4 , window exec;
#P newex 392 441 27 13303818 t i i;
#P newex 274 441 27 13303818 t i i;
#P newex 156 441 27 13303818 t i i;
#P newex 38 441 27 13303818 t i i;
#P window setfont “Sans Serif” 9.;
#P comment 164 425 76 9109513 “tl.y” (top/left Y);
#P comment 45 425 75 9109513 “tl.x” (top/left x);
#P comment 400 425 106 9109513 “br.y” (bottom/right Y);
#P comment 282 425 101 9109513 “br.x” (bottom/right X);
#P window setfont Verdana 10.;
#P newex 38 376 27 13303818 +;
#P newex 156 376 27 13303818 +;
#P newex 274 376 27 13303818 +;
#P newex 55 509 365 13303818 pack i i i i;
#P newex 392 376 27 13303818 +;
#P window setfont Verdana 9.;
#P comment 151 285 48 13303817 Offset Y;
#P comment 63 287 46 13303817 Offset X;
#N comlet Move window (use ubotton coordinates);
#P inlet 38 47 15 0;
#P window setfont Verdana 10.;
#P newex 126 283 27 13303818 -;
#P newex 38 283 27 13303818 -;
#P newex 38 251 116 13303818 buddy 4;
#P newex 38 207 117 13303818 unpack 0 0 0 0;
#P newex 38 120 64 13303818 zl group 4;
#N comlet Resize window (connect to thispatcher);
#P outlet 55 584 15 0;
#P connect 6 0 1 0;
#P connect 1 0 2 0;
#P connect 2 2 3 0;
#P connect 3 0 4 0;
#P connect 4 0 13 0;
#P connect 13 0 18 0;
#P connect 3 2 4 1;
#P connect 26 0 13 1;
#P fasten 18 0 13 1 43 467 119 467 119 363 60 363;
#P lcolor 13;
#P connect 18 1 10 0;
#P connect 10 0 22 0;
#P connect 22 0 0 0;
#P connect 2 3 3 1;
#P connect 2 0 3 2;
#P connect 3 1 5 0;
#P connect 2 1 3 3;
#P connect 3 3 5 1;
#P fasten 5 0 12 0 131 347 161 347;
#P connect 12 0 19 0;
#P connect 26 1 12 1;
#P fasten 19 0 12 1 161 470 236 470 236 368 178 368;
#P lcolor 6;
#P connect 19 1 10 1;
#P connect 23 0 25 0;
#P connect 25 0 24 0;
#P connect 24 0 26 0;
#P fasten 4 0 11 0 43 347 279 347;
#P connect 11 0 20 0;
#P fasten 20 0 11 1 279 472 378 472 378 370 296 370;
#P lcolor 7;
#P connect 26 2 11 1;
#P connect 20 1 10 2;
#P fasten 5 0 9 0 131 347 397 347;
#P connect 9 0 21 0;
#P connect 26 3 9 1;
#P fasten 21 0 9 1 397 471 500 471 500 366 414 366;
#P lcolor 15;
#P connect 21 1 10 3;
#P pop;
#P hidden newobj 175 423 92 13303818 p move.window;
#P objectname move.window;
#P user ubutton 0 0 416 21 0 2;
#P objectname window.bar.ub;
#P window setfont Verdana 12.;
#P comment 4 3 229 13303820 click and drag;
#B frgb 129 71 36;
#P objectname window.name;
#P window setfont Verdana 10.;
#N thispatcher;
#Q window flags nogrow close nozoom nofloat;
#Q window size 64 68 540 567;
#Q window notitle;
#Q window exec;
#Q savewindow 1;
#Q end;
#P hidden newobj 74 423 71 13303818 thispatcher;
#P user panel 0 0 475 22;
#X brgb 191 191 191;
#X frgb 0 0 0;
#X border 0;
#X rounded 0;
#X shadow 1;
#X done;
#P objectname window.bar.1;
#P user panel 0 1 476 22;
#X brgb 107 107 107;
#X frgb 83 83 83;
#X border 0;
#X rounded 0;
#X shadow 0;
#X done;
#P background;
#P objectname window.bar.2;
#P hidden connect 7 0 6 0;
#P hidden fasten 9 0 2 0 170 412 79 412;
#P hidden fasten 8 0 2 0 185 412 79 412;
#P hidden connect 5 0 2 0;
#P hidden connect 6 0 2 0;
#P hidden fasten 12 0 2 0 452 412 79 412;
#P hidden connect 7 0 9 0;
#P hidden connect 4 2 5 0;
#P hidden connect 2 0 5 1;
#P hidden connect 10 0 12 0;
#P pop;

#71286
Feb 23, 2006 at 4:05pm

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

#71287
Feb 23, 2006 at 4:44pm

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.

#71288
Feb 23, 2006 at 6:47pm

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.

#71289
Feb 23, 2006 at 7:01pm

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
>

#71290
Mar 2, 2006 at 4:37am

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.

#71291
Mar 7, 2006 at 4:49am

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/

#71292
Mar 7, 2006 at 11:18pm

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

#71293
Mar 8, 2006 at 12:26am

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

#71294
Mar 8, 2006 at 12:34am

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

#71295

You must be logged in to reply to this topic.