Jerky visual response at low cpu usage
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!
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.
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…
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.
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?
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
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….
I would post the patch, but it’s kinda too much for the list too be
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
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 …