Linux timer

Developer VST 3 SDK
1

I am trying to port a plugin to Linux and I run into this issue:

Timer* Timer::create (ITimerCallback* callback, uint32 milliseconds)
{
	assert (false && "DEPRECATED No Linux implementation");
	return nullptr;
}

On Windows and macOS, Timer::create works but fails on Linux due to the assert statement.

Is there a reason why there is no implementation for Linux? If I have to provide my own implementation, any idea what I could use?

Thanks
Yan

2

From digging in the code it seems that on Linux, hosts must provide an implementation of IRunLoop which has an api to use timers…

That being said I can’t seem to find any example of how I would get a hold of such an API both from the GUI and the RT.

Any help appreciated.

Thank you

3

Also stuck on the same problem and would appreciate some help.

4

I tried to use the CVSTGUITimer as well but that also failed due to some other error:

[Valid State Transition 32bits]
/workspaces/plugins/vst3sdk/vstgui4/vstgui/lib/platform/linux/x11timer.cpp:28: Assertion 'runLoop' failed. Timer only works of run loop was set
validator: /workspaces/plugins/vst3sdk/vstgui4/vstgui/lib/vstguidebug.cpp:124: void VSTGUI::doAssert(const char*, const char*, const char*, const char*): Assertion `false' failed.
5

I changed the design now and use std c++ thread library instead of using the Timer class from the vstsdk and got it working on Linux as well.

	void MyProcessor::sendData()
	{
		std::thread myThread([&]
		{
			IPtr<Steinberg::Vst::IMessage> message = Steinberg::owned(this->allocateMessage());
			if (message)
			{
			     message->setMessageID("MyMessage");
			     message->getAttributes()->setFloat("myValue", myValue);
			     sendMessage(message);
            }
		});
		myThread.detach();
	}

sendData function is called from the process function

6

@singularity1991 Yes I am sure it “works”, but it is clear that the behavior is not the same and might lead to some issues. With a real UI Timer (macOS / Windows), then you are guaranteed that the code runs on the UI thread, so in a sense it is single threaded and the order is well defined.

This code may end up sending data out of order (since it just creates a thread to do the job, so if you call sendData on each frame for example, it is not guaranteed the order you will send/receive).

It is also not clear (nor specified) how “sendMessage” behaves, but the host could be calling the receive side synchronously, and so now your UI is not thread safe because the UI thread is still rendering your UI while myThread sendMessage receiver is called on another thread…

None of these problems would exist if we could simply post an action into the UI thread queue…

7

We now have released a fix for this issue in VST SDK 3.7.9. But note, that the hosts first need to adopt to this change in order to be used by the plug-ins.

8

Thank you!