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...
This supersedes 0708cdb6b4, an explicit `name_label.show()`
is not needed. The inactive label was missing an explicit call
to show.
This also fixes MIDI track MIDNAM Selector visibility
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.
When ripple moving a region all the subsequent regions will be moved, next
region in the playlist after the dragged one first, last region of the playlist
last.
Thus, when an automation point is ripple moved along a region past the starting
point of the next region, it will be moved again along with the next region as
the move of the next region occurs after moving the automation point.
This fix reverses the sequence of the ripple moves, last region in the playlist
will be moved first, the next after the dragged one, last. So no temporary
overlap of regions will occur.
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).
This was done semi-automatically starting with
```
help2man -N -n "digital audio workstation" \
--version-string=6 \
-o ardour.1 gtk2_ardour/ardev
```
and then manually replacing "ardev" with "ardour" as well as
various upper-case and all-caps variants thereof.
The existing midi map for the M-Audio Oxygen controller did not work for me.
I note that my controller says 3rd Gen on the back
I used the documentation: https://manual.ardour.org/using-control-surfaces/generic-midi/midi-binding-maps/ to create a new map.
I think adding it to the rest of the files might be better than overwriting the old one, but happy for others to decide.
Maps the transport control buttons on the device only. They are labelled C10 to C15 on the controller, and map to 113 to 118 in the file.
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.