Graphical CPU spikes test for XP users

Sep 13, 2006 at 6:06pm

Graphical CPU spikes test for XP users

Hi, I was just wondering if some of our XP users could perform a small test in a few easy steps in order to isolate a problem I am experiencing with GUI interface elements. It can be quickly realized by doing the following.

1. launch task manager, set to one side…

2. launch MAX, create a new patcher, drop a textedit object down.

3. lock the patcher, then, click and HOLD down the mouse button inside the textedit object.. … …

4. result : CPU usage 100%!!!!!! unf!! >:X

Anyone else experiencing anything like this? It happened on my old Athlon 1800 as well as both of my newer rigs [3800+x2 and plain old 3800+]…. maybe it’s an Athlon thing, or maybe an NVidia being as I’ve never had Intel or ATI in my setups.

thnx! Jame$

#27613
Sep 13, 2006 at 9:50pm

Hi,
Confirmed the same behavior on 4.6.2b15 on a Windows XP SP2 PC. Dell Optiplex SX280 Pentium 4 2.8 GHz.

#83654
Sep 14, 2006 at 12:17am

I need testers!! [see top]

#83655
Sep 14, 2006 at 6:48am

Hi,

I confirm stays about at 100% until mouse up.

Cheers

Alessandro Fogar

2006/9/14, James Aldridge :
>
> I need testers!! [see top]
>

#83656
Sep 14, 2006 at 3:44pm

Hello,

I can reproduce : Max/MSP 4.5.7 & Athlon 2600+ & ATI graphic card

Bertrand

2006/9/14, Alessandro Fogar :
> Hi,
>
> I confirm stays about at 100% until mouse up.
>
> Cheers
>
> Alessandro Fogar
>
> 2006/9/14, James Aldridge :
> >
> > I need testers!! [see top]
> >
>

#83657
Sep 14, 2006 at 4:18pm

Yep. We can reproduce it too. It is not currently a high priority fix though, as current development on the underlying MaxMSP architecture will just make it go away anyway. Our tests have shown that the impact of this problem is not so great, but if we can be shown conclusively otherwise, we may be willing to look at it.

-A

#83658
Sep 14, 2006 at 11:48pm

Quote: Andrew Pask wrote on Fri, 15 September 2006 04:18
—————————————————-
> current development on the underlying MaxMSP architecture will
> just make it go away anyway.

Interesting. Will this perhaps also address the high CPU use at idle and occasional CPU spiking for the Mac version?

#83659
Sep 15, 2006 at 7:16am

Andrew Pask:

I will show you how volitile this problem is in regards to interaction with the scheduler. Observe the ordered guidelines in the patch below. Notice that the same schematic applies, clicking and holding, but now the object isn’t a textedit, but just an empty object box.

–=–=——=–=——=–=——=–=——=–=——=–=—-

#P button 41 92 15 0;
#P window setfont “MS Sans Serif” 10.;
#P newex 41 215 50 8585226;
#P button 41 146 15 0;
#P window linecount 1;
#P newex 41 119 61 8585226 metro 1000;
#P window linecount 3;
#P comment 100 215 184 8585226 < ------- click til you get the cursor [depends on setting] and hold down button;
#P window linecount 1;
#P comment 96 197 17 8585226 3.;
#P comment 64 91 17 8585226 2.;
#P comment 85 91 57 8585226 start metro;
#P window linecount 3;
#P comment 60 145 152 8585226 4. observe no scheduler while mouse button held down. Observe!;
#P window linecount 2;
#P comment 41 36 125 8585226 1. launch task manager , set to one side;
#P connect 6 0 7 0;
#P connect 9 0 6 0;
#P window clipboard copycount 10;

–=–=——=–=——=–=——=–=——=–=——=–=—-

Is this behavior the same on OSX Max? I think stuff like this should be first priority. It’s way too easy to trash the scheduler on wMax. If that’s not enough I can supply other examples for wMax where basic user interaction completely destroys timed events from occuring.

