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
e.g. selecting a track causes a ControlNotFoundException
if the ctrl surface is enabled, but no hardware is connected.
terminate called after throwing an instance of 'ArdourSurface::ControlNotFoundExceptio
```
#0 0x00007ffff14d8c2e in __cxa_throw () at /lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x00007fffe2b560a0 in ArdourSurface::Console1::get_button(ArdourSurface::Console1::ControllerID) const (this=0x61d0017e1c80, id=ArdourSurface::Console1::FOCUS1)
at ../libs/surfaces/console1/console1.cc:928
#2 0x00007fffe2bfc647 in ArdourSurface::Console1::map_select() (this=0x61d0017e1c80) at ../libs/surfaces/console1/c1_operations.cc:653
#3 0x00007fffe2b55384 in ArdourSurface::Console1::map_stripable_state() (this=0x61d0017e1c80) at ../libs/surfaces/console1/console1.cc:832
#4 0x00007fffe2b541ab in ArdourSurface::Console1::set_current_stripable(std::shared_ptr<ARDOUR::Stripable>)
...
```
This does at least fix the crash. Ideally the surface would
only be enabled if there is hardware present.
Some plugins call restartComponent(Vst::kParamTitlesChanged)
when their GUI is created, from the call that creates the UI.
This lead to a stack-overflow recursion in Ardour:
ProcessorBox::redisplay_processors -> VST3Plugin::has_editor
-> [plugin] -> VST3::restartComponent -> signal proc changed
-> ProcessorBox::redisplay processors
Since 62fc1d3c2e, Delivery buffers were flushed twice.
Once by copy_to_outputs() and again later by
Delivery::flush_buffers. This resulted in duplicate events
during export (see 576840c09e, MIDI buffers are not cleared
after flush to allow export processing to grab the data from
the port-buffers).
The workaround in 62fc1d3c2e is only relevant for ClickIO,
other Deliveries (Send is a Delivery) are explicitly flushed
by Route::flush_processor_buffers_locked.
This reverts commit 615326be9b because it
breaks windows builds.
```
File "/home/ardour/ardour-w64/wscript", line 1462, in configure
set_compiler_flags (conf, Options.options)
File "/home/ardour/ardour-w64/wscript", line 522, in set_compiler_flags
if re.search ('x86_64-w64', conf.env['CC']) is not None:
File "/usr/lib/python2.7/re.py", line 146, in search
return _compile(pattern, flags).search(string)
TypeError: expected string or buffer
```
