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.
Bindings were not loaded until after ProcessorBoxen were created,
meaning they had no effect (the ProcessorBoxen set their ardour
bindings to null).
Also handle leave-means-deselect at ProcessorBox level rather than
MixerStrip level, to include MonitorSection PB
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).
We now use the same actions in all modes, and the logic is:
1. is there a selected mixer strip and are we in it: if so, delete selected
processors
2. are we in draw or internal mode? if so ..
2a. if there are selected control points, delete them
2b. if not, attempt to delete MIDI notes
2c. done
3. continue with delete operation as before
~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.
The old code assumed that the thread that created a request buffer for a given
signal-emitting thread would be the latter thread, and thus a thread-local
pointer to the request buffer could be used. This turns out not to be true: the
GUI thread tends to be responsible for constructing the request buffers for
pre-registered threads.
That mechanism has been replaced by using a RWLock protected map using
pthread_t as the key and the request buffer as the value. This allows any
thread to create and register the request buffers used between any other pair
of threads (because the lookup always uses a pthread_t).
The symptoms of this problem were a signal emitted in an audioengine thread
that was propagated to the target thread, but when the target thread scans its
request buffers for requests, it finds nothing (because it didn't know about
the request buffer). In a sense, the signal was successfully delivered to the
target thread, but no meaningful work (i.e the signal handler) is performed.
Because we use the non-callback API, we can call our thread init callback
ourselves from ::process_thread(). In addition, the init_callback in JACK is
used by every thread JACK creates, including the messagebuffer thread, and this
confuses things from an Ardour POV where the callback was intended just for
realtime threads.