When a button has a fixed size, there's no need to call queue_resize().
This fixes an issue with the ArdourClock info displays when slaved.
The Timecode and Delta display text changes in small intervals and
caused excessive CPU load due to GUI size-requests + redraws.
* use left-aligned sign symbol with "sample" unit.
When the delta value jitters in decimal places (e.g. MTC)
it's otherwise no possible to discern + vs -.
* Use white text by default (not green)
An engine restart sends dis-connect messages for the reverse
port-mapping (after making the connection):
Connect: system:midi_capture_41a56f90 -> ardour:MTC in
Connect: system:capture_1 -> ardour:LTC in
DisConnect: ardour:MTC in -> system:midi_capture_41a56f90
DisConnect: ardour:LTC in -> system:capture_1
This lead to TransportMaster being marked as inactive.
This is likely an issue that should be fixed elsewhere, but in
case of JACK, we likely do not have control over this.
Offset the detected timecode instead of the detection time.
The latter is used by the DLL and later also used to calculate
delta times which lead to a constant offset.
TransportMasterStart needs to be set when this cycle's delta
can reach _remaining_latency_preroll.
This allows to directly catch the master-position and start
rolling without initial vari-speed.
This mechanism adds infrastructure that can later also be used
for MTC and MIDIClock.
PS. The LTC Generator port's latency is queried after the port
is created, and later kept in sync via LatencyUpdated signal.
This uses a recently introduce Signal instead of the generic
GraphReordered, which was used in the past since it usually
happened after the latency was changed.
* Do not allow new send to change implicit solo (no propagation)
* Propagate changes to due aux-send removal upstream
to tracks or busses connected to the source route.
* Forward solo-isolate
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.
When rolling forward the LTC generator needs to send future
a timestamp, so that when it matches the current time when
the signal arrives at the output port.
(A6 aligns transport playhead to output)
Also remove redundant double call to Track::set_block_size(). This dates back to 2010
when there used be an additional traversal of the Diskstream RCU-managed list, before
they became owned by Tracks
In case of JACK all ports not owned by Ardour may be re-sampled,
and latency is added. External JACK ports need to be treated
like physical ports: I/O latency needs to be taken into account.
When not using JACK, all external ports are physical ports
so this is a NO-OP for other backends.
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.
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 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.
Actions for hide/show/attach/detach tabbables use hard-coded names which are not
translated. Using Tabbable/WindowProxy::name() to lookup the action will fail,
since the name can be translated. This changes just removes the option to not
provide a menu-name when creating these objects, and uses the name menu-name
when looking up an action by name
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 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].
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.
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.
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
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 6fbcf83779
and parts of 2d11667ce3.
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.
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.
DiskReader::seek() no longer fills MIDI buffers.
MIDI is now read into memory via DR:overwrite_existing_buffers()
There is still some edge-case remaining to be fixed. For
some reasons the synth does not receive initial patch/program
changes when starting auditioning.
update_custom_midnam() is usually called from the GUI or butler
thread when a LV2 plugin is instantiated, or the plugin changes
its MIDNAM. It must be exclusive with load_midnams_in_thread()
and calls from MTAV to ::maybe_use().
- add missing translations
- largely follow original message regarding punctuation, capitalization
at the beginning of sentences, trailing white space
- fix typos and other obvious mistakes
Signed-off-by: Nils Philippsen <nils@tiptoe.de>
This fixes Virtual-keyboard velocity selection when scrolling
to numbers that are not explicitly in the menu-list.
(hopefully this does not introduce some recursive signals
for other ArdourDropdowns, fingers crossed).
Since 57118c2370, plugins are re-activated after every export.
So a silent pre no-roll is mainly useful for with realtime export,
and for some cases where a plugin does not correctly reset.
Note that for the first export, plugins are not currently flushed.
