At present only audio data from disk readers is declicked. MIDI tracks with audio output should
likely also be declicked, at which time Session::need_declick_before_locate() will require
amending
previously this subscription was handle done in
Route::add_routes() -> add_routes_inner() for MIDI tracks only.
Since f6c0b02d9f this was only done when adding
tracks, after any instruments were loaded (and fanned out).
This consolidates instrument creation for midi tracks & routes.
If an instrument is added, output auto-connect is postponed until
after the instrument plugin is added. Also when a multi-channel
instrument is fanned-out, the track outputs are not auto-connected.
This also subscribes MIDI-Busses to auto-connect when an instrument
is loaded or replaced at a later time.
Since fan-out happens (interactively) in the GUI thread,
we need to keep track of this, in order to prevent later
auto-connection of the track to the master-bus.
..forth and back..
1882c1ba7edabd5715e9fac8d84786
This needs a [much] better solution:
e.g. Wait until instrument is instantiated (ports are created),
then auto-connect, and finally fan-out
(or alternatively skip auto-connect for fanned-out tracks).
Currently both auto-connect as well as fan-out and port-creation
take place asynchronously.
Also MIDI track subscribe to &Session::midi_output_change_handler,
(MIDI busses don't).
This may (or may not) fix#8317. Usually changing I/O triggers
an auto-connect. The actual issue seems that auto-connect
thread runs before the ports are created.
This significantly speeds up parsing MIDI files with complex
tempo-maps. e.g. "Black MIDI Trilogy_2.mid" has 24134 Tempo
changes. Prior to this commit parsing that file took over 5 minutes.
now it loads in under one seconds (libsmf only; libardour still
add overhead, and now needs about 30-40 seconds, previously
it took about 10 mins).
The problem was that every call to `smf_track_add_event_pulses()`
calls `seconds_from_pulses()` which calls `smf_get_tempo_by_seconds()`
which iterates over the tempo-map:
for every midi-event { for ever tempo until that midi-event {..} }
This does not scale to 3.5M events and 24k tempo-changes.
see also https://github.com/stump/libsmf/pull/7
* Fix validity checks of escaped data
* Handle non-EOT-terminated tracks.
* Fix buffer overflow on tempo change event
* Fix memory leaks in case loading fails
* Fix a logic errors in extract_escaped_event()
* Fix the assertion problem `is_sysex_byte(status)`
* Make libsmf more tolerant to malformed MIDI files.
(fixes import of files generated by NoteEdit)
https://lv2plug.in/doc/html/group__options.html specifies
a NULL terminated array of options (not a single option).
Since the call is the "instantiation" LV2 threading class, and
a single fixed value is passed with a direct call into the
plugin, using a stack-allocated LV2_Options_Option is sufficient.
This is only relevant with JACK, where different implementations
use threads for the latency callback.
With jack 2, jack_port_register() blocks and the jack_latency_callback
arrives in a different thread: https://pastebin.com/mitGBwpq
with jack 1 the callback arrives in sync
In either case this usually happens while
_adding_routes_in_progress == true and Ardour holds the process-lock,
because jack2 can process in parallel with reconfiguring latency
See also 1983f56592
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.
