In some rare cases the butler may be busy for a long time
(e.g. seek in a large session may still be active when
export is started).
8 second timeout seems reasonable to prevent the app from hanging
without desktops showing a "unresponsive" popup in case the
timeout is reached for some reason (e.g the engine dies, and
no TFSM transition can happen).
Previously the bindings were given to the Region/* equivalents and made insensitive if there was no selected region.
Given that we have specific actions for nudge-playhead-*, and the ones in Region/ will always work on regions
if there are any selected regions, this provides a better set of possible actions, even if the naming is not
totally consistent.
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.
