This fixes several callsites that were passing samplepos_t to get a TempoMetric,
some of them somewhat significant (e.g. VST plugins that want tempo information).
Bad API design on my part, apologies.
This commit combines libs/ and gtk2_ardour because the new private status
of the ::metric_at() call would be a blocking point for git bisect
When starting RangePlay while the transport is already rolling
the transport is now stopped (and de-clicked) before locating.
This should not clear the RangeStop event when it is caused
by a RangePlay request.
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
Previously only adding an aux-send triggered a graph-reorder but copying
or deleting sends did nothing.
Adding/removing an aux-send may not even change the graph, but
both upstream/downstream latency can change and delaylines need to be
configured (which is done by calling update_latency_compensation with
force_whole_graph = true).
This fixes an issue with incorrect initial latency compensation after
copying a send (any later change to connections will correctly
recalculate it).
Add a list of marker locations to the session, for the the UI to add the
current location to when "add-region-cue-marker" happens whilst recording.
On record-stop, create source markers at the locations in that list in all
newly-recorded audio regions.
The pre-nutemo code used fmod() to calculate the offset into the bar:
`bar_fract = fmod (barbeat, 1.0); // fraction of bar elapsed`
with nutempo, beats start at 1, and the tick offset must also be
taken into account.
The bug was introduced in f67029bd0
if a slot becomes active, and the transport is not rolling, it still
asks the transport to roll. however, (1) there's only 1 request across
all triggerboxen (2) the request will not be handled till the next
process cycle (3) the triggerbox returns after the request i.e. it
waits until the transport is rolling
No behavior should be changed by this modification; the argument has a default value of false, which
matches previous semantics, and every instance where the argument is specified, it is given as false.
Session::route_processors_changed accumulates signals emitted
in realtime and processing is delegated to a dedicated rt-safe
thread. Previously this resulted in any changed to be converted
to a `GeneralChange`, which unconditionally triggered a route-reorder.
Record-arming a track causes a MeterPointChange (meters change to "in"),
and this caused routes to be resorted and a latency-update.
While the former is reasonable (Ardour prefers to process
rec-armed routes first), the latter certainly is not.
We know when we call non_realtime_stop() if we will be subsequently
locating. If so, do not do an additional non_realtime_locate() from
within the stop.
There is no event processing after the locate, and so the event that is (was)
queued at the loop start will not be processed, and each time we reach the
loop end, we will try (and fail) to queue an identical event (fail because
duplicate events are not allowed). We don't need this event (or signal) at
all, because locates (and then ::start_transport() while looping do not
represent a state change that any UI needs to know about.
TransportStateChange() triggers various updates.
However at the time the signal is handled
`transport_rolling()` and/or `transport_state_rolling()`
may still return false.
This fixes incorrect In/Disk display on tracks (RouteUI)
and incorrect automation write-pass handling,
when toggling stop/play.
This is for at least two reasons: transport will effectively
move with 32 samples * 6.25% = 2 samples per cycle and the
resampler cannot up/downsample a factor of > 16 with
reasonable quality.
Paul Davis
Robin Gareus
Ben Loftis
Colin Fletcher
luz paz