| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The disk-reader assumes that all playback ringbuffers are in sync
and have the same fill_level.
|
|
|
|
|
|
|
|
|
|
Amend 648beb94. If initial re-fill happens via override buffers,
the buffer may still be effectively empty.
|
|
Port (or Tracks) can be safely added during playback, however
the disk-reader's playback buffer is initially empty. This lead to
false-positive Underrun() signals when processing takes place
before or concurrently with re-filling the disk-buffer for the new
channels.
Now new empty buffers are ignored, and produce silence until the
initial refill is complete. There is however no per-channel
de-click in, yet.
This fixes: play some audio track, ctrl+drag a region to the
drop-zone, creating a new track while playing.
|
|
|
|
|
|
|
|
|
|
This reworking avoids some confusion caused by the use boost::optional here
|
|
|
|
|
|
|
|
misleading/confusing)
|
|
This is intended to be a no-op that makes the code easier to read/reason about
|
|
position in a DiskReader, pay attention to loop status
If the last read was not looped, but the new one should be, we need to ignore the heuristic. Ditto for vice-versa.
This isomorphic with the read-reversed case
|
|
Bug was introduced in 128a45954cf, declick-amp gain was
overridden, but declick not cleared. For some reason this did
not affect audio-only exports nor all session exports.
|
|
|
|
canonical
We told the DR to read from pos+shift, and it increment file_sample[T] appropriately. We should not adjust it. The
only thing that gets adjusted is the sample that will playback (as a result of PlaybackBuffer::increment_read_ptr()
|
|
"shift" offset
There is still a bug related to "shift" that causes a playback discontinuity
|
|
|
|
some reverse internal seek allowance
|
|
enough (read direction must match)
|
|
|
|
was done last time we read from disk
|
|
|
|
|
|
This reverts commit b2bc934e218a8ed05b6f37edc5585191e60ca288.
The commit does causes issues when a user manually removes channels:
The disk-reader's ::can_support_io_configuration() at first ignores
the user's request, forcing the output channel count to match the
DR's current channel config.
However, when configuring the DiskReader after that, channels is updated
to match the new input-count.
Even though the DR itself only plays back using the confgured I/O,
all processors after it still use the old channel count.
Only a later, second re-configuration step will apply the actual removal
to plugins and port.
PS. the original commit was mainly intended to fix a crash when
adding an instrument plugin *between* disk-writer and disk-reader
on a MIDI track.
|
|
DiskReader::refill_audio and DR::run() do check if a given playlist
is available. This is required for upcoming changes to set
DR channels to unconditionally match DiskWriter.
|
|
|
|
This fixes the following (loop-lennth > internal_playback_seek
length. Due to read-ahead on some cycles the following can happen
---
Loop From: 3528000 To: 3880800 (len: 352800)
start-sample: 3880971 playback_sample: 3528171 nframes: 96
start-sample: 3880875 playback_sample: 3528075 nframes: 192
---
which resulted in disk_samples_to_consume == 0;
|
|
Exponential approach to zero:
1 / exp(t) == exp (-t)
we "stretch" it by a time-constant "c":
gain(t) = exp (-t * c)
To find the time t, at which the exponential approach reaches gain "g":
exp (-c * t) = g
take the log of both sides: log (exp (-c * t) = log (g)
since log (exp (x)) == x : -c t = log (g)
divide by -c : t = -log (g) / c
set g = 1e-5 and c = _a/sr and we get: t = -log (1e-5) / (_a/sr)
The iterative approach using g += c * (target_gain - g);
converges faster than the exact exp() calculation.
Except with 32-bit float, if target-gain is 1.0f and "c" is small.
With 32bit float (1.0 - 1e-5) = .9999900 is represented as
sign: +1 | mantissa: 0x7fff58 | exponent: 126
there are only 126 "steps" to 1.0. Rounding of the lowest
mantissa bit does matter. We have to assume worst-case,
and increase the required loop_fade_length buffersize.
vs. approaching 0, where there are over 2^110 steps between
zero and 1e-5.
|
|
|
|
|
|
DiskReader::declick_in_progress()
If use_transport_fades() is false, then the declick_amp will have its gain always set to the current target (no declick).
Therefore only testing if it has reached zero is not enough, we need to check if we are declicking at all.
|
|
|
|
If we're within 1/6th of the size of the reserved buffer of the target sample, no need to refill
|
|
|
|
"roll-after-locate"
This allows callers to defer logic about auto-play/current rolling state and more to TransportFSM where it
can be cnentralized and is less ambiguous
|
|
|
|
|
|
|
|
|
|
|
|
Several math/geometry errors here
|
|
|
|
|
