* prevent duplicate names when pulling-in external sources
* drop "origin" after including external sources
* don't include unused playlists
(they may reference sources that are not included)
* likewise exclude unused regions
* 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
- Fix API call to add region(midi_region) -- set count to "1"
- Forward DataRecorded() signal
- remove botched merge/rebase"
a4a87f56 accidentally brought back code from old-destructive API
which was removed in af103cf3 and 08c13007
There is no per track NonLayered record mode anymore, it's session global.
- set can_record correctly to not accidentally clear last capture sources
for cont'd recording (toggle track's rec-arm)
* use start/end frame
* differentiate nframes and disk_samples_to_consume
* add global Port::port_offset () when writing data.
* add a note about b0rked vari-speed ..
Immediate events are used for MIDI-Panic and to inject GUI generated
events e.g. patch-changes, note-events from the track-header
(scroomer-keyboard) and patch-change audition.
Current behavior:
- snapshot copy immediate events from ringbuffer into a buffer at
the beginning of each the cycle.
- Inject immediate events into input-buffer directly after reading the input
- process "normally"
- pass immediate event-buffer to disk-writer, so it can skip them
(don't write immediate events to disk)
- if the Route is not monitoring input: clear buffer before disk-reader
and re-inject (original) immediate events after the disk-reader
- immediate events process normally and are also sent to outputs.
This moves common code (get and fill buffers) into ::passthru()
and renames ::passthru() to ::run_route().
passthru_silence() is no longer used (it was only needed A5 style
Track::no_roll_unlocked for no-roll + disk-monitoring)
Currently ::roll() may actually be a ::no_roll() under some circumstances.
This can also happen during count-in:
transport_stopped () == transport_rolling()
and during latency-preroll:
Global session-transport speed != 0, some tracks already roll,
read data from disk and feed latent plugins.
but other non-latent tracks or busses don't roll and still have to
behave like the switch from no_roll() to roll() has not yet happened.
This changes the game WRT to monitoring as well, previously, Route:roll()
called Route::no_roll_unlocked () for conditions outlined above.
Now Track::no_roll_unlocked is called and in some cases wrongly clears
the buffers before the signal hits the disk-writer. (more work is needed
related to 61f8e53b)
On the upside this also fixes an issue with MidiTrack::no_roll not keeping
a lock while pushing data into the step-edit-ringbuffer.
This is also a step towards consolidating all entry points:
::roll(), ::no_roll(), ::silent_roll() in the Route class.
Individual Routes cannot split the process-cycle in no_roll(); roll()
by themselves. Each of the calls will flush output buffers (and offset
port-buffers). If a route feeds another route the inputs of the other
route will only see partial data.
AudioPort::get_audio_buffer() can offset the buffer simply by offsetting
a pointer. This allows to get an offset buffer for a given port.
For MIDI there's no such concept. A method writing to a MIDI buffer
which is backed by a Port can at best offset it by the global port-buffer
offset (static Port::port_offset), but not by the individual target port's
offset.
This allows to push latency upstream and delay the source
in case the destination has a longer latency.
Also add a signal to notify the Session in case this happens, intended
to queue a latency-recompute.
The general goal is to align transport-sample to be the audible frame
and use that as "anchor" for all processing.
transport_sample cannot become negative (00:00:00:00 is the first audible
frame).
Internally transport pre-rolls (read-ahead) before the transport starts
to move. This allows inputs and disk to prefill the pipeline.
When starting to roll, the session counts down a global "remaning preroll"
counter, which is the worst-latency from in-to-out.
Each route in turn will start processing at its own output-latency.
Route::process_output_buffers() - which does the actual processing
incl disk i/o - begins by offsetting the "current sample" by the
route's process-latency and decrements the offset for each latent
processor. At the end of the function the output will be aligned
and match transport-sample - downstream-playback-latency (if any).
PS. This commit is a first step only: transport looping & vari-speed have
not yet been implemented/updated.
This is mostly to see if there'll be any problems when merging these changes into Mixbus. I'm guessing there'll be some conflicts in these projects (and a lot more to follow...)
After over 17 years of honorable service to the Ardour Codebase.
ClickBox and AutoSpin are retiring into the git nirvana.
We're glad for the duty, decency, reliability, dignity, respect which
these classes brought to Arodur and look back in gratitude on their years
of service.
PS. First one to say "cruft" will be fired.
Currently, the scroll handler obeys to the page increment, but instead
of using the step increment for more precise scroll, it uses an
hardcoded one tenth of the page increment.
Use the step increment instead since it has been filled with sensible
values by ArdourFader's users.
Set accumulated capture-latency for physical-outputs
and accumulated playback-latency for physical-inputs
after Ardour is done setting all non-physical port latencies.
This will be needed for latency-compensation of the complete graph.
Session::post_playback_latency() sets the actual route latency,
so that playback latency notifications need to come after capture-
latency (backends follow the same rule: capture first).
NB. Session::initialize_latencies() was already using the correct order
If disk-monitoring is disabled: disk-reader position is not relevant.
If Rec-arm is off: disk-writer position is not relevant.
But...
Play -> [plugins] -> Record
is basically a bounce and best done using the bounce operation.
(faster than realtime).
Input + Play -> Record -> Output
Ardour would need to align playback with the Input to be recorded
and at the same time align it with output, so that a player can play
along on the same track. That's not possible without a time-machine (or
a 2nd play processor).
While it can work in theory under some special circumstances, allowing
the disk-reader before the disk-writer is really just confusing,
error prone and valid uses cases are better handled by dedicated
operations.
"i18n.h" needs to be included last, after types have been defined or
clang bails out:
"call to function 'operator<<' is not visible in the template definition"
Once a session has been saved by a more recent version or a different
variant, the session file is tied to that version/variant.
The created-with version is only for debug purposes and internal use.
We want Track to shrink, and logic consolidation is always good. Route already knew about
disk_reader and disk_writer, now it knows about _monitoring_control too
* centralize signal_latency_at_***_position to processors
* update initial-delay/roll-delay when processor order changes
* consolidate signal-latency calculation: use the same method
for processor-changes and session's post_playback_latency.
* include relative output-delay in roll-delay
* fix capture processor position & optimize stem-export latency
(roll-delay fixes pending Route:roll() update)
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
While the pads work, overall integration is still not present, mainly
because the device does not lend itself for editing & mixing in a
DAW environment.
hand-adapted version of d977cc3238 from master
This does not merge MIDI data, but trims MIDI regions at rec-stop like
non-layered audio-recording does.
We're interested in average distance between slave/master, the direction is irrelevant and
using sign as direction causes the computed average to be absurd
