| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This is mainly for RME RayDAT that has a fixed buffersize of 16k:
dev_name : hw:HDSPMxc2f6c5,0
channels : 36
min_rate : 32000
max_rate : 192000
min_bufz : 16384
max_bufz : 16384
min_nper : 4
max_nper : 512
However nperiod configuration determines the effective latency
regardless.
This is similar to https://github.com/jackaudio/jack1/blob/master/drivers/alsa/alsa_driver.c#L476-L486
|
|
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 is useful when when the ardour-lua is started by a
command based wrapper that cannot poll the engine state.
|
|
|
|
|
|
|
|
|
|
|
|
This partially reverts 990afec2e
|
|
|
|
|
|
|
|
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
|
|
calls to ::set_colors()
|
|
This call also happens before colors are even defined
|
|
From Ardour5 to Ardour6 the AccessAction handle changes
from "Editor/script-action-<N>" to "LuaAction/script-<N>"
|
|
|
|
|
|
This will still need an update for Alsa_pcmi::set_hwpar() capture
channel (which is fixed at 2, unless FRAG_NEAR is used).
|
|
|
|
|
|
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"
|
|
This reverts commit 81cbf36c5693a6b1c70a29871bb2e0df5f83070b.
Limiting scrolling has other drawbacks. A proper fix for the redraw issue
has to be found.
|
|
The issue remains if a track is selected by a "fit-selection" action second
last track covers the whole trackview. Then when scrolling one track up, the
huge track disappears and a smaller track follows, that covers a lot less
space.
-> Proper redraw of the track view is still needed.
|
|
|
|
Session::update_latency() may be called multiple times with
the process-lock being held.
|
|
|
|
This file is not referenced by any bundle script nor wscript
install directives. Perhaps it's not needed?
|
|
|
|
|
|
usable with MIDI CC control
The old code meant that their current value was always zero, and that they would do nothing unless
the new value exceeded 0.5
|
|
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.
|
|
The typos in the original English were reported by Edgar
Aichinger while working on the German translation.
|
|
|
|
Previously, `dist` had to be the first argument to waf. If it came in a
different position (e.g. `APPNAME=Ardour ./waf tarball dist`) or
`distcheck` was used instead of `dist`, the resulting archive was named
`noname-....tar.bz2`.
Signed-off-by: Nils Philippsen <nils@tiptoe.de>
|
|
|
|
|
|
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.
|
|
When editing a sends, this allows to unlink send panner via
the panner's context menu.
NB. After 6.0-rc string freeze the context menu needs an update.
So far the text from the Processor Box context menu is reused.
|
|
This allows to also catch cases when a panner-ui directly changes
set_linked_to_route() of the panner shell.
|
