Graphical CPU spikes test for XP users


    Sep 13 2006 | 6:06 pm
    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$

    • Sep 13 2006 | 9:50 pm
      Hi, Confirmed the same behavior on 4.6.2b15 on a Windows XP SP2 PC. Dell Optiplex SX280 Pentium 4 2.8 GHz.
    • Sep 14 2006 | 12:17 am
      I need testers!! [see top]
    • Sep 14 2006 | 6:48 am
      Hi,
      I confirm stays about at 100% until mouse up.
      Cheers
      Alessandro Fogar
      2006/9/14, James Aldridge : > > I need testers!! [see top] >
    • Sep 14 2006 | 3:44 pm
      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] > > >
    • Sep 14 2006 | 4:18 pm
      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
    • Sep 14 2006 | 11:48 pm
      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?
    • Sep 15 2006 | 7:16 am
      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.
      --=--=------=--=------=--=------=--=------=--=------=--=----
      --=--=------=--=------=--=------=--=------=--=------=--=----
      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
    • Sep 15 2006 | 7:35 am
      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
    • Sep 15 2006 | 8:21 am
      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:
    • Sep 15 2006 | 1:53 pm
      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.
    • Sep 15 2006 | 2:46 pm
      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
    • Sep 15 2006 | 2:51 pm
      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
    • Sep 15 2006 | 4:03 pm
      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??? ;)