sendMessage() Cubase vs Reaper

Developer VST 3 SDK
1

Hi guys,

My plugin communicates from Audio side to the controller using the method: ComponentBase::sendMessage (IMessage* message).

This works great in Cubase, my Controller is notified asynchronously (on the GUI thread) of the message. I read the message and update my GUI. All good.

In Reaper I noticed this method directly (synchronously) calls straight into my method: controller::notify( IMessage* message ) from the process thread. Mayhem ensures as the GUI trashes itself thru accessing it’s data from two different threads at the same time. (This is also bad news from the perspective of blocking the process thread).

Clearly Cubase implements some type of non-blocking message mechanism (e.g. a non-blocking FIFO / ringbuffer ) which is what I would expect. Reaper does not.

Now, I can implement my own ringbuffer on top of the SDK, but isn’t that silly if Cubase is already providing that service? Can this be considered a bug in Reaper? or is the VST3 spec too loosely specified in this area? Having different interpretations of the spec is asking for trouble and placing extra burdens on plugin developers.

Can we have some guidance on the specification of the message mechanism. What are the requirements for implementers regarding concurrency and thread-safely?

Cheers,
Jeff McClintock

1 Like
2

Hi,
even in Cubase you should not call sendMessage from the process thread. From the documentation :

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.

But yes, you’re right that Reaper has to post the message on the UI Thread.

Cheers
Arne

3

Thanks Arne,
So I will implement a worker thread to pass messages from the processor. I will also blame Reaper for not posting the message on the foreground GUI thread. :slight_smile: