Optimizing FFT... driving me nuts!

[tor]

Hello good folks. As some might know I have a FFT in my EQ. I have tried everything I think. The only way I actually managed to get the CPU load down is to have a tick divide. But I can not go under tick25/2. The graphics just become to slow to funktion proper. On my Core 2 Duo the stock FFT consume between 50-70% and loopeytunes report that his i3 processor consumes 20%. I have gotten the load down in my EQ's FFT a little by reducing size and ticks. I really need this to be reduced much more.

I share this for anyone to look into and hopefully someone can give a hand in the optimizing. Please help me

BTW: I have cleaned up and fixed alot of GUI/interaction stuff from the earlier version of DPE i shared in the RBJ thread.

[MichaelBenjamin]

have you tried to use a "redraw area" module instead? also to make sure no unnecessary triggers get to the redraw - use some of infuzions redraw limiters. you should get down to a reasonable amount of cpu use, but still, in general graphics redrawing seems to be like a weak spot in sm.

[trogluddite]

Yes, MB has a good point.
I had a little play with the schematic, and even with the FFT disconnected and no audio running, the CPU load is pretty high - nearly 40% on my little notebook.
This is a particular problem with SM - redrawing large areas is very CPU greedy, even when well optimised. It would be worth having a play with various parts disabled to find exactly where all that CPU is going - could be that the actual FFT maths is using less than you think.
Another trick worth trying would be to buffer the EQ curve into a bitmap - that part only needs recalculating when you move a knob, but because it is overlaid over the FFT, the curve points also get calculated every time the FFT is redrawn - the trigger in GUI parts do weird stuff like that sometimes. You can turn the curve into a temporary bitmap when the controls are static, which is much faster to draw to the screen.
The thread Lower GUI CPU Load has examples of these CPU savers for graphics - but don't expect miraccles, big animations are just a bit of a pain in SM.

[tor]

No I did not try the redraw area this time. But the redraw component is connected to a max clipped down video connection. I thought maybe it did the same trick. I try now and see it actually helps a little. But far from what I want. Thank you!

[tor]

would it be better maybe to separate the layers. reponse graphs and dots in one gui panel and fft in a panel then give them seaparate dredraw prims? or will the two overlaying panels redraw affect eacother?

[trogluddite]

Could possibly help.
When you redraw an area, it will will redraw any view that overlaps that area , even if they are in completely different modules- and if you are using graphs or vector graphics, that means that all the hidden maths to calculate the pixels gets done too.

You can sometimes use this to your advantage...
Say you had a row of level meters like on a mixer - instead of having a ReDraw inside every meter, you can have another module that overlaps all of the meters, and use it to Redraw all of them at once - because ometimes drawing one big area can use less CPU than drawing a lot of little ones. The big 'overlay' module doesn't even have to have any graphics in it - just an MGUI and a ReDraw Area.

Something else I found that might help - Redraws can also make lots of green triggers too...
e.g. You have a vector graphic with lots of green maths that calculates where the vectors have to go - if you do a redraw of the vectors, the green maths gets done again too, sometimes - even if the values haven't changed. Putting trigger blockers (or Sample and Hold) to seperate the 'Green' from the 'Yellow' can help here - e.g. putting blockers on the green inputs to a Float-to-Area.
Could be that is happening with your schematic - the ReDraws might be making the Float Array calculations use extra CPU.

[tor]

hmmm... i see. so this happens even though it is not connected to the redraw? your suggestion is to have a sample and hold between the green math and the respecting graph components? and where should i get the triggers from that control sample and hold? why will not sample and hold be affected by the redraw if all other green is? if green math gets retriggered by redraw will not triggers connected in the same system also be?

[tor]

when i turn a knob or drag a node in the graphics there is a huge cpu raise. so i guess they are not constantly beein recalculated by the redraw. if not then the case is that i get double up with green calculations while adjusting the parameters.

i am ok with a constant cpu load. that why i use one tick25/2 as redraw and get trigger. i just dont see how i can get ok rendering with any lower trig rate.

must investigate more in the trig block prim though... but i think it will be a heck of a job finding where to implement them in the schematic and if they actually make significant difference.

[trogluddite]

hmmm... i see. so this happens even though it is not connected to the redraw

Can do, yes, though it's kind of unpredictable when it happens. Even if not connected to the redraw, if it is connected to any GUI parts that overlap the view, you can still get these 'backwards' triggers where the graphics are 'asking' the green to re-calculate the value - even if they are using the same tick.
You don't always need an extra source for the S&H triggers, you can connect like this...

SandH.png (4.71 KiB) Viewed 1596 times

(shown with float, but works the same with other green)
Looks kinda odd, like it doesn't do anything!?
But it stops 'backwards' triggers from coming through (from right to left) - so the maths only gets done once, even if other parts on the right hand side are refreshing many times. I often put one right at the end of any complicated maths, so that I know the maths only gets done when I want it to.

i get double up with green calculations while adjusting the parameters

Yes, that's a good place to look for some CPU saving - the handles and EQ plot shouldn't need ReDraws, because the FFT animation is already drawing that part of the screen.

[tor]

Yes, that's a good place to look for some CPU saving - the handles and EQ plot shouldn't need ReDraws, because the FFT animation is already drawing that part of the screen.

so i understood

i only have one redraw for that area. will try the sample and hold trick to see if it helps

thank you

[trogluddite]

Yeah, it can be hard work chipping little 1% here and there - Good luck.

[tor]

sample and hold in the end of all green math actually icreased cpu load

[trogluddite]

Ouch, that doesn't usually happen!

Oh yes, one last tip (if you still trust me ) - when checking GUI CPU load, make sure none of the modules are selected in the SM window. It's a mystery, but for some reason a selected module always uses a bit of extra CPU

[tor]

hmmm... ok.

i have no problem trusting you trog

as far as i can remember you have helped me out numberous times. and i am thankful for you dedication to the SM community

[Andrew J]

hmmm... ok.

i have no problem trusting you trog

as far as i can remember you have helped me out numberous times. and i am thankful for you dedication to the SM community

He uh good lad, inn't he?