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.
* use dedicated sort-order (fix issue with order being forgotten
when results are filtered)
* add support for recent and most-used plugins
* add a text-entry search filter for favorites
* remove tag-filter drop-down
* ignore v5 instant.xml plugin sort order
