Cherry Audio Forums

If it works then fine but this thread started on the premise that you were encountering problems with that approach.

You are right, the timers are local to the module, but the GUI Timer isn't in anyway synced to screen refresh. It's just an asynchronous timer that CA named GUI Timer because handling GUI updates is the most common purpose of a timer thread - in order to offload GUI jobs from the ProcessSample() thread. In effect it's just a named timer that doesn't have a name parameter.

My comments reflect a more generalised view about the GUI Timer thread because in many of my modules that thread is used for lots of different tasks so switching it on and off would interfere with all manner of things.

So in a typical module there are three threads in operation - one in ProcessSample() and two in Notify() one being the GUI_Timer thread and a parallel thread that handles events like mouse, knob and button changes. Note that this means that Notify() can be effectively doing two things simultaneously. For instance the timer thread still works even if a dialog box is blocking the thread that's handling a button press.

Okay, that's pretty clear. It was wrong because it was throwing an exception, albeit one that could be ignored. I may take a minute and rewrite the code as you suggested, just because it's niggling at me now.
Thanks for the assist.

That sounds like it might be a good idea as ignored exceptions do tend to gnaw at the back of one's mind, plus you can then reuse the same approach in other projects that need more flexibility.

Glad my comments were of some help. I also wanted to post them for a wider audience as these issues are glossed over in CA's documentation and it took me a while to figure out how things worked (and there are still some mysteries).

I appreciate the information, especially since, as you note, it's pretty hard to come by in the available sources. Thanks, again.