Instead of serializing the actual `YaMessage`, for the reasons mentioned
in the comments. This was needed to stop iZotope VocalSynth 2 in Ardour
from segfaulting when editing parameters, because that plugin is
apparently being very naughty.
They're exchanging pointers between the processor and the controller
using messages. And not only that, they're storing the message objects
instead of storing the pointers.
I've also tried a lot of other things, but none of the solutions I've
tried work 100% of the time. It sounds like a better idea to have
something that doesn't work consistently than to have something that
inconsistently sort of works. Setting the size in `WM_WINDOWPOSCHANGING`
to (0, 0) fixes the drifting, but the mouse coordinates are still wrong
and `SetWindowPos()` breaks the reparenting.
This reverts commit db2cc5800a.
I think some rounding in Wine is causing this issue, but then again
we're not supposed to send these ConfigureNotify events to the window
directly anyways.
This is needed to support Ardour. These extra hops and serialization
steps will probably hurt performance, but outside of some huge hacks (to
connect the components directly anyways) there's not much else we can
do.
I copied this from the SDK implementation and they don't do any pointer
casts there because it's not strictly necessary, but they're relying on
implementation details that may not always hold true.
It's not necessary, since all of these objects are simple data objects
that will be passed as arguments to other functions. When we have to
pass through one of those functions we can just serialize the objects at
that point.
iZotope plugins will already send messages when connect() is called on
the first object, so this flag has to be set on both host contexts at
the same time.
In the host context. So when the plugin wants to create an `IMessage`
object to send a message to the other object, we don't have to go
through the host.
This has much fewer moving parts, and it's probably more understandable.
There was also a race condition in the previous implementation, so
there's that.
This requires a super hacky workaround because the UI thread can be
currently blocked by the plugin calling `IPlugFrame::resizeView()` from
the Win32 message loop.
Robbert van der Helm