More spelling, grammar & style fixes
it's --> it is/its as appropriate loose --> lose were --> where remove excess hyphens
This commit is contained in:
parent
a2b5aa75b9
commit
042723be89
@ -272,7 +272,7 @@
|
||||
<p class="note">
|
||||
Notice that if any gain automation has been set and the
|
||||
automation state is set on "Play" (see below), then the Gain fader is driven by
|
||||
the automation, and not by the user. The Gain fader will turn grey to show it's
|
||||
the automation, and not by the user. The Gain fader will turn grey to show it is
|
||||
inactive.
|
||||
</p>
|
||||
|
||||
|
@ -81,7 +81,7 @@
|
||||
<p>
|
||||
Encoding the audio sources to <abbr title="Free Lossless Audio Codec">FLAC</abbr> allows for a good size reduction of the session.
|
||||
It should be noted though that FLAC is a fixed-point format, meaning that if the
|
||||
audio in the session is in a floating-point format, this conversion will loose
|
||||
audio in the session is in a floating-point format, this conversion will lose
|
||||
some information on the samples values that are rounded, though usually, this
|
||||
lost information cannot be perceived. Choosing "<em>None</em>" for Audio
|
||||
Compression does not compress the audio to FLAC, hence preserving the floating-point
|
||||
|
@ -192,7 +192,7 @@ The surface can be broken into 8 groups of controls:
|
||||
<td>
|
||||
In send mode, the encoders control sends from left to right instead of mixer pans.
|
||||
If there are less than 8 sends the behavior of the encoder will be to continue controlling
|
||||
the mixer pan. Visually it's indicated by the change in the LED from originating at the 12
|
||||
the mixer pan. Visually it is indicated by the change in the LED from originating at the 12
|
||||
o'clock position to originating at the 7 o'clock position. If <kbd class="button">FLIP</kbd> is pressed
|
||||
the encoder will control the mixer gain for the selected track/bus.
|
||||
</td></tr>
|
||||
|
@ -16,7 +16,7 @@ gui tab"/>
|
||||
<li>
|
||||
<p>
|
||||
<strong>Use name highlight bars in region display</strong> When enabled the
|
||||
region name is displayed, in the editor, in it's own bar at the bottom of
|
||||
region name is displayed, in the editor, in its own bar at the bottom of
|
||||
the region. When disabled, the region name is display at the top of the
|
||||
region, possibly over audio waveforms or MIDI notes.
|
||||
</p>
|
||||
|
@ -83,7 +83,7 @@
|
||||
Low latency is <strong>not</strong> always a feature you want to have. It
|
||||
comes with a couple of drawbacks: the most prominent is increased power
|
||||
consumption because the CPU needs to process many small chunks of audio data,
|
||||
it is constantly active and can not enter power-saving mode (think fan-noise).
|
||||
it is constantly active and can not enter power-saving mode (think fan noise).
|
||||
Since each application that is part of the signal chain must run in every
|
||||
audio cycle, low-latency systems will undergo<dfn>context switches</dfn>
|
||||
between applications more often, which incur a significant overhead.
|
||||
@ -95,7 +95,7 @@
|
||||
<h3>Playing virtual instruments</h3>
|
||||
<p>
|
||||
A large delay between the pressing of the keys and the sound the instrument
|
||||
produces will throw-off the timing of most instrumentalists (save church
|
||||
produces will throw off the timing of most instrumentalists (save church
|
||||
organists, whom we believe to be awesome latency-compensation organic systems.)
|
||||
</p>
|
||||
<h3>Software audio monitoring</h3>
|
||||
@ -132,19 +132,19 @@
|
||||
played back is internally aligned with the sound that is being recorded.
|
||||
</p>
|
||||
<p>
|
||||
This is where latency-compensation comes into play. There are two ways to
|
||||
This is where latency compensation comes into play. There are two ways to
|
||||
compensate for latency in a DAW, <dfn>read-ahead</dfn> and
|
||||
<dfn>write-behind</dfn>. The DAW starts playing a bit early (relative to
|
||||
the playhead), so that when the sound arrives at the speakers a short time
|
||||
later, it is exactly aligned with the material that is being recorded.
|
||||
Since we know that play-back has latency, the incoming audio can be delayed
|
||||
Since we know that playback has latency, the incoming audio can be delayed
|
||||
by the same amount to line things up again.
|
||||
</p>
|
||||
<p>
|
||||
As you may see, the second approach is prone to various implementation
|
||||
issues regarding timecode and transport synchronization. Ardour uses read-ahead
|
||||
to compensate for latency. The time displayed in the Ardour clock corresponds
|
||||
to the audio-signal that you hear on the speakers (and is not where Ardour
|
||||
to the audio signal that you hear on the speakers (and is not where Ardour
|
||||
reads files from disk).
|
||||
</p>
|
||||
<p>
|
||||
|
@ -1,6 +1,6 @@
|
||||
|
||||
<p>
|
||||
Ardour has automation modes for many of it's controls. As of version
|
||||
Ardour has automation modes for many of its controls. As of version
|
||||
5.9, OSC can control what automation mode a fader uses.
|
||||
(<a href="@@automation">See Automation.</a>)
|
||||
</p>
|
||||
|
@ -53,9 +53,9 @@ here</em>"/></kbd>
|
||||
<h2>Control Surface Set Up</h2>
|
||||
|
||||
<p>
|
||||
Control surface set up allows the controller to tell Ardour about it's
|
||||
Control surface set up allows the controller to tell Ardour about its
|
||||
capabilities. The surface can tell Ardour how many control strips it
|
||||
has for banking, if it is capable of setting it's faders or buttons
|
||||
has for banking, if it is capable of setting its faders or buttons
|
||||
to values set by Ardour's GUI or automation, What kind of math the
|
||||
faders use and more.
|
||||
</p>
|
||||
@ -600,7 +600,7 @@ Any of these actions that can be moved to session->action calls may reapear.
|
||||
<tr><th><kbd class="osc">/quick_snapshot_stay</kbd></th>
|
||||
<td>Take a snapshot and keep working on this version</td></tr>
|
||||
<tr><th><kbd class="osc">/fit_*_track(s)</kbd></th>
|
||||
<td>Were <em>*</em> is one of 1, 2, 4, 8, 16, 32 or all. Fits this
|
||||
<td>Where <em>*</em> is one of 1, 2, 4, 8, 16, 32 or all. Fits this
|
||||
many tracks in editor window. (add s for more than 1)</td></tr>
|
||||
<tr><th><kbd class="osc">/zoom_*</kbd></th>
|
||||
<td>Zoom editor to include <em>*</em> where <em>*</em> is 100_ms, 1_sec,
|
||||
|
@ -85,7 +85,7 @@
|
||||
There are busses that can be used a number of ways. From analog days,
|
||||
in OSC, a bus is something that gets used as a sub mix before ending up
|
||||
going to Master. An auxiliary bus is used like a separate mixer and
|
||||
it's output goes outside the program or computer to be used as:
|
||||
its output goes outside the program or computer to be used as:
|
||||
a monitor mix, a back up recording, or what have you. In OSC where
|
||||
controller strips may be limited, it may be useful not to use up a
|
||||
strip for an aux that is not really a part of the mix. It is also
|
||||
|
@ -11,7 +11,7 @@
|
||||
<p>
|
||||
Ardour does feedback by sending the same path back that is used to
|
||||
control the same function. As such any controls that have feedback
|
||||
have a parameter that is the value of the control or it's state
|
||||
have a parameter that is the value of the control or its state
|
||||
(on or off). In the case of OSC paths listed on the main OSC page
|
||||
as having no parameter, if they have feedback, they will also work
|
||||
with a 1 for button press and 0 for button release. This is because
|
||||
|
@ -18,8 +18,8 @@
|
||||
<li>
|
||||
Connect the output of that bus to one of the audio
|
||||
interface's playback ports that is not otherwise used. OSC
|
||||
will now include this bus in it's list of aux busses as it
|
||||
no longer has it's output connected to the Master bus.
|
||||
will now include this bus in its list of aux busses as it
|
||||
no longer has its output connected to the Master bus.
|
||||
</li>
|
||||
<li>
|
||||
Add an aux send to each channel the performer needs to hear
|
||||
@ -75,7 +75,7 @@
|
||||
<p>
|
||||
Ardour is not limited to talking to one personal monitor controller
|
||||
at a time, but is able to deal with many simultaneously, each controlling
|
||||
it's own Aux bus.
|
||||
its own Aux bus.
|
||||
</p>
|
||||
<p class="note">
|
||||
The send controls and feedback all have the send id (1 to n) in line
|
||||
|
@ -70,7 +70,7 @@
|
||||
if the strips have changed. This would be true if a strip gets moved, created or
|
||||
deleted. When this happens Ardour sends <code>/strip/list</code> to the surfaces
|
||||
that have previously requested a <code>/strip/list</code>. This lets the
|
||||
surface know that it's list of strips is no longer valid.
|
||||
surface know that its list of strips is no longer valid.
|
||||
</p>
|
||||
<p class="note">A bus will not have a record enable and so a bus message
|
||||
will have one less parameter than a track. It is the controllers
|
||||
|
@ -32,7 +32,7 @@
|
||||
<p>
|
||||
This field is informational only. It shows where Ardour will receive
|
||||
OSC messages. The system Name and the Port are the most important parts.
|
||||
Normally, Ardour will use 3819 as it's server port. However, if some
|
||||
Normally, Ardour will use 3819 as its server port. However, if some
|
||||
other server is already using this port, Ardour will try to use the next
|
||||
port up and will keep trying up to 10 ports up.
|
||||
</p>
|
||||
|
@ -73,7 +73,7 @@
|
||||
each model once (i.e. it will skip files, if there are clashes).
|
||||
</p>
|
||||
<p>
|
||||
After you have done modifications to a file, it's a good idea to validate it. This can
|
||||
After you have done modifications to a file, it is a good idea to validate it. This can
|
||||
be done using the tool <i>xmllint</i> as shown below:
|
||||
</p>
|
||||
<pre><code class="bash">
|
||||
|
@ -4,7 +4,7 @@
|
||||
</p>
|
||||
|
||||
<table class="dl">
|
||||
<tr><th>Start/Stop</th><td>Starts or stops the playhead, and recording if it's armed</td></tr>
|
||||
<tr><th>Start/Stop</th><td>Starts or stops the playhead, and recording if it is armed</td></tr>
|
||||
<tr><th>Play</th>
|
||||
<tr><th class="sub1">Play Selection</th><td>Only plays the selected part of the session, be it a range or selected regions</td></tr>
|
||||
<tr><th class="sub1">Play Selection w/Preroll</th><td>As the previous menu, except it starts the playback 1/2 bar before the beginning of the selection</td></tr>
|
||||
|
@ -103,7 +103,7 @@ theme tab"/>
|
||||
</li>
|
||||
<li>
|
||||
<p>
|
||||
<strong>Palette</strong> Hover over a color to display it's name. Click
|
||||
<strong>Palette</strong> Hover over a color to display its name. Click
|
||||
on a color to open a color chooser dialog.
|
||||
</p>
|
||||
</li>
|
||||
|
@ -150,7 +150,7 @@ transport tab"/>
|
||||
<li>
|
||||
<p>
|
||||
<strong>Enable LTC generator</strong>, when enabled Ardour will
|
||||
output an LTC timecode signal on it's <em>LTC-out</em> port.
|
||||
output an LTC timecode signal on its <em>LTC-out</em> port.
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
|
@ -16,7 +16,7 @@
|
||||
|
||||
<p>The two leftmost zoom buttons (<kbd class="menu">−</kbd> and <kbd class="menu">+</kbd>) use this zoom focus to zoom out and in respectively.<p>
|
||||
|
||||
<p>The <kbd class="menu">Zoom to session</kbd> button is a handy shortcut to zoom out or in until all the session (as defined by it's <a href="@@working-with-markers">start/end markers</a>) fits horizontally.</p>
|
||||
<p>The <kbd class="menu">Zoom to session</kbd> button is a handy shortcut to zoom out or in until all the session (as defined by its <a href="@@working-with-markers">start/end markers</a>) fits horizontally.</p>
|
||||
|
||||
<p>Changing the <kbd class="menu">Number of visible tracks</kbd> dropdown menu
|
||||
allows to fit this number of tracks vertically in the screen.<p>
|
||||
|
Loading…
Reference in New Issue
Block a user