Rotary slide (CPU heavy)


#1

Hi,

Anyone have noticed that a “Rotary Slider” takes up more CPU load when changed to values near min or max?

My CPU load seems to increase with about 15% when altered - this slider adresses a scaling parameter in my algorithm so it shouldn’t increase complexity!

Cheers
Thomas


#2

And a linear slider doesn’t do the same?..

Are you sure your algorithm’s not using out-of-range values that trigger some denormalisation?


#3

[quote=“jules”]And a linear slider doesn’t do the same?..

Are you sure your algorithm’s not using out-of-range values that trigger some denormalisation?[/quote]

Hi again,

I just found that other types of sliders are as cpu heavy as well :frowning: I wonder why this seems to eat all the resources when I change the slider position. What I’m working with is a Spectrum Analyzer where it is possible to warp the frequency axis using a warped delay chain prior to my fft. The warping factor is adressed with this slider that I have problems with. I can’t understand why the warping factor suddenly can take up more cpu resources when changed to values either close to -1 or 1; when values are close to zero the plugin does not eat too much resources (20% less than when close to -1/1). No matter the warping factor the number of multiplications for each new incoming sample is the same…

Anyone have some comments?

Cheers
Thomas


#4

Yes - please check your facts before assuming the UI is to blame! E.g. the first thing you could have done here would be to remove the line that makes the slider actually change any of your variables, which would be a very quick way of telling whether it’s the drawing of the UI or your own processing that’s going slowly.

(And it sounds like a denormalisation bug to me…)


#5

It occures to me, that if you do calculations where that value is subtracted from one you may end up with a very small float, which might trigger the infamous denormal problem.
I dont remember exactly how that stuff works, but I think toby bear has a plug for testing if your machine is suseptible to the denormal bug, which might be a first step.


#6

http://www.musicdsp.org/files/denormal.pdf
maybe this excellent paper could help you


#7

Running the juce demo and messing with the sliders (rotary and slide) very quickly (as fast as the mouse can move), the max cpu usage logged during that time was 3%, averaged 2%.


#8

[quote=“jules”]Yes - please check your facts before assuming the UI is to blame! E.g. the first thing you could have done here would be to remove the line that makes the slider actually change any of your variables, which would be a very quick way of telling whether it’s the drawing of the UI or your own processing that’s going slowly.

(And it sounds like a denormalisation bug to me…)[/quote]

Hi,

Thank you all for your answers!

…and Jules I’m sorry that I didn’t evaluate other sliders before submitting my question!

Thomas


#9