Toby

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)

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

jerky-visual-response-at-low-cpu-usage

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.

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

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


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

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 

I would post the patch, but it's kinda too much for the list too be 

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

I would post the patch, but it's kinda too much for the list too be 
useful!

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 

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

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


Jerky visual response at low cpu usage