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