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?