Drsbaitso

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.

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.

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.

graphical-cpu-spikes-test-for-xp-users

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

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


I confirm stays about at 100% until mouse up.

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


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

> I confirm stays about at 100% until mouse up.

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


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.

Quote: Andrew Pask wrote on Fri, 15 September 2006 04:18

----------------------------------------------------

> current development on the underlying MaxMSP architecture will 

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

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?


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.

--=--=------=--=------=--=------=--=------=--=------=--=----

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.

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.  

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.

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 

Centre de Recherches et de Formation Musicales de Wallonie asbl

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

Fortunately, it isn't!
_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl
http://users.skynet.be/crfmw/max


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

> --=--=------=--=------=--=------=--=------=--=------=--=----

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

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 

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:

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.

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.


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.

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.

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.

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??? ;)

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??? ;)


Graphical CPU spikes test for XP users