Age | Commit message (Collapse) | Author |
|
|
|
|
|
The delay-time itself can change arbitrarily, but the buffer-size
never shrinks.
If the buffersize grows it means that the new delay is longer than
the current one (or at least as large as any pending, not yet
active delay).
This is important for the mechanism that adjusts the read-pointer
to the new buffer-size.
|
|
Previously buffers were dropped, and data was not copied to
newly allocated buffers. As side-effect the read-offset was not
adjusted either.
The distance between read and write-pointer needs to be maintained
(delay does not change). This needs to be accounted for, when the
buffer increases while read->write wraps around the old (smaller)
buffer. Previously this triggered an assert (in line 180)
|
|
|
|
|
|
|
|
|
|
|
|
Also don't automatically flush the delayline at transport or monitor-
changes anymore.
With full-graph latency compensation, delaylines are before the
disk-reader, aligning input (disk uses read-ahead to align).
Flushing the delayline should only happen when input-monitoring
is disengaged. It's best degated to the Route or object using the
Delayline (potentially latency-aligned delayed flush).
|
|
This also tweaks fade behavior when the latency changes to prefer a
x-fade when possible.
This new variant does not support concurrent re-allocation and
execution. Hence the auto-connect thread needs to take a lock before
updating latencies (actually there's no need for an explicit update with
built-in backends, so this case remains to be updated further)
|
|
* Processor implement get_state(), classes derived from Processor
implement protected ::state() -- as documented in processor.h
* likewise for Route, Track: make ::state() a protected interface
* removal of "full_state", use explicit "template_save"
* use RAII/Unwind to skip saving automation-state
|
|
|
|
|
|
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
|
|
|
|
|
|
It is slightly questionable whether type specific methods like
velocity() belong on Event at all, these may be better off as free
functions. However the code currently uses them as methods in many
places, and it seems like a step in the right direction, since, for
example, we might some day have events that have a velocity but aren't
stored as MIDI messages (e.g. if Ardour uses an internal musical model
that is more expressive).
In any case, the former inheritance and plethora of sloppy casts is
definitely not the right thing.
|
|
Pass current (latency compensated) cycle times to plugin.
This fixes time-reporting to plugins and also fixes automation
and when bouncing (the session->transport* is not valid) etc.
|
|
|
|
|
|
|
|
|