When removing a plugin-insert that has a sidechain on a bus
that is implicitly soloed the following happens:
* Route::remove_processor() takes a WriterLock(_processor_lock)
* The sidechain input is disconnected
* Route::sidechain_change_handler() is called which calls
* Route::input_change_handler()
* Since the route is implicitly soloed, propagation is attempted
which calls
* Route::direct_feeds_according_to_reality()
which takes ReaderLock(_processor_lock)
Recursive locks, reader-lock after writer-lock don't cause
a deadlock, releasing the reader-lock effectively also
releases the writer-lock...
Polygons used PolyLine::render() to render the path.
However since 7bb8ca1e76, the PolyLine path is constrained
(for automation lanes), and closed shaped polygons were not
always completely redrawn.
It is possible that Route::monitoring_state() returns
(MonitoringDisk | MonitorSilence)
This lead to various cases where there were is a direct comparison
(ms == MonitoringDisk). DiskReader::run tests for MonitoringDisk
to check if the buffer needs to be zeroed while locating.
Likewise Route::process_output_buffers() also explicitly tests
for both MonitoringDisk and MonitoringDisk.
The issue was likely introduced in fbe8075117 (although
it may have been possible in earlier version when using hardware
monitoring as well).
Previously add_remove_sidechain() released the process-lock
(to create the I/O ports), while keeping a processor writer-lock.
Meanwhile the auto-connect thread may be woken up to perform
a latency update. This thread takes the process-lock and
then stalls, waiting for a processor reader-lock.
Then add_remove_sidechain() continues and tries to re-acquire
the process-lock.
Previously the GUI explicitly called remove_preset() before
saving a plugin-preset. This functionality is now moved
into the backend.
This fixes a case when a user tries to save/replace factory presets
and works around https://github.com/lv2/lilv/issues/37
Register all plugin props that we may be interested in
to _property_values, and later intercept all messages for
registered properties (not just atom_Path).
This partially reverts 208c781248
in order to fix monitoring when using punch-in/out.
This also allows to revert to Ardour 5 style MIDI exclusive
Input or Disk monitoring when not using layered-recording.