DSP Robotics Support

I am making a plugin that has a few moving graphics , a scope , running bar indicator etc.
It takes very little or about 1% cpu in FS but about 14% in Reaper , but only when the GUI is closed.
When GUI is open its about 40% !

I gather that the discrepancy between the CPU reported in Reaper and the actual CPU use is because it runs as another process due to the bridging ?
Is it normal to have a 1% CPU in FS and then up to 40% in Reaper , It seems reasonable that it takes a bigger hit as a VST but it seems excessive.

GUI Open


GUI Closed.


What do I need to take in to consideration for GUI cpu hits and what can I do to minimize that ?

Also the "running bar" does not "refresh" properly/smoothly , almost looks like it starts to run backwards , very jagged .
ANy tips or tricks ?

The CPU Meter in flowstone shows only CPU used by the Stream section.
Graphics in flowstone are not hardware accelerated, it all has to be drawn by the CPU.
For that reason I personally think, that you should not put any big continuously updating display (like scopes or an FFT display) in your Flowstone VSTs, it just takes too much CPU.

Maybe try a Redraw area prim for just the module view and use a Tick 25 prim to update the view??

Cheers

Spogg

Try using the "Limit" trigger with a sample and hold, this limits the redraw trigger to be too fast, and creates no trigger then the gui is closed so you save cpu.

Ok, so I did some testing .

The test shows :
Testing most recent CPU hog version in Reaper - 40% with gui open -turning off the scope on the VST changes nothing, which is interesting because removing the scope from the FS project -exporting as VST has a significant effect. I wonder why that is ? In FS I shut off the input to the scope with a multiplex.

Removing the scope has the biggest effect ,admittedly I needed a scope with 8000 samples for it to be useful and in fact I would probably need more and its a dual scope pre and post,but interestingly I had 3 moving indicators and all of them had a large effect.

1. One tiny indicator (tiny scope used as an indicator) with 16 samples 100 ticks used as an indicator for the envelope movement.
2&3. An indicator/knob for the CC value ( not needed on the interface, just for testing) and a counter for the cc.

So... I tried a few variations for these indicators to see what was hogging CPU.

1.
Scope removed , midi cc indicator removed - small envelope indicator 11.6% with the gui open
Scope removed , midi cc indicator removed - small envelope indicator removed 5.9% with the gui open
So the CPU is halved by removing that indicator/Scope


2&3
Scope removed , midi cc indicator intact - small envelope indicator intact 27% with the gui open.
Again , CPU doubled by a small moving indicator.



Best results so far were obviously with Scope removed, CC value indicator removed and small envelope value indicator removed. This gave me a result of 6% CPU with the GUI open and 0.3% with the GUI closed.

I could get this down by removing the running position bar.
So I tried that .

Scope removed, CC value removed, small indicator removed, running bar removed. In fact , all moving graphics removed.

0.9% CPU with GUI open!

I was not too surprised that the Scope was hogging the cpu , but I have to admit that the two tiny indicators , one of them a scope and another a bmp , both seem very heavy on the cpu ?

Comparing the cpu use to something similar like LFO tool from Xfer which has all these and more moving graphics and only uses about 4% CPU , it is however all written in c++. Interestingly when I turn on the scope on that plug it does indeed jump to about 40% cpu !!

This leaves me with two questions after all this testing.

1.Can I decide to take the CPU hit from the scope when it is turned on , but make sure it does not take CPU when turned off on the VST itself?It only needs to be used occasionally and for a short while. It seems weird that when I turn off the scope on the VST it hogs until I close the GUI ?
I only turn off the input to the scope with multiplex, maybe that is the reason...dunno ?

2. Can I make small moving indicators that are fast enough to be meaningful and yet economical ? I dont mind super simple? I feel like I am doing something wrong if I cannot use any moving graphics without such a huge cpu hit.

Next up is trying some of your suggestions so far.

Thanks

Ok, so the scope seems to take a lot of cpu in other VST plugs as well so I guess it is hard to escape that but how can I make sure that it does not take cpu when turned off ? I have tried a selector on the audio input to the scope , on the Mgui and on the FFT Arrays . It always takes CPU until I remove it completely , is there a way to make this work assuming that I am cool with the cpu when it is on ?


AHHH ! Trigger limit seems to have done the trick. Now when I shut it off the CPU drops significantly, but not completely.

Still wondering if I can get rid of any more cpu cycles when it is shut off on the VST ?

That scope that you are using has a trigger switch inside that controls if the triggers of the Tick25 primitive go through to the Mono to Graph primitive, you can just connect a bool to this trigger switch.
But the real problem seems to be that the stepposition display is causing redraws on the line editor and the scope, because they occupy the same space. It helps to only draw the stepposition display when the step position has actually changed, and also to only redraw the affected area of a stepposition change.
Here is a modified version:

The optimized step display give an error?

I also made it so that when the grid is changed , the width of the step position bar changes to fit the grid, well, there are two width settings , one for all grid settings except the coarsest one.

I lose that capability with this revised edition, I might be able to do it in a different way though?
In any event it gives an error when I connect the Stepsh/current step.