Does component visibility get set to 0 on plugin GUI close?

[aaronventure]

@Lindon I have at least 30 in my current project and no issues in the GUI behavior. Maybe memory but how would I check that? Would it show up in the RAM value in the performance toolbar? Is the timer's memory footprint even worth considering?

As long as you're stopping them when they're not being used, I think you should be fine.

[Lindon]

@d-healey said in Does component visibility get set to 0 on plugin GUI close?:

@Lindon said in Does component visibility get set to 0 on plugin GUI close?:

I'd like to add at least a couple more for the custom ARPS

This is just for the GUI?

No - there's some MVC in the design - so the GUI is separate (remember my post about sending large amounts of data into a ScriptProcessor?). The Arps will run in their own ScriptProcessors, however there's some other stuff I'd like to use a timer on in the "main" code base...

[d.healey]

@Lindon From my understanding only the Synth timer is useful for realtime stuff. And you're limited to 4 per container (I think that's what Christoph said anyway).

[Lindon]

@d-healey said in Does component visibility get set to 0 on plugin GUI close?:

@Lindon From my understanding only the Synth timer is useful for realtime stuff.

Damn it yes - thats what I meant.. how many Synth timers...thanks 4 should be enough, I think. Especially if I can have 4 per ScriptProcessor..

[aaronventure]

@Lindon https://forum.hise.audio//post/74073

It's 4 per container. But you can always add child containers, though the limited width of the Module Tree GUI might have something to say about that.

[Lindon]

@aaronventure said in Does component visibility get set to 0 on plugin GUI close?:

@Lindon https://forum.hise.audio//post/74073

It's 4 per container. But you can always add child containers, though the limited width of the Module Tree GUI might have something to say about that.

LOL - yes....

[d.healey]

@Christoph-Hart said in Does component visibility get set to 0 on plugin GUI close?:

I just realized that the timer created by Engine.createTimerObject() is not being suspended

Does that mean I can still use the Engine timer to play notes when the UI is closed?

[Christoph Hart]

• It's 4 timers per Sound Generator, not per container
• never ever use the timer object for anything related to MIDI processing. The frequency is as jittery as it can be so unless you want to create a random glitch machine, you absolutely need to resort to the onTimer callback.
• I've added a function Content.setTimerSuspendCallback(). Here are the docs, but I'm on the road so they will not be merged into the docs website until next week.
• The "problem" with the timer objects is that they are not automatically suspended, so they might stack up when using multiple instances. If you're using <10 timers, than it most likely won't matter, but with the numbers from Aaron it might make sense to utilize the new callback I just committed.

[Christoph Hart]

Is the timer's memory footprint even worth considering?

As long as you're stopping them when they're not being used, I think you should be fine.

There is no memory footprint, but all JUCE timers are inserted into a linked list across all plugin instances when they are running, so if you have 10+ instances of your plugin it might start to clog the UI thread (usually Cubase is the first host that starts to choke here).

A timer that is not running has a completely negligible impact on anything, so if you stop them, they are basically invisible on any performance metrics.

[d.healey]

@Christoph-Hart said in Does component visibility get set to 0 on plugin GUI close?:

but all JUCE timers are inserted into a linked list across all plugin instances

Is this list shared by different JUCE based plugins or only multiple instances of the same plugin?

[Christoph Hart]

@d-healey not entirely sure, but I think the "resource" that is being shared is UI render time, so this is basically shared across everything that needs to draw stuff on the screen (that's why cubase will start to freeze too and not only your plugin).

[aaronventure]

@Christoph-Hart said in Does component visibility get set to 0 on plugin GUI close?:

There is no memory footprint, but all JUCE timers are inserted into a linked list across all plugin instances when they are running, so if you have 10+ instances of your plugin it might start to clog the UI thread (usually Cubase is the first host that starts to choke here).

Right, so the callback returns true if no instances of the plugin are open and false if one is open.

If I have 15 instances of my plugin running in a project (not unrealistic, even less so if it's an effect), and any one of them is open, then all the callbacks in all the instances will return false.

If i'm tying timer start and stop to this, this effectively means that all the timers start running?

[Christoph Hart]

@aaronventure no, the suspension callback happens for each instance of your plugin.

There is just the possibility that one plugin instance creates more than 1 interface (all plugin standards allow this and there are some hosts which allow having more than 1 interface open, even if it's just for a short amount of time).

So every instance tracks the amount of open interfaces and suspend their timers by calling this callback with true whenever the count reaches zero.

[Lindon]

@Christoph-Hart said in Does component visibility get set to 0 on plugin GUI close?:

• never ever use the timer object for anything related to MIDI processing. The frequency is as jittery as it can be so unless you want to create a random glitch machine, you absolutely need to resort to the onTimer callback.

Well this confuses me, I think it says: dont use a timer object , instead use a timer object...unless you mean something different by "resort to the 'onTimer' callback"

Perhaps this is saying: dont use a Panel.timer, or an Engine.timer, instead use a Synth.timer.

[aaronventure]

@Lindon said in Does component visibility get set to 0 on plugin GUI close?:

Perhaps this is saying: dont use a Panel.timer, or an Engine.timer, instead use a Synth.timer.

Yes. Only the synth timer is sample accurate.

[Christoph Hart]

yup, with onTimer I mean the callback called onTimer :)

[Lindon]

@aaronventure said in Does component visibility get set to 0 on plugin GUI close?:

@Lindon said in Does component visibility get set to 0 on plugin GUI close?:

Perhaps this is saying: dont use a Panel.timer, or an Engine.timer, instead use a Synth.timer.

Yes. Only the synth timer is sample accurate.

..and I get 4 of these per Sound Generator - so this thread is confusing me more and more...

I have an arp, its in a ScriptProcessor - in the MAIN container... not in a sound generator...what timer should I be using?

[aaronventure]

@Lindon said in Does component visibility get set to 0 on plugin GUI close?:

what timer should I be using?

For anything that's related to the audio or MIDI output of your plugin, use the synth timer.

For the GUI, use the panel timer or a timer object.

[Lindon]

@aaronventure said in Does component visibility get set to 0 on plugin GUI close?:

@Lindon said in Does component visibility get set to 0 on plugin GUI close?:

what timer should I be using?

For anything that's related to the audio or MIDI output of your plugin, use the synth timer.

For the GUI, use the panel timer or a timer object.

yeah thats not answering the question tho is it. I've held on to the above rule-of-thumb for the 5 years I've been building HISE instruments. But now I learn that Synth.timers are attached to sound generators and as far as my mental model works a Script Processor is not a sound generator.

Very happy to be proved wrong.

[aaronventure]

@Lindon The master container is still a container and a container is a type of Sound Generator, according to the docs

I think that's what this remark was about

@Christoph-Hart said in Does component visibility get set to 0 on plugin GUI close?:

It's 4 timers per Sound Generator, not per container