| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
|
|
|
|
|
|
Auditioner seek calls are explicitly handled by the butler,
and DR:overwrite_existing_buffers() is called explicitly
to read MIDI data for audition.
Session::non_realtime_overwrite is no longer required.
This reverts commit 6fbcf837793ec9a8347fd2d12823b9e56587ffc0
and parts of 2d11667ce3d2ada93c0fb90978bdcc054413c2bb.
|
|
The Auditioner is not part of the session route-list and the
auditioner route's I/O latency is never updated.
Session::process_audition() does not handle pre-roll either,
so it need to be zeroed, otherwise Route::roll skips samples.
This has lead to initial samples being skipped, IFF the
auditioner's output-port had non-zero latency.
Since private port-latencies are usually only set for routes
in the route-list, and _remaining_latency_preroll is reset
at transport-stop, this *usually* worked...
Last but not least, MIDI notes need to be resolved when seeking.
|
|
This fixes a bug introduce in 2d11667ce3. The Auditoner
was accidentally added to the shared_ptr<> referenced RouteList.
|
|
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.
|
|
|
|
xmlParseMemory() uses a c-pointer char*.
Previously MIDNAM data on the heap were wrapped inside
a std::string only to be later accessed via c_str().
|
