In order to detect if route delaylines need to be updated,
aux-send delaylines need to be updated first. This was previously
done directly in the latency-callback, which may be concurrent
with processing.
Now only the information (pending_delay) is set, and the actual
change happens later at the end of process().
Due to _init_countdown when the engine starts, it is
extremely unlikely that Session::initialize_latencies(),
which is invoked by AudioEngine::Running runs concurrently
with Session::process, but at least in theory it would be possible.
block_processing() may hold the process-lock, waiting
for the latency-lock. at the same time audio-engine
may hold the latter, trying to acquire the former.
Just like PluginInsert::update_sidechain_name, the name is
implicitly set, using the owning route's name, suffixed with the
[i18n localized] Processor name.
This fixes an issue if a track is renamed and a new track with
the old name is created. This commonly happens during File Import:
For each ImportAsTrack a generic named track (e.g. "Audio") is created
before it is renamed.
Previously this lead to
Failed to register port "Audio 1-trig/midi_in 1", reason is unknown from here
This works around a race-condition, calling d'tors from
two threads concurrently.
The GUI thread destroys ctrl surfaces. ~~MIDIControllable()
calls ::drop_external_control() -> ::midi_forget()
This unsubscribes from signals (notably MIDI::Parser events)
by calling ScopedConnection::disconnect(), Connection::disconnect().
At the same time auto_connect_thread can call
PortManager::clear_pending_port_deletions() which removes
the MIDI port and destorys the MIDI::Parser.
~Parser() calls Connection::signal_going_away() to invalidate
connected signals.
This can deadlock if it is called concurrently with
Connection::disconnect() on the same signal.
see also
https://discourse.ardour.org/t/ardour-session-close-hangs/106523/10
When loading a session, we now just set up port state, which will
populate the Port::_connections member, and then once all ports have
been created, use PortManager::reconnect_ports() to get everything connected.
Previously Ardour only announced processor latency.
Routes that had additional latency to compensate for those
have not published this delay.
This is of no concern with internal backends, however with JACK,
Ardour reported incorrect *individual* port-latencies of
routes that perform PDC.
Since public port latency now includes delay-compensation,
some extra work is required to unset it before recalculating
latency of paths that include external ports.
resort_routes() is a no-op during session destruction,
however _current_route_graph can still hold references
to routes. A GraphVertex is-a boost::shared_ptr<Route>.
* remove unused variables in session.h
* move default play speed (varispeed(sic)) into fsm
* request_transport_speed should -never- set the default_play_speed
* remove unused variables in session.h
* move default play speed (varispeed(sic)) into fsm
* request_transport_speed should -never- set the default_play_speed
Prior implementation:
Bouncing a range and naming it "chorus" resulted in:
..a region per track, and they were all named "chorus"
...a file per track, with the name "chorus-{playlist name}"
New implementation:
Bouncing a range and naming it "chorus" results in:
..a region per track, with the name "chorus-{playlist name}"
...a file with the same name as the region
The TransportFSM is now responsible for deciding what to do at all transport state transitions. The Session (via the TransportAPI) merely
provides mechanism (locate, start, stop, set_speed). Default and most recent speed requests are managed by the TransportFSM too
"While 'atomic' has a volatile qualifier, this is a historical
artifact and the pointer passed to it should not be volatile."
Furthermore "It is very important that all accesses to a
particular integer or pointer be performed using only this API"
(from https://developer.gnome.org/glib/2.68/glib-Atomic-Operations.html)
Hence initialization of atomic variables is changed to also use
this API, instead of directly initializing the value.
This also fixes a few cases where atomic variables were
accessed directly.
see also libs/pbd/pbd/g_atomic_compat.h
Since 6.0 take-name was not updated correctly:
The name changes in Session::non_realtime_stop(). At that
time tracks are still record-armed and ignored name changes.
Newly created tracks also never had a diskstream name set
correctly. This only happened at session-load via set_name(),
or config change.
The JACK API doesn't allow server calls from inside a server callback, even though JACK2 doesn't enforce this.
It would be nice to find a way to NOT call Session::setup_bundles() from every port registration callback, too.
Retain engine speed across stop/start/locate, so that it is
possible to run a loop at non-unity speed. User must
explicitly reset to 1.0 if default speeds are set to !1.0
This fixes an issues with missing monitor-sends when creating
a session from a template with monitor-section, or when creating
tracks from a route-template.
i18n must be included last, after all template specialization.
Otherwise the following happens:
In file included from ../libs/pbd/pbd/i18n.h:22:
../libs/pbd/pbd/compose.h:122:6: error: call to function 'operator<<' that is neither visible in the template definition nor found by argument-dependent lookup
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).