manual/_manual/22_preferences-and-session-properties/01_preferences-dialog/02_transport.html

178 lines
5.7 KiB
HTML

---
layout: default
title: Transport Tab
menu_title: Transport Tab
---
<p>
This tab contains settings that relate to the behavior of the
<a href="/controlling-playback/using-the-transport-bar/">Transport Bar</a>
and <a href="/synchronization/">Synchronization</a>.
</p>
<img src="/images/a4_preferences_transport.png" alt="preferences
transport tab"/>
<ul>
<li>
<p>
<strong>Keep record-enable engaged on stop</strong> leaves the global
record-enable engaged after transport is stopped. Does not affect track
level record-enable which is never changed on stop.
</p>
</li>
<li>
<p>
<strong>Play loop is a transport mode</strong> changes the behavior of the
loop button, turning it into a toggle. When enabled, the loop button does
not start playback but forces playback to always play the loop. Looping
stays engaged when the transport is stopped. Playback continues where the
transport stopped and continues to loop.
</p>
<p>
When disabled, the loop button starts playing the loop but stop then
cancels loop playback.
</p>
</li>
<li>
<p>
<strong>Stop recording when an xrun occurs</strong> will stop the transport
when an xrun occurs during recording, ensuring no audible glitches are
recorded.
</p>
</li>
<li>
<p>
<strong>Create markers where xruns occur</strong> will create a new
<a href="/working-with-markers/">marker</a> when an xrun occurs during
recording at the location of the xrun. This marks where possible xruns
might produce audible glitches when stopping on xruns is disabled.
</p>
</li>
<li>
<p>
<strong>Stop at the end of the session</strong> causes the transport to
stop during playback when it reaches the end marker. Behavior during
recording is not changed.
</p>
</li>
<li>
<p>
<strong>Do seamless looping</strong> removes any clicks that might
otherwise be audible when the transport moves from the end of the loop
range back to the beginning.
</p>
</li>
<li>
<p>
<strong>Disable per-track record disarm while rolling</strong>, when
enabled, will not allow the any track's record-enable to be disarmed
during record, preventing accidentally stopping the recording of a take.
</p>
</li>
<li>
<p>
<strong>12dB gain reduction during fast-forward and fast-rewind</strong>
when enabled will reduce the unpleasant increase in perceived volume
that occurs when fast-forwarding or rewinding through some kinds of audio.
</p>
</li>
<li>
<p>
<strong>Sync/Slave</strong>
<ul>
<li>
<p>
<strong>External timecode source</strong> determines which external
source to use when Ardour is using an external
<a href="/synchronization/">synchronization</a> source. Depending
on the timecode source chosen, additional preference options are
available.
</p>
</li>
<li>
<p>
<strong>Match session video frame rate to external timecode</strong>
controls the value of the video frame rate <em>while chasing</em>
an external timecode source.
</p>
<p>
When enabled, the session video frame rate will be changed to match
that of the selected external timecode source.
</p>
<p>
When disabled, the session video frame rate will not be changed to
match that of the selected external timecode source. Instead, the
frame rate indication in the main clock will flash red and Ardour
will convert between the external timecode standard and the session
standard.
</p>
</li>
<li>
<p>
<strong>Sync-lock timecode to clock</strong> can disable drift
compensation.
</p>
<p>
When enabled, Ardour will never varispeed when slaved to external
timecode. Sync Lock indicates that the selected external timecode
source shares clock-sync (Black &amp; Burst, Wordclock, etc) with
the audio interface. This options disables drift compensation.
The transport speed is fixed at 1.0. Vari-speed LTC will be ignored
and cause drift.
</p>
<p>
When disabled, Ardour will compensate for potential drift regardless
if the timecode sources shares clock sync.
</p>
</li>
<li>
<p>
<strong>Lock to 29.9700 fps instead of 30000/1001</strong>, when
enabled, will force Ardour to assume the external timecode source
uses 29.97 fps instead of 30000/1001.
SMPTE 12M-1999 specifies 29.97&nbsp;df as 30000/1001. The spec
further mentions that drop-frame timecode has an accumulated error
of -86&nbsp;ms over a 24&nbsp;hour period. Drop-frame timecode would
compensate exactly for an NTSC color frame rate of 30 * 0.9990 (i.e.
29.970000). That is not the actual rate. However, some vendors use
that rate - despite it being against the specs - because the
variant of using exactly 29.97&nbsp;fps has zero timecode drift.
</p>
</ul>
</p>
</li>
<li>
<p>
<strong>LTC Reader</strong> specifies which incoming port will provide
the LTC signal.
</p>
</li>
<li>
<strong>LTC Generator</strong>
<ul>
<li>
<p>
<strong>Enable LTC generator</strong>, when enabled Ardour will
output an LTC timecode signal on it's <em>LTC-out</em> port.
</p>
</li>
<li>
<p>
<strong>Send LTC while stopped</strong>, when enabled Ardour will
continue to send LTC information even while the transport (playhed) is
not moving.
</p>
</li>
<li>
<p>
<strong>LTC generator level:</strong> specifies the peak volume of
the generated LTC signal in dbFS. A good value is 0dBu^=-18dbFS in an
EBU calibrated system.
</p>
</li>
</ul>
</li>
</ul>