Jerky visual response at low cpu usage

Mar 2, 2006 at 8:50pm

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!

Toby

#24686
Mar 3, 2006 at 1:37am

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

#71857
Mar 3, 2006 at 9:06am

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

#71858
Mar 3, 2006 at 2:14pm

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

#71859
Mar 3, 2006 at 7:35pm

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

#71860
Mar 3, 2006 at 8:04pm

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!

#71861
Mar 3, 2006 at 10:07pm

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 …

#71862

You must be logged in to reply to this topic.