This is not complete, because the symol names are identical, and there's no way (yet)
to ensure which versions Ardour will use if both are dynamically loaded.
This can happen with snapshots or after save-as with
.ardour session files having different "Names" in the same path.
Or simply by saving a session on macOS in /tmp (which is really
/private/tmp).
This fixes an issue where brining up a menu can directly activate an
action in the menu. Notably on macOS.
Nathan reports that this may also address #9515
Note: mac touchpads are not affected since right-click there is
effectively a "press and hold".
This likely needs checking for all surfaces that inherit from MidiSurface. It is clearly
the correct thing to have in the code, but existing behavior might be predicated on
the former incorrect connection
freetype on macOS does not scale fonts, font-scale and ui_scale
have to remain at 100% otherwise other UI elements change size
while the font does not.
This is perhaps a better solution than b8551eed7e
and 8d0a655608 and 7942897d93. It is certainly less
fragile.
It is more consistent with other plugin standards,
where modules are closed with the last instance in a session.
Then again keeping the VST3 factory around is beneficial
when switching snapshots.
Discuss, and let's watch for issues when re-loading a
previously unloaded VST3 module.
The InstrumentSelector keeps a PluginPtr reference to all
instruments. By default Ardour does not destroy the editor
at exit, So 3 instances of Instrument Selector can remain
* TriggerClipPicker in the editor sidebar (owned by _editor)
* TriggerClipPicker on the TriggerPage (owned by trigger_page)
* SoundFileOmega (sfbrowser owned by Editor)
If a shared_ptr reference is retained, VST3 Module is not
unloaded at exit. This leads to issues with various plugins.
eg. Reason Rack does not terminate, Ardour hangs at exit.
There is no thread when an AbstractUI<T> is constructed. The event loop name and the
association between the event loop object and the thread that "runs" it must be
set from within the thread, which is not created until BaseUI::run() is called.
There appears to have been some confusion in e3569b64 about how this
all works; this commit should remove that