thanks for your time,

James

#83660
Sep 15, 2006 at 7:35am

On 15 sept. 06, at 09:16, James Aldridge wrote:

> I will show you how volitile this problem is in regards to interaction
> with the scheduler. Observe the ordered guidelines in the patch
> below.

< ...>

> Is this behavior the same on OSX Max?

Fortunately, it isn’t!
_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl

http://users.skynet.be/crfmw/max

#83661
Sep 15, 2006 at 8:21am

James Aldridge wrote:
> I will show you how volitile this problem is in regards to interaction with the scheduler. Observe the ordered guidelines in the patch below.
>
> –=–=——=–=——=–=——=–=——=–=——=–=—-
-snip-
> –=–=——=–=——=–=——=–=——=–=——=–=—-

Wow, that’s the ugliest thing I’ve ever seen Max do. Thanks for the
warning.

This could easily have bit me since I use textedit to enter formulas for
injection… just haven’t tested ‘live’ use yet. Not a damning problem
for me now, but it could be in two months. My saving grace is that I
cache these parameters for quick recall in an ubumenu, which does not
exhibit this problem, so at least in one case there’s a workaround.

The textedit object did not exist in the clip you sent. Here’s the
correct version:

#P window setfont “Sans Serif” 9.;
#P user textedit 41 215 95 245 0 139 9;
#P button 41 92 15 0;
#P button 41 146 15 0;
#P window setfont “MS Sans Serif” 10.;
#P window linecount 1;
#P newex 41 119 61 8585226 metro 1000;
#P window linecount 3;
#P comment 100 215 184 8585226 < ------- click til you get the cursor
[depends on setting and hold down button];
#P window linecount 1;
#P comment 96 197 17 8585226 3.;
#P comment 64 91 17 8585226 2.;
#P comment 85 91 57 8585226 start metro;
#P window linecount 3;
#P comment 60 145 152 8585226 4. observe no scheduler while mouse button
held down. Observe!;
#P window linecount 2;
#P comment 41 36 125 8585226 1. launch task manager , set to one side;
#P connect 8 0 6 0;
#P connect 6 0 7 0;
#P window clipboard copycount 10;

#83662
Sep 15, 2006 at 1:53pm

i know andrew already answered for cyclig, but ill say that the same thing happens for me on my P4, XP SP1 laptop. it first goes up to about 50%, then to 100% in less than 2 seconds.

#83663
Sep 15, 2006 at 2:46pm

In the patch that I posted, the textedit object was replaced by an empty object box. Clicking and holding down the mouse button inside the object box while its in “text entry” mode will cause the CPU to spike….

So it’s not just textedit that’s this, but even the basic max object box!!!

If you want a THIRD example, go to menu help > about max while task manager is open. Yet another 100% spike!

Something funky is going on. And yes, this has hindered my ability to finish a textedit dependent step sequencer project I am working on which uses it’s own syntax to control a variety of hardware parameters.

Thanks for your help,

James

#83664
Sep 15, 2006 at 2:51pm

Hmmmmmm. I can see that it might be a problem, especially for all you high wire live patching type guys. At least it doesn’t happen when modifying a UI object.I’m still unable to offer promises about the timing of any fix though.

>If that’s not enough I can supply other examples for wMax where >basic user interaction completely destroys timed events from >occuring.

Please do. These kind of reports are super useful.

-A

#83665
Sep 15, 2006 at 4:03pm

Alrighty, andrew

I’ll be working on a patch today that might show off just how damaging this can be. Also see my VSTGUI thread which is causing me mucho grief.

I think anything that freezes the Max scheduler, whether it be a vst plugin or a UI element should be placed on moderately high priority. That’s just me though, I have no idea what you guys are cookin’ up over there. I definetly like the hint about this problem being abolished all together in the future due to a change in I guess how max handles graphics. OpenGL interface coming sometime soon??? ;)

#83666

You must be logged in to reply to this topic.