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.
|
|
|
|
This should fix excessive latency with the RayDay that
has a fixed buffersize of 16384 samples.
|
|
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 helpful when debugging by PID (adevices.sh most notably),
just "gui" is not usually helpful.
|
|
|
|
|
|
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 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"
|
|
|
|
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..
|