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).
Previously add_remove_sidechain() released the process-lock
(to create the I/O ports), while keeping a processor writer-lock.
Meanwhile the auto-connect thread may be woken up to perform
a latency update. This thread takes the process-lock and
then stalls, waiting for a processor reader-lock.
Then add_remove_sidechain() continues and tries to re-acquire
the process-lock.
This partially reverts 208c781248
in order to fix monitoring when using punch-in/out.
This also allows to revert to Ardour 5 style MIDI exclusive
Input or Disk monitoring when not using layered-recording.
The GUI uses ::axis_view_by_control() if a controllable when
the CoreSelection contains a controllable.
CoreSelection::get_stripables() saves and looks up controllable
by PBD::ID. Panorama automation controls were previously
not found, since they are not directly owned by the route.
So far internal-sends were explicitly special-cased, and implicit
solo-state only was only forwarded for direct up/down-stream
connections. ...and nobody can remember why :)
This restriction is removed, so far mainly with commenting-out
code, as experiment.
Internal sends are not only more convenient, but also required
in cases where direct connections result in ambiguous latency.
This fixed a false-positive "ambiguous latency" warning for
MIDI busses:
MIDI track -midi-> MIDI Bus w/instrument -audio|midi-> master
The master-bus only has audio inputs, so the MIDI Bus'
MIDI out is left unconnected. Its latency does not matter,
it can float freely.
Previously it was assumed to be zero. So the MIDI Bus' input
playback latency range was [0, master-bus playback-latency].
Various backends have different strategies for updating latencies,
and different thread semantics for latency update callbacks.
With jack2 it is possible that processing happens concurrently
while port latencies are being changed.
Ardour internal backends emit the latency callback from the
main process thread, serializing latency changes with processing.
Various user actions can also trigger latency changes. e.g.
with a stopped engine it is possible to re-order plugins.
IO::latency iterates over the port-set retrieving the
private_latency_range of each port. Since it can only change
when connections and latency changes, we can instead cache the value.
This is also in preparation to allow the auditioner to override it.
* Signals use camelcase.
* use a static signal, independent of the route
Previously the signal was handled by RouteUI, which
caused various issues:
* the RouteUI may not yet be available
* There may be many RouteUIs for a single Route
(mixer, editor-mixer, meter-bridge strips)
* Remove unused direct calls into plugin
* Assume empty model to mean plugin-provided MIDNAM (!)
The route owned Instrument-Info is the central access point used
by the GUI for MIDI name lookups.
At this point in time, custom settings are saved/restored by the
GUI (MidiTimeAxisView). InstrumentInfo provides a volatile store
for MIDNAM mode and model.
This fixes another assert(), caused by configuring processors,
before set_processor_state() was called.
Route::configure_processors() will be called later.
---
#3 0x00007ffff2472102 in __GI___assert_fail at assert.c:101
#4 0x00007ffff7a8ca1f in ARDOUR::Route::setup_invisible_processors() at ../libs/ardour/route.cc:5013
#5 0x00007ffff7a7a665 in ARDOUR::Route::configure_processors_unlocked at ../libs/ardour/route.cc:1870
#6 0x00007ffff7a79377 in ARDOUR::Route::configure_processors at ../libs/ardour/route.cc:1719
#7 0x00007ffff7a902c0 in ARDOUR::Route::set_disk_io_point at ../libs/ardour/route.cc:6041
#8 0x00007ffff7a7ea0a in ARDOUR::Route::set_state at ../libs/ardour/route.cc:2679
Previously set_state() -> set_meter_point() acquired the
process-lock to change meter-position, usually causing x-runs
when setting route-state.
This also fixes an issue introduced in fd414ec158. After
populating the processor list, force setting the meter-position
looks up the output streams of the processor before the meter.
However the processors are not configured. That will only happen
later from Session::post_engine_init().
---
#3 0x00007ff07b7d4102 in __GI___assert_fail at assert.c:101
#4 0x00007ff080d3224a in ARDOUR::PluginInsert::output_streams() const at ../libs/ardour/plugin_insert.cc:289
#5 0x00007ff080de8c30 in ARDOUR::Route::set_meter_point_unlocked() at ../libs/ardour/route.cc:4106
#6 0x00007ff080de8699 in ARDOUR::Route::set_meter_point(ARDOUR::MeterPoint, bool) at ../libs/ardour/route.cc:4037
#7 0x00007ff080ddfad3 in ARDOUR::Route::set_state(XMLNode const&, int) at ../libs/ardour/route.cc:269
This fixes the following issue:
On the master channel insert the waveform scope before the fader.
Then set the meter position to custom and move the meter to the
very beginning of the chain.
Before this change, when set_meter_point() was called the
processor list only contained the Fader (_amp) and no other
processor. _main_outs was not yet present in the list, and
Route::maybe_note_meter_position() triggered an
and assert(_processor_after_last_custom_meter.lock());
See also d0dca7daf0
This handles some special cases where a plugin is added after
the disk-writer but before the disk-reader.
The plugin may add/remove ports (e.g. an instrument: MIDI to audio,
or some stereo to mono processors). However we need to ensure
that any data that is recorded will be played back.
This is a new take replacing b2bc934e2.
[Re]name sidechain port directly when a plugin is added.
Usually plugins are constructed without an Route (owner is unset).
PluginInsert c'tor may already create a side-chain port, at the
time of construction the sidechain port will be created using
the port-name "toBeRenamed".
Previously the plugin had to be added to a route using "add_processor",
in order to set a unique name, before a new plugin with sidechain
could be constructed.
ProcessorBox::use_plugins() did that in the correct sequence,
however there may have been cases where this didn't work, and
Route::add_processors() was called directly..
This builds on top of 51d2bb:
* v6 routes templates/states have a version per <Route>
* older route-states are assumed to be from ardour-5
Stateful::loading_state_version 3002,
unless specified otherwise
Currently using Ardour-5 route templates (state version "3002")
with Ardour6 fails. As opposed to session-templates, Route
templates were not versioned.
This ensures future compatibility (and may allow to interpret
unversioned templates as "3002")
* update AFL position when preference changes
* "after post-fader processors (before pan)" is before
the main-out (not at the end).
* Fix "immediately post-fader":
The amp, when added was the last element. ++after_end then
made the iterator point to .end()
This likely worked in the past when the monitor send was added
immediately after adding the fader/amp before any other processors.
While loading a session XML state, set_state must use
`Stateful::loading_state_version`.
When later copying processor state,
`Stateful::current_state_version` is correct.
This also solves bi-stable automation for plugins where latency
can change due to automation. e.g.
cycle 1: run (t): automation (t) = on: -> increase latency
cycle 2: run (t-latency): automation (t-latency) = off -> decrease latency
repeat.
In theory different UIs can show different meter-types, so it
can make sense to maintain the type in different places.
MeterType is a bit-set and PeakMeter implementation provides for this.
However, this is not being used, and the current implementation
was rather fragmented, cross-connected signals to keep types in sync,
allowed inconsistent meter-types in GUI and backend.
MeterType is now kept by meter itself, however it is still
saved/restored as part of the Route state.
N.B. This change breaks the API, various methods have been renamed
for consistency.
This fixes a bug when shift() creates automation for parameters that
can not have any automation (hidden parameters, Mixbus PRE).
The GUI (RTAV) aborts() when it finds an automation lane for
a hidden parameter.
This also cleans up shift() operations in general. Empty automation
lanes should be left alone, no guard-point at zero should be added.
Delaylines are not saved in the XML and internal-return is an
invisible processor not explicitly re-added when the state is restored.
They are [re]inserted during Route::setup_invisible_processors().
So this method need to be called after restoring processor state
(indirectly via configure_processors_unlocked as needed).
PS. During route creation this call happens explicitly and on session load
hookup_io() -> Route::output_change_handler() implicitly sets this up.
Speed up route creation: add_processor() takes a process-lock
and calls configure_processors() but this is done explicitly at the
end of init() already.
Route::processors_changed() signal connects to a same thread session-slot
Session::route_processors_changed() which can end up iterating over
Routes and Processors to re-calculate latency.
This takes a ReadLock after WriteLock, which eventually leads a duplicate
unlock and segfault.
Previously "zero custom/user latency" meant "default plugin latency".
This is now saved in a separate boolean allowing a user to reduce a
processor's latency to zero.
This also prepares for a global switch to use zero latency throughout
the whole session.
This saves some memory (gmsynth loads a 30MB soundfont), and also
re-initializes the synth every time to gm defaults in case some
.mid changes patches or parameters.
When a PluginInsert is created it does not have an owner right away. That's why
a we need to set the sidechains name once the owner is known, in order to
include owner's name into the name.
Furthermore we need to follow renames of the owner.
This is required by 7d8b93ad for showing error when actively recording.
It also prevents other UIs (OSC, Lua,..) to change re-configuring
sidechain ports/plugins while recording.
ensure_track_or_route_name() can produce the current name.
This fixes the following issue:
Create a two audio tracks. Their names are "Audio" and "Audio 1".
Try to rename "Audio 1" to "Audio", its name becomes "Audio 2".
currently this is only used to resolve midi events for plugins
(this is conceptually not correct, note offs should be resolved by
the disk-reader only), but it calls into all processors now (incl
disk-reader if present), which is handy (e.g. flush delaylins)
Pan-automation is evaluated directly from the control-list.
::distribute_automated() does not update the controls.
However, the *owner* of each automation-control is responsible to
evaluate automation of automated automation-controls (and emit Changed()
signals to notify the GUI and slaved controls).
This follow the same concept as PluginInsert: The Changed signal
is called on demand when evaluating automation.
This fixes pan-automation-sliders (automation-lane header) not updating.
This properly sets the port-latencies of PluginInsert owned ports as well
as handles external sends (send-target playback latency).
NB. This needs more work to ensure that Sidechain input port playback
latency is set before the feeding send queries it the connected latency.
Re-ordering process may change sidechain or external-send latencies,
but since re-ordering does not change the route's latency,
engine.update_latency() may not be called.
The processors will becomes responsible to know about loop-positions
and map latency-compensated start_sample, end_sample into the loop-range
as needed.
* Processor implement get_state(), classes derived from Processor
implement protected ::state() -- as documented in processor.h
* likewise for Route, Track: make ::state() a protected interface
* removal of "full_state", use explicit "template_save"
* use RAII/Unwind to skip saving automation-state
Immediate events are used for MIDI-Panic and to inject GUI generated
events e.g. patch-changes, note-events from the track-header
(scroomer-keyboard) and patch-change audition.
Current behavior:
- snapshot copy immediate events from ringbuffer into a buffer at
the beginning of each the cycle.
- Inject immediate events into input-buffer directly after reading the input
- process "normally"
- pass immediate event-buffer to disk-writer, so it can skip them
(don't write immediate events to disk)
- if the Route is not monitoring input: clear buffer before disk-reader
and re-inject (original) immediate events after the disk-reader
- immediate events process normally and are also sent to outputs.
This moves common code (get and fill buffers) into ::passthru()
and renames ::passthru() to ::run_route().
passthru_silence() is no longer used (it was only needed A5 style
Track::no_roll_unlocked for no-roll + disk-monitoring)
Currently ::roll() may actually be a ::no_roll() under some circumstances.
This can also happen during count-in:
transport_stopped () == transport_rolling()
and during latency-preroll:
Global session-transport speed != 0, some tracks already roll,
read data from disk and feed latent plugins.
but other non-latent tracks or busses don't roll and still have to
behave like the switch from no_roll() to roll() has not yet happened.
This changes the game WRT to monitoring as well, previously, Route:roll()
called Route::no_roll_unlocked () for conditions outlined above.
Now Track::no_roll_unlocked is called and in some cases wrongly clears
the buffers before the signal hits the disk-writer. (more work is needed
related to 61f8e53b)
On the upside this also fixes an issue with MidiTrack::no_roll not keeping
a lock while pushing data into the step-edit-ringbuffer.
This is also a step towards consolidating all entry points:
::roll(), ::no_roll(), ::silent_roll() in the Route class.
Individual Routes cannot split the process-cycle in no_roll(); roll()
by themselves. Each of the calls will flush output buffers (and offset
port-buffers). If a route feeds another route the inputs of the other
route will only see partial data.
The general goal is to align transport-sample to be the audible frame
and use that as "anchor" for all processing.
transport_sample cannot become negative (00:00:00:00 is the first audible
frame).
Internally transport pre-rolls (read-ahead) before the transport starts
to move. This allows inputs and disk to prefill the pipeline.
When starting to roll, the session counts down a global "remaning preroll"
counter, which is the worst-latency from in-to-out.
Each route in turn will start processing at its own output-latency.
Route::process_output_buffers() - which does the actual processing
incl disk i/o - begins by offsetting the "current sample" by the
route's process-latency and decrements the offset for each latent
processor. At the end of the function the output will be aligned
and match transport-sample - downstream-playback-latency (if any).
PS. This commit is a first step only: transport looping & vari-speed have
not yet been implemented/updated.
If disk-monitoring is disabled: disk-reader position is not relevant.
If Rec-arm is off: disk-writer position is not relevant.
But...
Play -> [plugins] -> Record
is basically a bounce and best done using the bounce operation.
(faster than realtime).
Input + Play -> Record -> Output
Ardour would need to align playback with the Input to be recorded
and at the same time align it with output, so that a player can play
along on the same track. That's not possible without a time-machine (or
a 2nd play processor).
While it can work in theory under some special circumstances, allowing
the disk-reader before the disk-writer is really just confusing,
error prone and valid uses cases are better handled by dedicated
operations.
We want Track to shrink, and logic consolidation is always good. Route already knew about
disk_reader and disk_writer, now it knows about _monitoring_control too
* centralize signal_latency_at_***_position to processors
* update initial-delay/roll-delay when processor order changes
* consolidate signal-latency calculation: use the same method
for processor-changes and session's post_playback_latency.
* include relative output-delay in roll-delay
* fix capture processor position & optimize stem-export latency
(roll-delay fixes pending Route:roll() update)
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
Robin Gareus
Len Ovens
Paul Davis
Ben Loftis
Nikolaus Gullotta
Johannes Mueller
John Emmas