Age | Commit message (Collapse) | Author |
|
|
|
This is done in order to set the TransportGenerator flag
|
|
Generator ports (like TransportMaster slaves), should not be
re-sampled when vari-speeding. Instead the Timecode/Clock should
directly use the engine-speed.
For this to happen, they need to be special-cased: no re-sampler
latency, direct access to engine-buffers.
|
|
Since 4508d5bab this only happened after a fade-out.
Currently there is no fade when transport is stopped and monitor
mode changes MonitoringDisk <-> MonitoringInput.
DiskReader::DeclickAmp is only used for data from disk.
Fading live-input data passing through will likely need another
Amp.
|
|
PortManager::cycle_start() excludes these ports from being
resampled. They're directly handled by the TSM, outside of
the session.
|
|
|
|
|
|
This went away when we added RTMidiBuffer. Getting data from MIDI playlists is now
completed in one pass, without note trackers
|
|
We need a MidiStateTracker to determine notes whose end is not reached
during the call to ::write_one_track(), so that we can resolve them
in the output (SMF) source. This required some changes to the ::export_stuff()
API for tracks.
In addition, we now take the source "lock" just once during ::write_one_track()
rather than every time we write. This isn't an integral part of the
note tracking, but fell out along the way.
Finally, note that although we use a vector to handle MIDI "sources" here,
it is expected that there is only 1 MIDI source at present. Leave vectors in
place since it is possible that ::write_one_track() could be modified
in the future to change that.
|
|
|
|
|
|
|
|
|
|
Previously use-monitor-fades was unused in A6, and transition
between monitoring states used the use-transport-fades preference.
|
|
Previously it was possible that
* declick_out = true,
* target_gain == 0, cur_gain != 0 (fade out active)
* speed != 0, disk_samples_to_consume > 0.
So the disk-reader advanced the playback_sample, but since
declick_out is active, the read from the ringbuffer was not committed.
|
|
|
|
|
|
|
|
When export is done, nothing a MIDI-only track will reduce the gain ("goto midi" inside
DiskReader::run() and the "declick-in-progress" state will be permanent
|
|
|
|
|
|
|
|
This was just a proxy for libs/evoral/evoral/Event.h. Note that the #define
that controlled allocation that was at the top of the removed header is
replicated in the Evoral header, so there are no semantic changes
|
|
|
|
|
|
|
|
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].
|
|
that MTC events "occured at"
|
|
|
|
Session::update_latency() may be called multiple times with
the process-lock being held.
|
|
|
|
|
|
jack2 can process in parallel with calling a graph-order or
latency-callback, so Ardour takes a lock to update those in sync.
Yet jack2 can also block while port-registrations happen,
and concurrently emit latency-callback from another thread..
|
|
|
|
Port and connection changes always imply a latency_callback from
the engine. Worst I/O latency is updated directly in
Session::update_latency() which is called from
AudioEngine::latency_callback.
Explicit subscriptions to route->output()->changed() is not needed
to update the worst I/O latency.
Only set_block_size() needs to to update the I/O latency when
the buffer-size changes.
|
|
-DLatency now triggers all four:
* LatencyCompensation (entry-points, overall flow)
* LatencyIO (Port/IO query, set/get private/public)
* LatencyDelayLine (Delaylines for internal sends and alignment)
* LatencyRoute (route processor latency)
|
|
The backend may call update_latency() while at the same time
the auto-connect-port calls set_worst_io_latencies().
The latter already holds the process-lock, so update_latency()
first needs to acquire it, as well. If one already holds the
_update_latency_lock, one must not ask for the process-lock.
---
Previously Ardour's connection manager first took the process_lock
and then waited to the _update_latency_lock.
Meanwhile jack calls latency_callback(), takes the
_update_latency_lock and waits for the process_lock.
Classic deadlock.
|
|
|
|
LV2 plugins may add a MIDNAM file when they're loaded.
This can be happen concurrently with the MidiPatchManager,
loading the system-wide patch files.
Session load should not be interrupted by the initial
background scan of patch files, which can take a very long time.
We need to allow update_custom_midnam() to grab the _lock.
|
|
|
|
|
|
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.
|
|
This allows to also catch cases when a panner-ui directly changes
set_linked_to_route() of the panner shell.
|
|
external sync if command is allowed
The semantics are that if the user configures things to allow transport commands while
using a transport master, issuing such commands first stops using the master
|
|
|
|
for ltc slave
|
|
left in place
|
|
|
|
|
|
|