DSP Robotics Support

So... As promised here are my findings.

What I was trying to do is cut down CPU on FFT display, original starting point is two stock FFT displays put together, one for each channel. CPU reading was 21% (not DAW or F.S. CPU reading but windows CPU reading, as explained above).

* going from multiple Tick_25 to single Tick_25 and 'wireless out' to all draw/redraw modules - 21% [no effect]
* Cutting Ticker (trigger divide) by 2 (still good speed) - 13%
* Cut out one of the 'stock FFT display' and combine both 'lines' into a stereo display - 10%
* Cut out all 'grid' and 'background' from redraw area (just paste it on top of static background) - 6%
* Cut down vector (array) size to 400 (from 16000, still fine resolutiuon for EQ background) brought it down to 4%

So, CPU is cut down from 21% to 4%, resolution is lower but acceptable to my mind. Still higher than 'market VST' EQ's which run FFT displays in background...

The last version is attached, for anyone to use.

Thanks for the help !

Nice play.
It would be interesting to get a not limited spectral waterfall (spectrogram) with live mode per time window (scrolling, paging) and capturing as a bitmap as well.

Rocko wrote:Cut out all 'grid' and 'background' from redraw area (just paste it on top of static background)

Is a view just a set of pixels that's redrawn or does the content of the view (not just the size) effect the redraw cost?

Hi,

Not a measured answer, but from the way I understand it, the 'CPU eater' is high amount of green calculations.
This means that if you redraw large vectors of data which are calculated at high rate, CPU will be high.

To decrease this, I have (basedon forum advice):
* Shortened calculated vectors
* Lowered rate and sunched all display (redraw) to one

If the background is constant, not changing, just take it out of redraw area. The stock FFT provided by FS/SM comes with a chagnging grid/background area, which is redrawn by size change or by new data, so (AFAIK) - it actually redraws the whole area and grid, once a new vector comes in...
Big waste of CPU if the VST is finalized and display size is determined.

Thanks,
Rocko

Rocko wrote:If the background is constant, not changing, just take it out of redraw area.

So, from what you're saying, the things in the area effect the cost of the redraw beyond just the size of the redraw area? And shapes and gradients are all recalculated? Every object? Is everything inside the view recalculated but only the area specified redrawn? How much does the size of the redraw area (in pixels) effect the cost irrespective to the content?