Ticks Question.

[lalalandsynth]

Say you have a module, within that module are a few modules doing various things and lets say that 10 of them use a 25 tick . Is there any reason not to have a single 25 tick outside the main module, connected into the module and then routed to each item needing a 25 tick ?

If so , why are there separate Ticks rather then global Tick modules that are in essence all the same ticker?

Am I overlooking something ?

[nix]

No, there's no reason not to have a global ticker AFAIK.
You can make it by putting a tick in parent module with wireless connector.
I'm not sure why FS doesn't call a global tick, but it doesn't seem a biggy

[tulamide]

The prim itself is not a clock producing ticks. It is just a connector for the Windows timer (which makes these Tickers unreliable). It doesn't really make a difference. What does make a difference is taking proper care of trigger forwarding and backward triggers. In really bad situations just one tick can trigger dozens of prims and modules.

[adamszabo]

Yes, you are overlooking the fact that you are not thinking like a programmer

Sure, you can have a hundred of those 25 tick, modules, but its better to have a single 25 tick and connect it to wherever you want. Its called optimization. How is FlowStone supposed to know what you are creating? It doesnt have artificial intelligence to tell you that you only need 1 of them. YOU have to tell FlowStone what it should do. You can also write 1*2 + 3*2 + 6*2 and FlowStone will do it, but its better to write (1+3+6)*2, or hey they are all just a single number so they equal 20, so its better to just write 20. Start thinking like this, and your project will be much faster and use less CPU.

[lalalandsynth]

"trigger forwarding and backward triggers" that is a concept I am not sure I understand and I need to start figuring this out , optimization is where my biggest problem is right now. I guess greens cannot touch an audio stream at any point and maintain precision , which leaves me with no real methods of manipulating stuff without writing code I guess ?

I always end up with a CPU munching monster.
My current plugin is 9800 triggers and 12% CPU , unacceptable.
Seems ok with the gui closed though, when I go deeper into the schematic and the gui is out of sight the cpu is at 3% and yet the trig count is only down by a 1000 or so..

What are some tactics to optimize the Gui ?

[lalalandsynth]

One thing I have been thinking about, lets say that I have a spectrum analyser , it is not seen most of them time unless selected, can I shut it off completely , processing wise when not seen or does that happen automatically ?
Does it help to disable audio input into that section when not seen or ?

Same question applies to audio processing although I think it does not take cpu if it does not get a signal.

[lalalandsynth]

I now have the whole plugin using two trigger modules.
Not a noticeable difference so I guess its the Backward forward triggering thing.

[adamszabo]

Try the Editor Open module which gives true or false when you have the vst gui open, and use it with a trigger blocker. When the gui is closed it doesnt need to do these graphical calclations

[lalalandsynth]

Ok, And I connect that to what ? The Mgui ?
Or the ticker ?
or the audio input to the module ?

And do I use a selector with the input triggered by the Ed Open where the inputs either go through to the module or into the trigger blockers and then into the module ?

And does this apply to the whole GUI when not show in the DAW or does it shut off the parts that are not in view ?
I switch between 4 guis at the moment.
The CPu is acceptable when the gui is not open in the DAW, in comparison to when open at least.

i basically have to two scenarios , GUI elements that can be shut off completely when not shown.
And Gui elements that do processing that need to RUN audio but shut off the Graphic element when not in view.

[lalalandsynth]

Shutting off the ticker into the analyser seems to save me a bit of cpu.