Handle connection point proxy from GUI thread

FabFilter plugins will exchange messages that have to be handled from
the GUI thread, or they'll get stuck waiting on a synchronisation
object. This probably hurts GUI performance significantly but luckily it
only affects Ardour.
This commit is contained in:
Robbert van der Helm
2021-01-24 15:42:25 +01:00
parent 77414c80d6
commit 21ff906bf8
2 changed files with 16 additions and 4 deletions
@@ -52,7 +52,11 @@ Vst3ConnectionPointProxyImpl::disconnect(IConnectionPoint* /*other*/) {
tresult PLUGIN_API
Vst3ConnectionPointProxyImpl::notify(Steinberg::Vst::IMessage* message) {
if (message) {
return bridge.send_message(
// FabFilter plugins require this to be done from the GUI thread so we
// need to use our mutual recursion mechanism. Luckily only Ardour uses
// connection proxies, so if this ends up breaking something it will
// only affect Ardour.
return bridge.send_mutually_recursive_message(
YaConnectionPoint::Notify{.instance_id = owner_instance_id(),
.message_ptr = YaMessagePtr(*message)});
} else {
+11 -3
View File
@@ -280,9 +280,17 @@ void Vst3Bridge::run() {
// We should thus be passing a (raw) pointer to the
// original object so we can pretend none of this wrapping
// and serializing has ever happened.
return object_instances[request.instance_id]
.connection_point->notify(
request.message_ptr.get_original());
// NOTE: FabFilter plugins require some of their messages to be
// handled from the GUI thread. This could make the GUI
// much slower in Ardour, but there's no other non-hacky
// solution for this (and bypassing Ardour's connection
// proxies sort of goes against the idea behind yabridge)
return do_mutual_recursion_or_handle_in_main_context<tresult>(
[&]() {
return object_instances[request.instance_id]
.connection_point->notify(
request.message_ptr.get_original());
});
},
[&](YaContextMenuTarget::ExecuteMenuItem& request)
-> YaContextMenuTarget::ExecuteMenuItem::Response {