tick 100 vs 25

[tor]

i think i just made a strange discovery...

as i struggle to lower the CPU load from the graphics in my equalizer i experience that if i use a tick100 and divide it by 2 the cpu load is 10-20% lower than with a plain tick25. even though the redraw rate now is "double". I also have a triglimiter between tick and redraw.

can more people confim this beaviour

[tor]

to me it was a present. smother graphics and less cpu load

[tor]

it seems like this cpu friendly effect only applies to the osm inside sm and not in exported vst's. must check more later. need a break here now.

[Dell]

Hello Tor.

I haven't seen a difference in CPU drainage moving from a tick 25 to tick 100. The only problems I've faced using a
tick 100 are a few on Gearslutz complaining the meters are too fast on a compressor in which, I resorted back to tick 25.

If you are working on the equaliser you made a year ago, I do recall lowering graph's samples. A very high setting will
drain your cpu.

Cheers!

[infuzion]

Neither are accurate, so a tick 100 may be 115, maybe 90ish. If you want to lower CPU, find my heartbeat on the registered users forum, maybe a separate d/l, maybe an old XMas present.

[tor]

thanks

i will look into the heartbeat.

my challenge now is that i have a FFT overlayed by nine response graphs (one main and one for each band) and the eight nodes. this is a whole lot of redrawing to be done. i recall that someone said the the green maths connected to the redrawn graphics also get retriggered on the redraws. this i have not been able to reveal with the triggercounter so i guess it is not the case. and i cant optimize the greens or triggerlimit it more than i already have done. i hope that the heartbeat can give me some ideas. otherwise i'll have to abandon the individal band graphs.

[infuzion]

1 redraw for them all

[tor]

That is already done. Im wondering if this is impossible to do in a good way. Aliasant showed me the bitmap caching method by it is not responsive enough. Anyone interested please have a look:

DoublePrecisionEqualizerNewEngine7minGUI6osm.osm

[trogluddite]

Hi tor - I has a quick go through, and here's a quick mod that helped a lot on my little notebook...

DoublePrecisionEqualizerNewEngine7minGUI6osm_Image Cache.osm

It's using the bitmap cache idea - but only for the EQ curve. The FFT is still live, as there's no point cacheing something that changes every single frame. The new components are inside the little module that sits above your graph primitives, linking them to the view and area.
The cache prevents all of those graph modules from recalculating their images every time the screen is redrawn - instead, they draw to the bitmap only when any of the array contents gets changed by moving a control. I also reduced the number of points being calculated for the graphs themselves - they're now set to have the same number of points as the there are pixels across the view - saving all those float array modules an awful lot of calculations.
Even with the cacheing, there's still a lot of CPU load when you are moving the controls, but over here, it is much lower when the plugin is just running normally.
The only easy way to lower the 'mousing' CPU load would be to limit the speed that the controls update.
Quantising the display resolution might also help - i.e. make it so that very tiny parameter changes, that are too small to see on the graphs, don't bother to send a trigger

retriggered on the redraws. this i have not been able to reveal with the triggercounter so i guess it is not the case

This can indeed be the case, because triggering a primitive causes it to request updates from the modules supplying it with values. Unfortunately these 'backwards' triggers do not show up on the counter - in fact, this example will show you how weird they can be...

Weird Triggers.png

2 + 2 = 8 !!! but, 2 + 2 + 1 = 5.
If you change the top two numbers, nothing happens at the outputs because of the trigger blockers. Change the third float, and the correct answer appears at the end - the second add sends a 'reverse' trigger to the first one asking for its correct result - but this doesn't cause the upper 'result' display to update, only the primitives that made the 'request' will get to see the answer - hence you won't see it on a trigger counter.
This can sometimes happen with GUI's - ReDrawing a views causes the graphics elements to update, and in turn, they request the latest results from green primitives that are supplying the variables.
If the re-calculation and the ReDraw are both driven by the same trigger, it doesn't usually matter - the triggers have tags so that SM knows if they've already been actioned. But if a view is triggered independently by a ticker, it can cause a lot of extra calculations.

[tor]

splendid!!!!!!!!
this did the trick. now it is down to a acceptable cpu load.

i tried the caching with the module i got from aliasant. i guess it was to complex to update right. your version works just perfect.

i trust you regarding the backfiring triggers. i just thought they would be revealed by the counter

i will also look into quantisizing the control data. good idea

Thank you again for the Nth time trog

[aliasant]

Heres another way.

I did cache the background and the graph but also made sure no triggers redraws anything if theres no audio input or change to the graph.

The output from the scale module can be a list on NANs if the input to that module is an array with zeroes so I added a small number to that and that then prevents the smooth module from letting triggers thru when its not changing.Edit: The Float Array Changed module I made is why NANs will let triggers thru.

Another thing I fixed is the draw of the line and graph. They are now synced and drawn correctly.

Looking at the cpu in Taskmanager gives me similar results as with Troggs but you can probably get something from mine aswell.
I marked the modules I changed with "CHANGED"

[tor]

hey aliasant

thank you for the effort. the image cache that trog made did the trick. i also had to add a 'float changed' after the preset module in my knobs aswell to make automation render fine. i am also going to quantisize q's and gain floats to get it futher optimized. i really dont think there i much more to save on the redraw of the graphics after this.

[aliasant]

hey aliasant

thank you for the effort. the image cache that trog made did the trick. i also had to add a 'float changed' after the preset module in my knobs aswell to make automation render fine. i am also going to quantisize q's and gain floats to get it futher optimized. i really dont think there i much more to save on the redraw of the graphics after this.

Well-
you can do what I did.
Stop the redrawing of the graph when your not having any audio in(changes in the graph
And other little things...

[tor]

yes that can apply to the fft. but users may want to tweak the eq when audio is not played. so reponse graphs must be updated when ever a change is done.

[aliasant]

yes that can apply to the fft. but users may want to tweak the eq when audio is not played. so reponse graphs must be updated when ever a change is done.

hehe
Of course.
Exactly what I did.
but you dont need the freq graph updating all the time if theres no audio?