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

[Christoph Hart]

As far as I know the message thread is effectively disabled when the GUI is closed.

Not really no (the actual UI thread is supplied by the OS and will not be stopped), but most UI timers in HISE are derived from a custom class I wrote called SuspendableTimer which tracks the amount of open plugin interfaces and stops / starts the timers when it reaches zero (and yes there can be multiple plugin interfaces per instance in some weird cases).

The default JUCE timer runs on the message thread and keeps running, plus it shares its resource with all other instances of the plugin which caused UI freezing (especially in Cubase) when a certain amount of plugin instances with hundreds of different timer objects was used.

However I just realized that the timer created by Engine.createTimerObject() is not being suspended and still a default JUCE timer, so your question is valid. I guess that when I made that the decision these things were used sparsely and it was the huge amount of panel timer callbacks causing the issue.

Obviously I can't change that now without breaking most projects, but if you want to have control over that I could add a method to the timer object like setSuspendable() which then switches to the suspendable timer base class.

[d.healey]

@Christoph-Hart I think that sounds like a good idea

[aaronventure]

@Christoph-Hart That would be great, thanks. I already tied them to visibility using the broadcaster, this is now the missing piece.

[Lindon]

@Christoph-Hart Whilst we are here...

How many Engine.createTimerObject() can I use in a project, I mean roughly? I have one already - and I'd like to add at least a couple more for the custom ARPS we are considrering.

[d.healey]

@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?

[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.