This allows to move or copy whole sections of the timline (everything
you hear) to a differnt position on the timeline.
NB. Markers and tempo-map are not yet moved, and interpolated MIDI
events are lost.
This is never for inline references to parameters, only for starting parameter
documentation blocks. The "@p" command is for this, although unfortunately
Doxygen doesn't actually do anything with it and it's just an alias for code
text.
This is required to collect relevent undo/redo information, notably
automation-data changes from Playlist::update_after_tempo_map_change and
DiskReader::playlist_ranges_moved.
The realtime thread should not move regions to begin with, and debug
builds woudl also assert since no undo operation was started.
This fixes a deadlock, because tempo-map write copy
was not released. A later call to TempoMap::write_copy
will deadlock and in this case also hold the process lock.
This can happen if there is more than one tempo on the
timeline or if the tempo-difference is too large.
This moves the _amp from send to delivery (which already
applies gain for the master-bus normalization). This generalizes
the use of a gain stage for use in port-inserts.
Previously active Routes were retained until the end of
Session d'tor and not dropped during Session::destroy.
While most resources were explicitly cleaned up via DropReferences,
Processor UIs are kept around until the actual destructor runs.
Likewise some controllable are kept around while the GraphNode (Route)
owning it is not released.
Session dirs must exist when loading Sources of a project.
SourceFactory::init() starts the PeakFileBuilder background thread
early on when libardour is initialized.
This thread [re-]creates missing peak files when Sources are
created or loaded. However AudioSource::prepare_for_peakfile_writes
assumes the peak/ folder exists. This may not be true, which lead to
"AudioSource: cannot open _peakpath [..] (No such file or directory)"
errors.
Also drop creation from Source::get_transients_path() as this
may be called concurrently from Analyser background threads.
When a session-range coincides with a loop-range location, moving
the session-range also updates the loop-range.
Keeping session and loop-range in sync can be useful if the whole
session is looped. However markers are treated individually, so
we need prevent invalid ranges.
If session-start and loop-start coincide, but loop-end is before the
end-marker, it is possible to move session-start beyond the loop-end.
There is no longer an extra set of rt-threads, but existing
process-graph threads are reused.
There are two main benefits to this approach: graph-threads
have a SessioEvent pool and ProcessThread buffers. They are
also joined to work-groups (on macOS), or JACK created threads
(cgroups).
* don't create a new MixerScene if one already exists
* only resize the vector when necessary
* adding a new scene at position N should not shrink the vector size
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.
This allows to pass any GraphChain to the Graph to process.
It removes the need to use a mutex to swap two dedicated
chains (setup-chain <> active-chain, pending-chain).
Also various special cases pertaining to graph interaction
while auditioning and route-deletion can be removed.
This also unconditionally creates a graph-thread for GraphChains
to be processed, even if the main callback uses a special-cased
sorted RouteList if there is only one process thread.
The process-graph should only be concerned with GraphNodes,
which may or may not be Routes.
This also removes intrinsic connection information from
the graph-node. Connection information is to be kept separate
from the nodes.
When the graph is re-calculated in the background, old information
has to be retained until the new graph becomes active.
Previously *new* information was already stored in the nodes
while the graph is sorted, even though the new graph was not
active.
This commit leaves two issues outstanding:
1. unclear/ugly semantics for drag operations that reset the GUI thread's tempo map to the writable copy
2. undo/redo for the tempo map
These will be addressed in future commits
This allows two reader threads to proceed without blocking each other, as can
happen when the butler renders a MIDI track into an RT-safe buffer while the
GUI reads the same MidiModel/Source for visual display.
We do not want a value as large as the previous one, which limits the time
range that can be represented in 62 bits unnecessarily. The new value is
9 times smaller than the previous value, and loses only 384000 as a significant
factor.
This commit also switches to using an (inline) accessor for superclock_ticks_per_second,
making it possible in debug/testing phases to spot early/illegal uses of the value.
Robin Gareus
Ben Loftis
David Robillard
Paul Davis
Todd Naugle
luz paz