Timer thread? Processor <-> Controller?

I know that question about communicating the processor and the controller is a typical thing.
But I’m get stuck.

A document says:

Please note that messages from the processor to the controller must not be sent during the process call! This sending could be not speed enough and then break the real time processing. Such tasks should be handled in a separate timer thread.

What is the timer thread? Is CVSTGUITimer the one?
How do you incorporate it to share various data (except Parameters) between the Processor and
the Controller?
I am stuck on how to make the threads communicated.

So far, I’ve tested a code bellow and it works in the Controller,

CMessageResult My_Controller::notify(CBaseObject* sender, IdStringPtr message)
{
	if (message == CVSTGUITimer::kMsgTimer)
	{
		refreshGUI(global_A); //Get value of a global variable and reflect it on GUI.
		return kMessageNotified;
	}
	return kMessageUnknown;
}

but with a global variable that is accessed also from the Processor.
So if the same plugin was inserted multiple times, they will be synced.
Then I’ve tried declaring timer and notify in the Processor like as I wrote in the Controller. And I wrote sendMessage() into the notify.
Compile failed.

I’m a beginner in C++, so please forgive me if I repeat some elementary questions.
Thank you.

Hi, what kind of data do you want to share and how often is the data updated?

Thanks for your reply.
It sharing some of MIDI data from the processor to the controller every MIDI note on (or off), and GUI changes like buttons on/off from the controller to the processor, the shared data type could be mostly integer or array.
Yes, I am making a midi effect plugin.

I’ve noticed that it is laggy firing notify() in the process function. May be this is what the document saying.
So I doubt I am doing something not efficient.

Hi, you need to use two wait free queues to communicate changes between the part that runs in the real time thread and the other parts. The queues need to be wait free as otherwise there will be unpredicted audio drop outs. The realtime thread is called already periodically where you can check the queue if there’s new data available. For the other threads you need to find a way to check the queue periodically for example with a platform dependent run loop timer callback. The data you get out of the queue on the non-realtime thread can then be send via a message to your controller.