Vst editor closed = more cpu!?

[Father]

When i close my vst editor window, FL shows more CPU use (e.g 8% open to 14% closed)?!
What could cause it? which direction should i be looking into?

[tester]

Denormals?

Take an example. If you feed a filter with zero (standy by mode) - it will eat more CPU than when it was processing anything (like "-180dB" silent noise). Some types of modules just need such stuff.

[Father]

Denormals?
Take an example. If you feed a filter with zero (standy by mode) - it will eat more CPU than when it was processing anything (like "-180dB" silent noise). Some types of modules just need such stuff.

No thats not it. It happens while playing.
After some testings I've found that its probably a GUI problem. This example is very much like my main project. It has visual meters and tabs in front panel.

More cpu when hidden.fsm

(82.12 KiB) Downloaded 1118 times

When the LED meters are hidden it seems like the plugin uses more CPU!

[Nubeat7]

why are you using 4 led meters for one channel? one on each channel would be enough!

and you can use ed open primitive to block triggers when gui is closed (hidden)

[Nubeat7]

you also can use mono4 for the env follower to save cpu

[Father]

It was just an example, wanted to be more obvious. but there could be several led meters for input, output, compressor...etc.
Mono 4 and trigger blocker, those were 2 things that i did first. Mono4 is definitely helps, but surprisingly blocking didn't do any good though, same behavior. I think when editor is closed it doesn't redraw anyway.
I used windows resource monitor and this is what i get:
editor open, or led tab is in front: 3% CPU usage, 95% Maximum frequency, 1.4% average CPU consumption, FL CPU meter 10% steady.
editor closed, or Leds are hidden: 5% CPU usage, 50% Maximum frequency, 1.8% average CPU consumption, FL CPU meter 15-18 jumpy!

[tester]

Try gui elements without ruby.
Get replacements from SM forum.

[Father]

The example doesn't have any ruby graphics. maybe the opposite is true...
I have isolated the problem. The LED meters!
Performance without meters = with meters and hidden (or closed)
Using those led meters somehow makes CPU work in higher frequencies, so looks like the plugin is using less CPU!! But actually the CPU is doing more work! This is just my feelings!
Someone needs to explain this to me!

[tester]

Your example has ruby driven knobs.

And btw, there seems to be a bug in FS related to ruby-driven modules with gui-visible values. NB's schematic crashes here when starting it with with click (i.e. not drag into open FS editor). I also have some example here, where editbox is connected to ruby module to convert some values, and as long the editbox has any non-zer value - the schematic always crashes on load.

So there may be some mess between visuals and ruby routines.

[Father]

Your example has ruby driven knobs.

ah yes...didn't notice them because their not the problem.
LED lights are the cause of this problem.
I've seen similar behavior when redrawing some part of GUI with a 100 ticker. It shows less CPU in the host but slows down graphical performance.
I did change LEDs a bit and used tick 25 or even less and it is much better. Should try it all in ruby instead of bitmap and see what happens. The meters from FS aren't working properly (for me), they are sleepy sometimes
What I've learned from this is not to trust CPU meters because processioning graphics and streams are two different thing.