Jerky visual response at low cpu usage


    Mar 02 2006 | 8:50 pm
    Hi there, I was wondering if anyone could help me with a problem -
    I have multisliders and matrixes (matrixctrl) in my patch that refresh at a very slow rate - around once every second when I move them. However, this only happens when the patch is playing (it is a drum machine) and the cpu usage is only between 2 to 5%.
    Is there any way to improve this? Maybe I can set the priority higher for these objects? (I've tried turning off overdrive and scheduler in audio interrupt)
    Cheers for any help!
    Toby

    • Mar 03 2006 | 1:37 am
      Say, Toby, are you running on a Mac, by any chance? I don't know if it makes
      any difference, but I was experiencing this on my Mac until I added a bunch
      of memory. Don't know how much you have, but that could be the issue.
      Best wishes,
      Warren Sirota
    • Mar 03 2006 | 9:06 am
      What OS & Max version are you using? There were some
      issues like this a few years back, but things improved
      dramatically after an upgrade. And of course, some
      more RAM might be handy, if your machine is deficient
      in that dept...
      cheers
      Roger
    • Mar 03 2006 | 2:14 pm
      Of course, the other thing that could make response sluggish is some sort of
      feedback loop in the program that's not quite bad enough to cause a stack
      overflow. I wonder whether these UI elements are as sluggish in a simpler
      patch. It might be worth testing and trying to figure out whether the
      problem is the patch or the machine.
      Best wishes,
      Warren Sirota
    • Mar 03 2006 | 7:35 pm
      Thanks for your responses. I have a gig of Ram on Windows XP, which should be ample I think. The Max version is 4.3, so maybe this is the problem? However, I do have quite alot going on in the patch, with several poly~ objects etc. You'd think the CPU usage would reflect on visual performance too though, wouldn't you?
      Cheers
      Toby
    • Mar 03 2006 | 8:04 pm
      I sent a patch and problem description to c74 support a while ago that
      detailed some problems I had on OSX (haven't tried on XP) with poly. I
      don't know if it's poly~ within poly~ related or not. I never heard
      back about it tho :(. Anyway, i found that with my patch, my timing
      from metro and "interactivity" would slowly degrade over time - faster
      with more voices in poly~. I found that when I de-poly'ed the patch
      and ran many instances as abstractions, my timing didn't degrade. I'm
      kinda suspecting it was the poly~-in-poly~ causing the problem. As it
      was sort of a side project, I haven't had a chance to really boil it
      down.
      SO the point is, as a test, you may want to try running the poly~'ed
      patches as abstractions, and load many instances and see if you have
      the same problems....
      p.
      I would post the patch, but it's kinda too much for the list too be
      useful!
    • Mar 03 2006 | 10:07 pm
      Quote: Toby wrote on Fri, 03 March 2006 12:35
      ----------------------------------------------------
      > Thanks for your responses. I have a gig of Ram on Windows XP, >which should be ample I think. The Max version is 4.3, so maybe >this is the problem? However, I do have quite alot going on in >the patch, with several poly~ objects etc. You'd think the CPU >usage would reflect on visual performance too though, wouldn't >you?
      absolutely true. normally you can exspect a good
      performance with say 500 multisliders with your
      system.
      so i also think it might be something with your code,
      maybe the interface is only slow because it does not
      recieve the messages earlier? ... check that.
      keywords are "right to left order" and "working with
      long lists" here.
      on mac OS classic - which isnot the case with you, i
      would have recommended to reboot before using MAXMSP
      or codewarrior or ego shooters to have a frag-free
      memory but in XP that can not be the issue.
      another thing is that gui objects in bpatchers are
      like 5 times slower performing so if you ...