This can happen when a device is already connected
while Arodur is stating. The butler thread may activate it
(immediately post-engine), while the GUI thread tries
to do the same later when restoring state.
* reserve "probe" to actually probe for devices
* use separate probe for libusb and MIDI port devices
* use "available" to check if surface can be used
* allow both methods to be NULL
* remove unused ControlProtocolDescriptor* argument
Most surface just return `true` for available.
In case of internal backends this allows to retrieve the
Device name for a given (hashed unique) port-name.
As opposed to "pretty-name" (which defaults to hw-port-name),
this cannot be changed by the user.
It is intended to be used when probing for control surfaces.
In case there are any unconnected tracks, the track's output is
assumed to align to the master bus (see Route::update_signal_latency).
For this to work correctly the master bus port's public latency
has to be set first.
This fixes e.g. the following issue: add a latent plugin to
the monitor section. Then toggle its bypass or remove it.
Previously the worst-case latency remained unchanged.
VST3PI::performEdit already updates the shadow data, so
since 979f9876a7
VST3Plugin::set_parameter effectively did nothing (unless a user
rapidly moves the control slider, in which case the next process
cycle sets a previous value).
~Session calls AudioEngine::remove_session(), which fades out,
then unsets the session, and then in libs/ardour/audioengine.cc:460
```
session_removed.signal(); // wakes up thread that initiated session removal
```
Session d'tor continues, and calls Port::PortDrop(), which
unregisters all ports one at a time.
Concurrently, AudioEngine continues, and calls PortManager::silence_outputs
which gets all ports first (!), and then iterates over them.
There is a race condition which can lead to
DummyAudioBackend::get_buffer: Assertion `valid_port (port)' failed
This fixes a "too many sections" issue
```
Fatal error: can't write 159 bytes to section .text of build/libs/ardour/luabindings.cc.1.o: 'file too big'
x86_64-w64-mingw32-as: build/libs/ardour/luabindings.cc.1.o: too many sections (36781)
```
This also mitigates an issue that selecting a track in
a group may select other tracks. Previously the last
selected track's input was connected to MIDI ports, which
is usually not the track that the user clicked on.
There is no need to preallocate request buffers for these threads - the event
loops that require them can allocate them when they discover and register the
pre-registered threads. This also means that event loops do not need to
register request buffer factories.
