Various manual edits
Typo fixes, improving readability, conforming to the style guide, etc.
This commit is contained in:
parent
aef2845ef8
commit
cd424ba51a
12
STYLE_GUIDE
12
STYLE_GUIDE
@ -120,7 +120,7 @@ signal to the build system that it is an internal link that needs to be fixed
|
||||
so that it points to the correct URL.
|
||||
|
||||
|
||||
4.1 Inline markups
|
||||
4.2 Inline markups
|
||||
------------------
|
||||
|
||||
<dfn>
|
||||
@ -156,7 +156,7 @@ spacing of sections. If you're unhappy with those, fix the CSS (which fixes the
|
||||
entire manual in one go!).
|
||||
|
||||
|
||||
4.2 Lists
|
||||
4.3 Lists
|
||||
---------
|
||||
|
||||
<ul>, <ol>
|
||||
@ -170,7 +170,7 @@ Definition lists are for technical terms <dt> and their definition <dd>. Do
|
||||
not abuse them for anything else.
|
||||
|
||||
|
||||
4.3 Quotations
|
||||
4.4 Quotations
|
||||
--------------
|
||||
|
||||
<blockquote>
|
||||
@ -182,7 +182,7 @@ For inline citations, the <cite>W3C</cite> recommends to <q cite="http://
|
||||
www.w3.org/TR/xhtml1/dtds.html">use the cite and q elements</q>.
|
||||
|
||||
|
||||
4.4 Keyboard/Controller interaction
|
||||
4.5 Keyboard/Controller interaction
|
||||
-----------------------------------
|
||||
|
||||
<kbd>
|
||||
@ -237,7 +237,7 @@ is only used for the textual output of any code, never for anything the user
|
||||
types or presses.
|
||||
|
||||
|
||||
4.5 Images
|
||||
4.6 Images
|
||||
----------
|
||||
|
||||
<img>
|
||||
@ -260,7 +260,7 @@ inside as well to describe to the reader what the image is.
|
||||
|
||||
* Avoid any typographical quotation marks to highlight terms or express any
|
||||
kind of subtle inflection, use semantic markup instead.
|
||||
* The hyphen is used to for compound words such as this well-advised example.
|
||||
* The hyphen is used for compound words such as this well-advised example.
|
||||
* Do not hyphenate words at line breaks.
|
||||
* For breaks in thought—such as this splendid example—use the long
|
||||
em-dash. Note that the em-dash is snugged up against the text on both
|
||||
|
@ -18,7 +18,7 @@
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>Making sure there is actaully an input signal</li>
|
||||
<li>Making sure there is actually an input signal</li>
|
||||
<li>Making sure the input signal is getting into the computer</li>
|
||||
<li>Making sure that Ardour is talking to the correct sound card</li>
|
||||
<li>Making sure that the sound card in use by Ardour is working properly</li>
|
||||
|
@ -18,7 +18,7 @@
|
||||
<h2>Crossfades</h2>
|
||||
|
||||
<p>
|
||||
<dfn>Crossfades</dfn> refer to the behavior of two audio regions transitionning
|
||||
<dfn>Crossfades</dfn> refer to the behavior of two audio regions transitioning
|
||||
smoothly (mixing) from one to another on the same
|
||||
track. Historically, this was done by splicing two pieces of analog
|
||||
tape together, and this concept was carried forward into digital
|
||||
@ -26,14 +26,14 @@
|
||||
two regions are butted against each other, there needs to be a method
|
||||
to splice them smoothly together. The crossfade allows one region
|
||||
to fade smoothly out, while the next region fades smoothly in, like two
|
||||
pieces of tape that have been cut at and angle, and overlapped.
|
||||
pieces of tape that have been cut at an angle, and overlapped.
|
||||
</p>
|
||||
<p>
|
||||
But Ardour uses a more refined "layered" editing model, and
|
||||
therefore it is possible for multiple regions to be stacked on a single
|
||||
location with arbitrary overlaps between different layers. For
|
||||
this reason, crossfades must be implemented differently. It can't be
|
||||
assumed that a crossfade is an entitry that exists between two regions;
|
||||
assumed that a crossfade is an entity that exists between two regions;
|
||||
instead each region must have its own associated crossfades at each
|
||||
end, and the topmost region must always crossfade down to the
|
||||
underlying region(s), if any.
|
||||
@ -93,13 +93,13 @@
|
||||
transition.</td></tr>
|
||||
<tr><th><kbd class="menu">Constant power</kbd></th><td>The constant power
|
||||
curve starts fading slowly and then cuts off abruptly. When used as a
|
||||
crossfade between 2 audio regions, the signals are symetrically attenuated,
|
||||
crossfade between 2 audio regions, the signals are symmetrically attenuated,
|
||||
and they each reach -3dB at the midpoint. This is the correct crossfade to
|
||||
use when splicing audio in the general ( uncorrelated ) case.</td></tr>
|
||||
<tr><th><kbd class="menu">Symmetric</kbd></th><td>The Symmetric fade starts
|
||||
slowly, then attenuates significantly before transitioning to a slower
|
||||
fade-out near the end of the fade. When used as a crossfade, the Symmetric
|
||||
curve is not mathematically correct like the Equal Power or Linear curves,
|
||||
curve is not mathematically correct like the Constant Power or Linear curves,
|
||||
but it provides a slower fade-out at low volumes. This is sometimes useful
|
||||
when editing 2 entire music works together so that the transition is more
|
||||
gradual.</td></tr>
|
||||
|
@ -83,7 +83,7 @@
|
||||
possible to enter part of a full time value.
|
||||
</p>
|
||||
<p>
|
||||
As an exemple, supposing that the clock is in BBT mode, displaying
|
||||
As an example, supposing that the clock is in BBT mode, displaying
|
||||
<samp>024|03|0029</samp>, altering the value to the first beat of the current
|
||||
bar can be done by clicking on the clock and typing
|
||||
<kbd>0</kbd><kbd>1</kbd><kbd>0</kbd><kbd>0</kbd><kbd>0</kbd><kbd>0</kbd>.
|
||||
@ -123,7 +123,7 @@
|
||||
|
||||
<p>
|
||||
With the mouse pointer over the clock, pressing the left mouse button and
|
||||
dragging also affects the clocks : dragging upwards increases the value shown
|
||||
dragging also affects the clocks: dragging upwards increases the value shown
|
||||
on the clock, dragging downwards decreases it, again with a step size equal to
|
||||
the unit of the field where the drag began on.
|
||||
</p>
|
||||
|
@ -6,7 +6,7 @@
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You can also export the outputs of multiple tracks & busses all at once via
|
||||
You can also export the outputs of multiple tracks and busses all at once via
|
||||
<kbd class="menu">Session > Export > Stem Export…</kbd>.
|
||||
</p>
|
||||
|
||||
@ -118,7 +118,7 @@
|
||||
|
||||
<p>
|
||||
Checking <kbd class="option">Analyze Exported Audio</kbd> shows the Export Report/Analysis
|
||||
window. This provides a lot of usefull informations about the exported file:
|
||||
window. This provides a lot of useful information about the exported file:
|
||||
</p>
|
||||
<ul>
|
||||
<li>the file name and location</li>
|
||||
|
@ -85,7 +85,7 @@ choose the dithering algorithm to use.
|
||||
<p>
|
||||
As well as exporting an audio file, create a file (in CUE or TOC format
|
||||
respectively) containg CD track information, as defined in the
|
||||
<a href="@@the-ranges-and-marks-lists">Ranges & Marks List</a>.
|
||||
<a href="@@the-ranges-and-marks-lists">Ranges and Marks List</a>.
|
||||
|
||||
|
||||
<h4>Tag with session's metadata</h4>
|
||||
@ -114,7 +114,7 @@ Certain sequences are allowed here to stand for the exported file name and the
|
||||
like. Currently these are:
|
||||
<table class="dl">
|
||||
<tr><th><code>%f</code></th>
|
||||
<td>Full path & filename of the exported audio file</td></tr>
|
||||
<td>Full path and filename of the exported audio file</td></tr>
|
||||
<tr><th><code>%d</code></th>
|
||||
<td>Directory containing the exported audio file (including trailing directory separator)</td></tr>
|
||||
<tr><th><code>%b</code></th>
|
||||
|
@ -29,7 +29,7 @@
|
||||
For example, <code>ardour5</code> where the Ardour version is 5.6.
|
||||
</p>
|
||||
<p class="note">
|
||||
In Linux, all path names are lower case and case matters.
|
||||
In Linux, all path names are lowercase and case-sensitive.
|
||||
</p>
|
||||
|
||||
<h3>macOS</h3>
|
||||
|
@ -33,7 +33,7 @@
|
||||
<p>
|
||||
<kbd class="mouse">Right</kbd> clicking on the MIDI region to be independent
|
||||
then selecting <kbd class="menu">MIDI > Unlink From Other Copies</kbd>
|
||||
makes it independant: the copy is now using its own version of the data, and
|
||||
makes it independent: the copy is now using its own version of the data, and
|
||||
edits to the copy will affect only the copy. Other copies will continue to
|
||||
share data.
|
||||
</p>
|
||||
|
@ -10,7 +10,7 @@ This Documentation is Work in Progress and far from complete. Also the documente
|
||||
|
||||
<h2 id="Preface">Preface</h2>
|
||||
<p>
|
||||
There are cases that a Ardour cannot reasonably cater for with core functionality by itself, either because they're session specific or user specific edge cases.
|
||||
There are cases that Ardour cannot reasonably cater to with core functionality alone, either because they're session specific or user specific edge cases.
|
||||
</p><p>
|
||||
Examples for these include voice-activate (record-arm specific tracks and roll transport depending on signal levels),
|
||||
rename all regions after a specific timecode, launch an external application when a certain track is soloed, generate automation curves
|
||||
@ -31,8 +31,8 @@ but provides for a much nicer reading and learning experience.
|
||||
|
||||
<h2 id="Overview">Overview</h2>
|
||||
<p>
|
||||
The core of ardour is a real-time audio engine that runs and processes audio. One interfaces with than engine by sending it commands.
|
||||
Scripting can be used to interact with or modify active Ardour session. Just like a user uses the Editor/Mixer GUI to modify the state or parameters of the session.
|
||||
The core of Ardour is a real-time audio engine that runs and processes audio. One interfaces with an engine by sending it commands.
|
||||
Scripting can be used to interact with or modify the active Ardour session, just like a user uses the Editor/Mixer GUI to modify the state or parameters of the session.
|
||||
</p><p>
|
||||
Doing this programmatically requires some knowledge about the objects used internally.
|
||||
Most Ardour C++ objects and their methods are directly exposed to Lua and one can call functions or modify variables:
|
||||
@ -55,7 +55,7 @@ Most Ardour C++ objects and their methods are directly exposed to Lua and one ca
|
||||
<div style="clear:both;"></div>
|
||||
|
||||
<p>
|
||||
You may notice that there is only a small syntactic difference, in this case.
|
||||
You may notice that there is only a small syntactic difference in this case.
|
||||
While C++ requires recompiling the application for every change, Lua script can be loaded, written or modified while the application is running.
|
||||
Lua also abstracts away many of the C++ complexities such as object lifetime, type conversion and null-pointer checks.
|
||||
</p><p>
|
||||
@ -154,7 +154,7 @@ Scripts that come with Ardour (currently mostly examples) can be found in the <a
|
||||
|
||||
<h3 id="Action Scripts">Action Scripts</h3>
|
||||
<p>Action scripts are the simplest form. An anonymous Lua function is called whenever the action is triggered. A simple action script is shown above.</p>
|
||||
<p>There are 10 action script slots available, each of which is a standard GUI action available from the menu and hence can be bound to a keyboard shortcut</p>
|
||||
<p>There are 10 action script slots available, each of which is a standard GUI action available from the menu and hence can be bound to a keyboard shortcut.</p>
|
||||
|
||||
<h3 id="Session Scripts">Session Scripts</h3>
|
||||
<p>Session scripts similar to Actions Scripts, except the anonymous function is called periodically every process cycle.
|
||||
@ -262,7 +262,7 @@ end
|
||||
<p>
|
||||
The top most object in Ardour is the <code>ARDOUR::Session</code>.
|
||||
Fundamentally, a Session is just a collection of other things:
|
||||
Routes (tracks, busses), Sources (Audio/Midi), Regions, Playlists, Locations, Tempo map, Undo/Redo history, Ports, Transport state & controls, etc.
|
||||
Routes (tracks, busses), Sources (Audio/Midi), Regions, Playlists, Locations, Tempo map, Undo/Redo history, Ports, Transport state and controls, etc.
|
||||
</p><p>
|
||||
Every Lua interpreter can access it via the global variable <code>Session</code>.
|
||||
</p><p>
|
||||
@ -279,8 +279,8 @@ Meanwhile <a href="https://github.com/Ardour/ardour/blob/master/libs/ardour/luab
|
||||
<ul>
|
||||
<li>There are no bound constructors: Lua asks Ardour to create objects (e.g. add a new track), then receives a reference to the object to modify it.</li>
|
||||
<li>Scripts, once loaded, are saved with the Session (no reference to external files). This provides for portable Sessions.</li>
|
||||
<li>Lua Scripts are never executed directly. They provide a "factory" method which can have optional instantiation parameters, which returns a lua closure.</li>
|
||||
<li>No external lua modules/libraries can be used, scripts need to be self contained (portable across different systems (libs written in Lua can be used, and important c-libs/functions can be included with ardour if needed).</li>
|
||||
<li>Lua Scripts are never executed directly. They provide a "factory" method which can have optional instantiation parameters, which returns a Lua closure.</li>
|
||||
<li>No external Lua modules/libraries can be used, scripts need to be self contained (portable across different systems (libs written in Lua can be used, and important c-libs/functions can be included with Ardour if needed).</li>
|
||||
</ul>
|
||||
<p>
|
||||
Ardour is a highly multithreaded application and interaction between the different threads, particularly real-time threads, needs to to be done with care.
|
||||
@ -288,12 +288,12 @@ This part has been abstracted away by providing separate Lua interpreters in dif
|
||||
</p>
|
||||
<ul>
|
||||
<li>Editor Actions run in a single instance interpreter in the GUI thread.</li>
|
||||
<li>Editor Hooks connect to libardour signals. Every Callback uses a dedicated lua interpreter which is in the GUI thread context.</li>
|
||||
<li>Editor Hooks connect to libardour signals. Every Callback uses a dedicated Lua interpreter which is in the GUI thread context.</li>
|
||||
<li>All Session scripts run in a single instance in the main real-time thread (audio callback)</li>
|
||||
<li>DSP scripts have a separate instance per script and run in one of the DSP threads.</li>
|
||||
</ul>
|
||||
<p>
|
||||
The available interfaces differ between contexts. e.g. it is not possible to create new tracks or import audio from real-time context; while it is not possible to modify audio buffers from the GUI thread.
|
||||
The available interfaces differ between contexts. For example, it is not possible to create new tracks or import audio from real-time context; while it is not possible to modify audio buffers from the GUI thread.
|
||||
</p>
|
||||
|
||||
<h2 id="Current State">Current State</h2>
|
||||
@ -305,7 +305,7 @@ Fully functional, yet still in a prototyping stage:
|
||||
<li>Further planned work includes:
|
||||
<ul>
|
||||
<li>Built-in Script editor (customize/modify Scripts in-place)</li>
|
||||
<li>convenience methods (wrap more complex Ardour actions into a library). e.g set plugin parameters, write automation lists from a lua table</li>
|
||||
<li>convenience methods (wrap more complex Ardour actions into a library). e.g set plugin parameters, write automation lists from a Lua table</li>
|
||||
<li>Add some useful scripts and more examples</li>
|
||||
<li>Documentation (Ardour API), also usable for tab-exansion, syntax highlighting</li>
|
||||
<li>bindings for GUI Widgets (plugin UIs, message boxes, etc)</li>
|
||||
|
@ -119,7 +119,7 @@
|
||||
|
||||
<img class="right" src="/images/mixer-meter-context-menu.png" alt="mixer strip meter context menu" />
|
||||
<p>
|
||||
Meters are available in various places in ardour:
|
||||
Meters are available in various places in Ardour:
|
||||
</p>
|
||||
<ul>
|
||||
<li>The mixer window features fixed height meters for each <dfn>channel strip</dfn>.</li>
|
||||
@ -166,7 +166,7 @@ alt="Needle-style meters as external LV2 plugins" />
|
||||
alt="Bar-graph meters in Ardour" />
|
||||
|
||||
<p>
|
||||
Due to layout concerns and consistent look&feel all meters available in
|
||||
Due to layout concerns and consistent look and feel all meters available in
|
||||
Ardour itself are bar-graph type meters. Corresponding needle-style
|
||||
meters—which take up more visual screen space—are available as
|
||||
LV2 plugins (see image on the right):
|
||||
|
@ -27,7 +27,7 @@
|
||||
<tr><th>Start</th><td>the timestamp of the start of the note</td></tr>
|
||||
<tr><th>Channel</th><td>the MIDI channel of the event</td></tr>
|
||||
<tr><th>Num</th><td>The <a href="@@midi-notes-ref">MIDI number</a> of the note</td></tr>
|
||||
<tr><th>Name</th><td>The MIDI name of the note, made of its english name and octave (e.g. "C4")</td></tr>
|
||||
<tr><th>Name</th><td>The MIDI name of the note, made of its English name and octave (e.g. "C4")</td></tr>
|
||||
<tr><th>Vel</th><td>the velocity of the note (i.e. its intensity, between 0 and 127)</td></tr>
|
||||
<tr><th>Length</th><td>duration of the note, either expressed as a number (in ticks, related to the tempo) or as a text (fraction of a beat, also related to the tempo)</td></tr>
|
||||
</table>
|
||||
|
@ -24,7 +24,7 @@
|
||||
</li>
|
||||
<li>
|
||||
Clicks on the piano header of the track (if visible—the track must
|
||||
be tall enough to display it) will select all occurences of that note.
|
||||
be tall enough to display it) will select all occurrences of that note.
|
||||
</li>
|
||||
<li>
|
||||
Drags on the piano header of the track will select all notes within the
|
||||
|
@ -37,7 +37,7 @@
|
||||
<h2>Using Playlists for Multi-Language Productions</h2>
|
||||
<p>
|
||||
The same approach as for takes is useful when recording or editing content in
|
||||
multiple versions, such as dubbed movie dialog in several languages : having
|
||||
multiple versions, such as dubbed movie dialog in several languages: having
|
||||
all versions on the same track allows to apply the same processing, making it
|
||||
easy to switch language before exporting the session.
|
||||
</p>
|
||||
|
@ -13,7 +13,7 @@
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The main box in the top half of a mixer strip shows the <dfn>processor box</dfn>. Processors are shown as colored rectangles, with a small "LED" beside them that lights up when the processor is enabled. The color of the processor depends on its location in the sequence; processors that are <dfn>pre-fader</dfn> are colored in red, and <dfn>post-fader</dfn> processors are colored green (in the default theme).
|
||||
The main box in the top half of a mixer strip shows the <dfn>processor box</dfn>. Processors are shown as colored rectangles, with a small LED beside them that lights up when the processor is enabled. The color of the processor depends on its location in the sequence; processors that are <dfn>pre-fader</dfn> are colored in red, and <dfn>post-fader</dfn> processors are colored green (in the default theme).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@ -47,7 +47,7 @@
|
||||
<h2>To Reorder (Move) Processors</h2>
|
||||
|
||||
<p>
|
||||
Processors can be re-ordered using drag & drop. Dragging a processor allows it to be moved around within the chain, or copied to another processor list on another track or bus.
|
||||
Processors can be re-ordered using drag and drop. Dragging a processor allows it to be moved around within the chain, or copied to another processor list on another track or bus.
|
||||
</p>
|
||||
|
||||
<h2>To Enable/Disable a Processor</h2>
|
||||
|
@ -24,7 +24,7 @@
|
||||
</figure>
|
||||
|
||||
<p>
|
||||
In the initial situation, before trimming, two adjascent regions are present,
|
||||
In the initial situation, before trimming, two adjacent regions are present,
|
||||
the rightmost-one being selected.
|
||||
</p>
|
||||
<p>
|
||||
|
@ -46,7 +46,7 @@
|
||||
<p>
|
||||
Duplicating or splitting a region creates new region(s) that
|
||||
are based on the same original files. Hence, they share the same base name (in the
|
||||
exemple above, <samp>Hang drum-1</samp>), but their version number will be incremented
|
||||
example above, <samp>Hang drum-1</samp>), but their version number will be incremented
|
||||
each time. Duplicating <samp>Hang drum-1.4</samp> by <kbd class="mod1 mouse">left</kbd>
|
||||
dragging it will create a new region called <samp>Hang drum-1.5</samp>. Splitting
|
||||
<samp>Hang drum-1.5</samp> by hitting the <kbd>S</kbd> key will remove the
|
||||
|
@ -70,10 +70,10 @@
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In the first example above, if the entire drum part is on one track, then compressing with this signal as a sidechain will result in every peak triggering the compression, be them bass drum kicks or snare, cymbals, etc.
|
||||
In the first example above, if the entire drum part is on one track, then compressing with this signal as a sidechain will result in every peak triggering the compression, be they bass drum kicks or snare, cymbals, etc.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In this case, adding an EQ to the drum track with a low pass filter would filter out the peaks created by the high pitched instruments of the drum kit, and allow for a better triggering, though to avoid damaging the original drum track, a send to an intermediary track would be better suited to place the EQ on. This track won't be connected to the Master, as its content is of no musical interest except for it's use as a trigger, allowing for some extreme EQ.
|
||||
In this case, adding an EQ to the drum track with a low pass filter would filter out the peaks created by the high pitched instruments of the drum kit, and allow for a better triggering, though to avoid damaging the original drum track, a send to an intermediary track would be better suited to place the EQ on. This track won't be connected to the Master, as its content is of no musical interest except for its use as a trigger, allowing for some extreme EQ.
|
||||
</p>
|
||||
|
||||
|
@ -5,7 +5,7 @@
|
||||
key.
|
||||
</p>
|
||||
<p>
|
||||
It allows to extend or reduce the duration of a region, optionnaly maintaining
|
||||
It allows to extend or reduce the duration of a region, optionally maintaining
|
||||
its pitch. This is one of the few operations in Ardour that affect the underlying
|
||||
audio data from a region, even if the original audio is kept safely—no data
|
||||
is lost in the process.
|
||||
@ -13,7 +13,7 @@
|
||||
<p>
|
||||
This operation is usually used to fit an audio sequence with a different rhythm
|
||||
into a session, but can be used in a wide area of cases, due to its ability to
|
||||
maitain or alter the pitch.
|
||||
maintain or alter the pitch.
|
||||
</p>
|
||||
|
||||
<figure>
|
||||
|
@ -58,7 +58,7 @@
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Audio locked tempo marks stay in their frame position as their neigbour's
|
||||
Audio locked tempo marks stay in their frame position as their neighbour's
|
||||
positions are altered. Their pulse (musical) position will change as their
|
||||
neighbours move. Music locked tempo marks move their frame position as their
|
||||
neighbours are moved, but keep their pulse position (they will move as the
|
||||
|
@ -71,7 +71,7 @@
|
||||
all data is recorded to a single file and if a section of
|
||||
existing data is overdub, the existing data is destroyed irrevocably—there is no
|
||||
undo. Fixed crossfades are added at every punch in and out point. This mode
|
||||
can be useful for certain kinds of re-recording workflows, but it not
|
||||
can be useful for certain kinds of re-recording workflows, but is not
|
||||
suggested for normal
|
||||
use.</td></tr>
|
||||
</table>
|
||||
|
@ -105,7 +105,7 @@
|
||||
|
||||
<p>
|
||||
By default, the I/O config is set to <em>Automatic</em>, i.e. the <kbd
|
||||
class="menu">Manual Config</kbd> led light is turned off. In this mode, the
|
||||
class="menu">Manual Config</kbd> LED light is turned off. In this mode, the
|
||||
diagram will display the standard input/outputs for this plugin, i.e. the
|
||||
number of ports (inputs & outputs) is equal to the number of pins on the
|
||||
plugin, and a one-to-one connection is automatically created.
|
||||
@ -144,7 +144,7 @@
|
||||
<p>
|
||||
The window allows connection of the I/O ports to the plugin pins and other
|
||||
I/O ports, provided they are compatible (MIDI vs. audio), just by dragging
|
||||
& dropping the end connectors on top of one another. A dotted connector's
|
||||
and dropping the end connectors on top of one another. A dotted connector's
|
||||
line is a "<em>thru</em>" line that directly connects an input to an output
|
||||
without connecting to a pin on the plugin—hence without any audio
|
||||
modification. These "thru" connections are latency compensated, with respect
|
||||
|
@ -51,9 +51,9 @@
|
||||
presets.
|
||||
</p>
|
||||
<p>
|
||||
As last note: every time a video is transcoded, the quality can only get
|
||||
As a last note: every time a video is transcoded, the quality can only get
|
||||
worse. Hence for the final mastering/<abbr
|
||||
title="Multiplexing Audio and Video">muxing</abbr> process, one should
|
||||
always to back and use the original source of the video.
|
||||
always go back and use the original source of the video.
|
||||
</p>
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
<p>
|
||||
Considering the numerical nature of MIDI events, it can be tempting to apply
|
||||
mathematical transformations to our MIDI regions by using mathematical
|
||||
operations. Ardour makes it very easy and powerfull with the Transform tool.
|
||||
operations. Ardour makes it very easy and powerful with the Transform tool.
|
||||
</p>
|
||||
|
||||
<figure>
|
||||
@ -27,7 +27,7 @@
|
||||
<p>
|
||||
In the picture above, the Transform tool has been used to add a bit of
|
||||
humanization, by slightly changing the velocity of each note of the region, by
|
||||
a random number between -19 and +19 from it's original velocity. So
|
||||
a random number between -19 and +19 from its original velocity. So
|
||||
three operations are applied:
|
||||
</p>
|
||||
|
||||
@ -77,14 +77,14 @@
|
||||
|
||||
<ul>
|
||||
<li>+ (addition)</li>
|
||||
<li>- (substration)</li>
|
||||
<li>- (subtraction)</li>
|
||||
<li>* (multiplication)</li>
|
||||
<li>/ (euclidian division)</li>
|
||||
<li>mod (rest of the euclidian division).</li>
|
||||
<li>mod (remainder of the euclidian division).</li>
|
||||
</ul>
|
||||
|
||||
<p class="note">
|
||||
All these operations can be very handy, as long as ther is a mathematical way
|
||||
All these operations can be very handy, as long as there is a mathematical way
|
||||
to achieve the targeted goal. Beware though of odd "border cases": division by
|
||||
zero (which does nothing), using the note's index and forgetting it starts at
|
||||
0 and not 1, etc.
|
||||
|
@ -15,7 +15,7 @@
|
||||
|
||||
<p>
|
||||
This very simple dialog allows to choose either a number of semitones to add
|
||||
or substract to all the notes inside the region(s), and/or for more significant
|
||||
or subtract to all the notes inside the region(s), and/or for more significant
|
||||
changes, octaves (12 semitones).
|
||||
</p>
|
||||
|
||||
|
@ -48,9 +48,9 @@
|
||||
<td>Trim selected region(s) beginning and end to the loop/punch boundaries (if it exists).</td></tr>
|
||||
<tr><th><dfn>Trim to Previous</dfn> (<kbd class="mod1">j</kbd>)</th>
|
||||
<td>Trim the start of selected region(s) to the end of the previous region.
|
||||
If the region is too short, it is extended to it's maximum to the left.</td></tr>
|
||||
If the region is too short, it is extended to its maximum to the left.</td></tr>
|
||||
<tr><th><dfn>Trim to Next</dfn> (<kbd class="mod1">k</kbd>)</th>
|
||||
<td>Trim the end of selected region(s) to the start of the following region.
|
||||
If the region is too short, it is extended to it's maximum to the right.</td></tr>
|
||||
If the region is too short, it is extended to its maximum to the right.</td></tr>
|
||||
</table>
|
||||
|
||||
|
@ -35,7 +35,7 @@
|
||||
time, and tracks can even share playlists.
|
||||
</p>
|
||||
<p>
|
||||
Some other <abbr title="Digital Audio Workstation">DAW</abbr>s, us the term
|
||||
Some other <abbr title="Digital Audio Workstation">DAW</abbr>s use the term
|
||||
<dfn>"virtual track"</dfn> to define a track that isn't actually playing or
|
||||
doing anything, but can be mapped/assigned to a real track. This concept is
|
||||
functionally identical to Ardour's playlists. We just like to be little more
|
||||
@ -48,7 +48,7 @@
|
||||
One thing to bear in mind is that playlists are cheap. They
|
||||
do not cost anything in terms of CPU consumption, and they have very
|
||||
minimal efforts on memory use. So generating new playlists whenever needed
|
||||
is recommendable. They are not equivalent to tracks,
|
||||
is recommended. They are not equivalent to tracks,
|
||||
which require extra CPU time and significant memory space, or audio
|
||||
files, which use disk space, or plugins that require extra CPU time.
|
||||
If a playlist is not in use, it occupies a small amount of memory, and
|
||||
|
@ -108,8 +108,8 @@
|
||||
<p>
|
||||
Ardour video export is not recommended for mastering! While ffmpeg
|
||||
(which is used by Ardour) can produce high-quality files, this export
|
||||
lacks the possibility to tweak many settings. We recommend to use winff,
|
||||
devede or dvdauthor to mux & master. Nevertheless this video-export c
|
||||
omes in handy to do quick snapshots, intermediates, dailies or online videos.
|
||||
lacks the possibility to tweak many settings. We recommend using winff,
|
||||
devede or dvdauthor to mux and master. Nevertheless this video-export comes in
|
||||
handy to do quick snapshots, intermediates, dailies or online videos.
|
||||
</p>
|
||||
|
||||
|
@ -16,7 +16,7 @@
|
||||
markers to compact disc images.
|
||||
</li>
|
||||
<li>
|
||||
The <dfn>Loop range</dfn> defines the start end end points for Looping.
|
||||
The <dfn>Loop range</dfn> defines the start and end points for Looping.
|
||||
</li>
|
||||
<li>
|
||||
The <dfn>punch range</dfn> defines the in and out points for punch
|
||||
|
Loading…
Reference in New Issue
Block a user