master and two extenders with the master on the left, in the center
and on the right. While these files will work for many uses there may
be cases where a custom device profile makes more sense.
- The best way is to start with the *.device file that matches your
- master device and copy it
- to a new name such as xt+mc.device and then edit that file. It is best to
+ The best way is to start with the *.device file in the <a
+ href="/appendix/files-and-directories/">
+ sytem config sub directory mcp</a> that matches your
+ master device and copy it to a new name such as xt+mc.device in the
+ <a href="/appendix/files-and-directories/">
+ user config sub directory mcp</a> and then edit that file. It is best to
name the file with the order the devices are expected to be used in as
the position of the master device is specified in this file.
</p>
</p>
<p>
The <code>Name</code> value should be a unique name so it is obvious
- in the list of devices.
+ in the list of devices (so change it).
</p>
<p>
The <code>Extenders</code>
<p>
When an <code>Extenders</code> value of greater than 0 is used, extra midi
ports will appear for the extenders to be connected to. The MIDI ports
- for the controllers will be named <code>mackie control #1</code>,
- <code>mackie control #2</code> and up. The numbers will go from left to
- right. That is, from lowest number channel to highest.
+ for the controllers will be named <code>mackie control in/out</code> for
+ the master, <code>mackie control in/out ext #*</code> where * is the
+ position of the extender from left to right. So for a master in the middle
+ with an extender on either side, the ports from left to right will be
+ mackie control in/out ext #1, mackie control in/out and mackie control in/out ext #3.
</p>
<p>
- The <code>MasterPosition</code> value is the port number the master unit
- (with the master fader) is connected to. So if there are three surfaces,
- <code><MasterPosition value="1"/></code> will expect the master on
- the left, <code><MasterPosition value="2"/></code> would be master
- in the middle and <code><MasterPosition value="3"/></code> would be
- master on the right. So the position matches the port name.
+ If using the MCP GUI to connect surfaces the top surface is the leftmost
+ and the bottom is the rightmost. The GUI shows explicitly the position
+ of the main or master surface within the group of surfaces.
+</p>
+<p><img alt="the Mackie Control Device Dialog"
+ src="/images/mcp-extender-position.png"></p>
+<p>
+ The <code>MasterPosition</code> value is the position the master unit
+ (with the master fader) is located at within the group of surfaces.
+ The surfaces are numbered from 1 at the left side and up. So if there
+ are three surfaces, <code><MasterPosition value="1"/></code> will
+ expect the master on the left, <code><MasterPosition value="2"/></code>
+ would be master in the middle and <code><MasterPosition value="3"/></code>
+ would be master on the right.
</p>
<p class="note">
The default value of <code><MasterPosition value="0"/></code> has
</p>
<p>
If the <code>MasterPosition</code> value does not properly match the
- physcal position and MIDI port, the master fader and global controls will
+ physical position and MIDI port, the master fader and global controls will
not work. The master unit will act like an extender.
</p>
--- /dev/null
+---
+layout: default
+title: Files and Directories Ardour Knows About
+---
+
+<h2>Configuration Directories</h2>
+<p>
+ Ardour stores configuration files in two places. The system configuration
+ directory and the user configuration directory. The system configuration
+ directory is used for stock configuration files and is used by all
+ users on any one system. The user configuration directory is used by
+ Ardour to store configuration changes made in the GUI as well as being
+ a place the user can add control surface device files, scripts etc.
+</p>
+
+<p>
+ Ardour tries to use standard places for these directories for the platform
+ it is running on.
+</p>
+<h3>Linux</h3>
+<p>
+ Linux is the most variable of the platforms mainly due to Ardour obtained from
+ a distro package. If Ardour is obtained from ardour.org as a ready to install
+ and run bundle, the system configuration directory will always be in
+ /opt/Ardour-major.minor.sub/share/ That is it will match the name of the
+ file you downloaded. If Ardour is self built and installed with the
+ default install path (yes you can change this) then system configuration
+ will be in /usr/local/share/ardour*/ where * is the major number such as
+ /usr/local/share/ardour5/ for Ardour 5.6. If you have installed Ardour
+ as a package from your distro, then distro policy will dictate where
+ it is installed. /usr/share/ardour*/ is quite common and a good place to start
+ looking. However, the Ardour development team does not support these
+ distro builds nor keep track of where they may put things.
+</p>
+<p>
+ The user configuration directory will be somewhere inside the user's
+ home directory. A normal place to find this is ~/.config/ardour*/ where
+ * is the major version. However this can be set by the system with the
+ $XDG_CONFIG_HOME environment variable to something else. If you can not
+ find ~/.config/ on your system try echo ${XDG_CONFIG_HOME} to see if your
+ distro is using something else.
+</p>
+<h3>OSx or MacOS</h3>
+<p>
+ maybe someone who has a MAC can complete this section.
+</p>
+<h3>Windows</h3>
+<p>
+ This section also needs someone with real knowledge to complete it.
+</p>
+
+<h2>Plugins</h2>
+<p>
+ Plugins will be installed in various places, some by standard and some
+ by developer whim. Some are installed incorrectly by distro policy.
+</p>
+
+<h3>Linux</h3>
+<p>
+ In linux there are 3 kinds of plugins Ardour can use. LADSPA, LV2 (LADSPA version 2)
+ or lxvst (VSTs compiles as native linux binaries). While it is possible
+ with some strange magic to run <a href="/working-with-plugins/windows-vst-support/">Windows VSTs</a>
+ on linux, their whereabouts would follow the Windows info below.
+</p>
+
+<h4>LADSPA</h4>
+<p>
+ LADSPA plugins should be found in /usr/lib/ladspa/, /usr/local/lib/ladspa/
+ or in a directory mentioned in your LADSPA_PATH environment variable.
+ The most common mistake made by distro packagers, is to use a path
+ like /usr/lib/$ARCH/ladspa/ and find that Ardour will not find that by
+ default. The user can either add a link from this actual directory to
+ the standard directory or add this path to LADSPA_PATH.
+</p>
+
+<h4>LV2</h4>
+<p>
+ LADSPA plugins should be found in /usr/lib/lv2/, /usr/local/lib/lv2/
+ or in a directory mentioned in your LV2_PATH environment variable.
+ The most common mistake made by distro packagers, is to use a path
+ like /usr/lib/$ARCH/lv2/ and find that Ardour will not find that by
+ default. The user can either add a link from this actual directory to
+ the standard directory or add this path to LV2_PATH.
+</p>
+
+<h4>Linux VST or lxvst</h4>
+<p>
+ They are typically installed in /usr/lib/lxvst, /usr/local/lib/lxvst or
+ a directory mentioned in your LXVST_PATH environment variable. However,
+ this is not a standard and the VST plugin developer may install the plugin
+ just about anywhere. Therefore Ardour allows the user to set extra VST
+ paths in the preferences GUI under Plugins>VST.
+</p>
+
+<h3>OSX or MacOS</h3>
+<p>
+ On the Mac, plugins are expected to be installed correctly Ardour uses
+ the system tool to scan for AU style plugins and LV2s should be in the right
+ place. LV2 should be in $HOME/Library/Audio/Plug-Ins/LV2
+ /Library/Audio/Plug-Ins/LV2
+ /usr/local/lib/lv2
+ /usr/lib/lv2
+ If an AU or LV2 plugin does not show up on a Mac it is probably
+ a development fault with the plugin and the plugin will not work with anything.
+ Ardour in Ardour 5.6 has support for native VST plugins. That is VST
+ plugins built for OSX. I am not sure if these have a standard place to
+ be, but as with other VSTs the search path can be edited at Plugins>VST.
+</p>
+
+<h3>Windows</h3>
+<p>
+ The most common plugins on Windows are VSTs. However, LADSPA and LV2
+ plugins are available for windows as well. In fact Ardours built in
+ plugins are LV2s. The biggest advanatage of LV2 plugins is that they are
+ the most likely to be cross platform and therefore allow the same Ardour
+ project to be worked on in Windows, OSX and Linux.
+</p>
+
+<h4>VST</h4>
+<p>
+ As with other platforms, VSTs on Windows do not have a standard place
+ to reside. Ardour Preferences>Plugins>VST allows setting the VST path
+ from the GUI.
+</p>
+<h4>LV2</h4>
+<p>
+ The LV2 standard for Windows is %APPDATA%/LV2 or %COMMONPROGRAMFILES%/LV2
+</p>
+
+<h4>LADSPA</h4>
+<p>
+ While there are LADSPA plugins for Windows, I have been unable to find
+ the standard path for them... perhaps someone knows?
+</p>
+
+<h2>Project Directory</h2>
+<p>
+ Ardour places a project directory where the user tells it to. This
+ directory is chosen when creating a project. In most cases the user
+ does not need to know about the files inside of the project directory.
+ However there are a few subdirectories worth noting.
+</p>
+<h3>export</h3>
+<p>
+ This is the subdirectory where exported files end up.
+</p>
# to handle.
#
# by James Hammons
+# (C) 2017 Underground Software
#
import os
# Make a filename from the title...
levelNames[level] = MakeFilename(header['title'])
-
path = ''
for i in range(level):
path = path + str(levelNums[level]).zfill(2) + '_' + levelNames[level]
- # Append the appropriate footer, if the current file is one level
- # down from the previous...
+ # Append the appropriate footer to the last file, if the current file
+ # is one level down from the previous...
if ((level > 0) and (level > lastLevel)):
nfile = open(buildDir + lastFile + '.html', 'a')
nfile.write('\n{% children %}\n\n')
nfile.close()
- # Parts DO NOT have any content, they are ONLY an organizing construct!
- if (level == 0):
+ # Handle TOC scriblings...
+ if level == 0:
toc.write('<h2>Part ' + roman[levelNums[level]] + ': ' + header['title'] + '</h2>\n');
+ elif level == 1:
+ toc.write(' <p id=chapter>Ch. ' + str(levelNums[level]) + ': <a href="/' + levelNames[0] + '/' + levelNames[1] + '/">' + header['title'] + '</a></p>\n')
+ elif level == 2:
+ toc.write(' <a id=subchapter href="/' + levelNames[0] + '/' + levelNames[1] + '/' + levelNames[2] + '/">' + header['title'] + '</a><br>\n')
+ elif level == 3:
+ toc.write(' <a id=subchapter href="/' + levelNames[0] + '/' + levelNames[1] + '/' + levelNames[2] + '/' + levelNames[3] + '/">' + header['title'] + '</a><br>\n')
+ elif level == 4:
+ toc.write(' <a id=subchapter href="/' + levelNames[0] + '/' + levelNames[1] + '/' + levelNames[2] + '/' + levelNames[3] + '/' + levelNames[4] + '/">' + header['title'] + '</a><br>\n')
+ # Parts DO NOT have any content, they are ONLY an organizing construct!
+ if (level == 0):
os.mkdir(buildDir + path, 0o774)
nfile = open(buildDir + path + '.html', 'w')
nfile.write('---\n' + 'title: ' + header['title'] + '\n')
# Chapters, subchapters, sections & subsections all can have content.
# But the basic fundamental organizing unit WRT content is still the
# chapter.
- elif (level == 1):
- toc.write(' <p id=chapter>Ch. ' + str(levelNums[level]) + ': <a href="/' + levelNames[0] + '/' + levelNames[1] + '/">' + header['title'] + '</a></p>\n')
-
- os.mkdir(buildDir + path, 0o774)
-
- if ('include' in header):
- shutil.copy('include/' + header['include'], buildDir + path + '.html')
- else:
- htmlFile = open(buildDir + path + '.html', 'w')
- writingToFile = True
- htmlFile.write('---\n' + 'title: ' + header['title'] + '\n')
-
- if ('menu_title' in header):
- htmlFile.write('menu_title: ' + header['menu_title'] + '\n')
-
- if ('style' in header):
- htmlFile.write('style: ' + header['style'] + '\n')
-
- htmlFile.write('---\n\n')
-
- elif (level == 2):
- toc.write(' <a id=subchapter href="/' + levelNames[0] + '/' + levelNames[1] + '/' + levelNames[2] + '/">' + header['title'] + '</a><br>\n')
-
- os.mkdir(buildDir + path, 0o774)
-
- if ('include' in header):
- shutil.copy('include/' + header['include'], buildDir + path + '.html')
- else:
- htmlFile = open(buildDir + path + '.html', 'w')
- writingToFile = True
- htmlFile.write('---\n' + 'title: ' + header['title'] + '\n')
-
- if ('menu_title' in header):
- htmlFile.write('menu_title: ' + header['menu_title'] + '\n')
-
- if ('style' in header):
- htmlFile.write('style: ' + header['style'] + '\n')
-
- htmlFile.write('---\n\n')
-
- elif (level == 3):
- toc.write(' <a id=subchapter href="/' + levelNames[0] + '/' + levelNames[1] + '/' + levelNames[2] + '/' + levelNames[3] + '/">' + header['title'] + '</a><br>\n')
-
- os.mkdir(buildDir + path, 0o774)
-
- if ('include' in header):
- shutil.copy('include/' + header['include'], buildDir + path + '.html')
- else:
- htmlFile = open(buildDir + path + '.html', 'w')
- writingToFile = True
- htmlFile.write('---\n' + 'title: ' + header['title'] + '\n')
-
- if ('menu_title' in header):
- htmlFile.write('menu_title: ' + header['menu_title'] + '\n')
-
- if ('style' in header):
- htmlFile.write('style: ' + header['style'] + '\n')
-
- htmlFile.write('---\n\n')
-
- elif (level == 4):
- toc.write(' <a id=subchapter href="/' + levelNames[0] + '/' + levelNames[1] + '/' + levelNames[2] + '/' + levelNames[3] + '/' + levelNames[4] + '/">' + header['title'] + '</a><br>\n')
-
+ else:
os.mkdir(buildDir + path, 0o774)
if ('include' in header):
--- /dev/null
+#!/usr/bin/python
+#
+# Small program to 'explode' the master document automagically into separate
+# files in the include/ directory.
+#
+# by James Hammons
+# (C) 2017 Underground Software
+#
+
+import os
+import re
+import shutil
+
+
+#
+# Create an all lowercase filename without special characters and with spaces
+# replaced with dashes.
+#
+def MakeFilename(s):
+ # This RE is shitty, but I can't think of a better one right now
+ fn = re.sub("[?!'&#:;_*()/\\,.]+", "", s)
+ fn = fn.lower()
+ fn = fn.replace(' ', '-')
+ return fn
+
+
+lineCount = 0
+fileCount = 0
+writingFile = False
+toFile = open('master-doc.txt')
+toFile.close()
+filenames = []
+
+
+master = open('master-doc.txt')
+firstLine = master.readline().rstrip('\r\n')
+master.close()
+
+if firstLine == '<!-- exploded -->':
+ print('Master file has already been exploded.')
+ exit(0)
+
+if os.rename('master-doc.txt', 'master-doc.bak') == False:
+ print('Could not rename master-doc.txt!')
+ exit(-1)
+
+master = open('master-doc.bak', 'r')
+explode = open('master-doc.txt', 'w')
+
+explode.write('<!-- exploded -->\n')
+
+for line in master:
+ lineCount = lineCount + 1
+
+ # Do any header parsing if needed...
+ if line.startswith('---'):
+
+ # Close any open file from the previous header
+ if (writingFile):
+ toFile.close()
+ writingFile = False
+
+ header = {}
+ noMove = False
+
+ while (True):
+ hdrLine = master.readline().rstrip('\r\n')
+ lineCount = lineCount + 1
+
+ # Break out of the loop if we hit the end of header marker
+ if hdrLine.startswith('---'):
+ break
+
+ # Parse out foo: bar pairs & put into header dictionary
+ a = re.split(': ', hdrLine, 1)
+ header[a[0]] = a[1]
+
+ # Make sure the filename we're making is unique...
+ inclFile = MakeFilename(header['title']) + '.html'
+
+ if inclFile in filenames:
+ suffix = 2
+ inclFile = MakeFilename(header['title']) + str(suffix) + '.html'
+
+ while inclFile in filenames:
+ suffix = suffix + 1
+ inclFile = MakeFilename(header['title']) + str(suffix) + '.html'
+
+ # Pull in files and write the result to the master file
+ explode.write('\n---\n' + 'title: ' + header['title'] + '\n')
+
+ if header['part'] != 'part':
+ if 'menu_title' in header:
+ explode.write('menu_title: ' + header['menu_title'] + '\n')
+
+ if 'link' in header:
+ explode.write('link: ' + header['link'] + '\n')
+
+ if 'style' in header:
+ explode.write('style: ' + header['style'] + '\n')
+
+ if 'include' in header:
+ noMove = True
+ explode.write('include: ' + header['include'] + '\n')
+ explode.write('exclude: yes\n')
+ filenames.append(header['include'])
+ else:
+ explode.write('include: ' + inclFile + '\n')
+ filenames.append(inclFile)
+
+ explode.write('part: ' + header['part'] + '\n' + '---\n')
+
+ # Only parts have no content...
+ if header['part'] != 'part':
+ if noMove:
+ explode.write('\n')
+ else:
+ fileCount = fileCount + 1
+
+ toFile = open('include/' + inclFile, 'w')
+ writingFile = True
+ toFile.write('---\n' + 'title: ' + header['title'] + '\n')
+
+ if 'menu_title' in header:
+ toFile.write('menu_title: ' + header['menu_title'] + '\n')
+
+ if 'style' in header:
+ toFile.write('style: ' + header['style'] + '\n')
+
+ toFile.write('---\n')
+ else:
+ if writingFile:
+ toFile.write(line)
+
+master.close()
+explode.close()
+
+print('Processed ' + str(lineCount) + ' lines.')
+print('Exploded master document into ' + str(fileCount) + ' files.')
+
+os.remove('master-doc.bak')
+
--- /dev/null
+#!/usr/bin/python
+#
+# Small program to 'implode' the master document automagically from separate
+# files in the include/ directory.
+#
+# by James Hammons
+# (C) 2017 Underground Software
+#
+
+import os
+import re
+import shutil
+
+
+def CheckForHeader(fn):
+ check = open(fn)
+
+ for line in check:
+ if line.startswith('---'):
+ check.close()
+ return True
+
+ check.close()
+ return False
+
+
+lineCount = 0
+fileCount = 0
+delList = []
+
+master = open('master-doc.txt')
+firstLine = master.readline().rstrip('\r\n')
+master.close()
+
+if firstLine == '<!-- imploded -->':
+ print('Master file has already been imploded.')
+ exit(0)
+
+if os.rename('master-doc.txt', 'master-doc.bak') == False:
+ print('Could not rename master-doc.txt!')
+ exit(-1)
+
+master = open('master-doc.bak', 'r')
+implode = open('master-doc.txt', 'w')
+
+implode.write('<!-- imploded -->\n')
+
+for line in master:
+ lineCount = lineCount + 1
+
+ # Do any header parsing if needed...
+ if line.startswith('---'):
+
+ header = {}
+ noMove = False
+
+ while (True):
+ hdrLine = master.readline().rstrip('\r\n')
+ lineCount = lineCount + 1
+
+ # Break out of the loop if we hit the end of header marker
+ if hdrLine.startswith('---'):
+ break
+
+ # Parse out foo: bar pairs & put into header dictionary
+ a = re.split(': ', hdrLine, 1)
+ header[a[0]] = a[1]
+
+ # Pull in files and write the result to the master file
+ implode.write('\n---\n' + 'title: ' + header['title'] + '\n')
+
+ if header['part'] != 'part':
+ if 'menu_title' in header:
+ implode.write('menu_title: ' + header['menu_title'] + '\n')
+
+ if 'link' in header:
+ implode.write('link: ' + header['link'] + '\n')
+
+ if 'style' in header:
+ implode.write('style: ' + header['style'] + '\n')
+
+ if ('exclude' in header) and ('include' in header):
+ noMove = True
+ implode.write('include: ' + header['include'] + '\n')
+ implode.write('exclude: yes\n')
+
+ implode.write('part: ' + header['part'] + '\n' + '---\n')
+
+ # Only parts have no content...
+ if header['part'] != 'part':
+ if noMove:
+ implode.write('\n')
+ else:
+ fileCount = fileCount + 1
+ inclFile = 'include/' + header['include']
+
+ try:
+ fromFile = open(inclFile)
+ except (FileNotFoundError):
+ print('Could not find include file "include/' + header['include'] + '"; aborting!')
+ os.remove('master-doc.txt')
+ os.rename('master-doc.bak', 'master-doc.txt')
+ exit(-1)
+
+ if CheckForHeader(inclFile) == True:
+
+ # Skip the header
+ while fromFile.readline().startswith('---') == False:
+ pass
+
+ ln = fromFile.readline()
+
+ while fromFile.readline().startswith('---') == False:
+ pass
+
+ shutil.copyfileobj(fromFile, implode)
+ fromFile.close()
+ delList.append(inclFile)
+
+master.close()
+implode.close()
+
+print('Processed ' + str(lineCount) + ' lines.')
+print('Imploded master document from ' + str(fileCount) + ' files.')
+
+os.remove('master-doc.bak')
+
+for name in delList:
+ os.remove(name)
+
+++ /dev/null
----
-title: About Ardour's documentation
----
-
-<h2>Conventions Used In This Manual</h2>
-
-<p>
- This section covers some of the typographical and language conventions used in this manual.
-</p>
-
-<h3>Keyboards and Modifiers</h3>
-
-<p>
- <dfn>Keyboard bindings</dfn> are shown like this: <kbd>s</kbd> or <kbd class="mod1">x</kbd>.
-</p>
-
-<p>
- <kbd class="mod1">x</kbd> means "press the <kbd class="mod1"> </kbd> key, keep it pressed and then also press the <kbd>x</kbd> key.
-</p>
-
-<p>
- You may also see key combinations such as <kbd class="mod12">e</kbd>, which mean that you should hold down the <kbd class="mod1"> </kbd> key <em>and</em> the <kbd class="mod2"> </kbd> key, and then, while keeping them both down, press the <kbd>e</kbd> key.
-</p>
-
-<p>
- Note that different platforms have different conventions for which modifier key (Control or Command) to use as the primary or most common modifier. When viewing this manual from a machine identifying itself as running OS X, you will see <kbd>Cmd </kbd> where appropriate (for instance in the first example above). On other machines you will see <kbd>Ctrl </kbd> instead.
-</p>
-
-<h3>Mouse Buttons</h3>
-
-<p>
- We refer to <a href="/setting-up-your-system/the-mouse">mouse buttons</a> as <kbd class="mouse">Left</kbd>, <kbd class="mouse">Middle</kbd> and <kbd class="mouse">Right</kbd>. Ardour can use additional buttons, but they have no default behaviour in the program.
-</p>
-
-<h4>Mouse click modifiers</h4>
-
-<p>
- Many editing functions are performed by clicking the mouse while holding a modifier key, for example <kbd class="mouse mod1">Left</kbd>.
-</p>
-
-<h4>Mouse wheel</h4>
-
-<p>
- Some GUI elements can optionally be controlled with the mouse wheel when the pointer is hovering over them. The notation for mouse wheel action is <kbd class="mouse">⇑</kbd> <kbd class="mouse">⇐</kbd> <kbd class="mouse">⇓</kbd> <kbd class="mouse">⇒</kbd>.
-</p>
-
-<h4>Context-click</h4>
-
-<p>
- The term <dfn>context-click</dfn> is used to indicate that you should (typically) <kbd class="mouse">Right</kbd>-click on a particular element of the graphical user interface. Although right-click is the common, default way to do this, there are other ways to accomplish the same thing—this term refers to any of them, and the result is always that a menu specific to the item you clicked on will be displayed.
-</p>
-
-<h4>"The Pointer"</h4>
-
-<p>
- When the manual refers to the "pointer", it means the on-screen representation of the mouse position or the location of a touch action if you are using a touch interface.
-</p>
-
-<h3>Other user input</h3>
-
-<p>
- Ardour supports hardware controllers, such as banks of <kbd class="fader">faders</kbd>, <kbd class="knob">knobs</kbd>, or <kbd class="button">buttons</kbd>.
-</p>
-
-<h3>Menu Items</h3>
-
-<p>
- Menu items are indicated like this:<br />
- <kbd class="menu">Top > Next > Deeper</kbd>.<br />
- Each ">"-separated item indicates one level of a nested (sub-)menu.
-</p>
-
-<h3>Preference/Dialog Options</h3>
-
-<p>
- Choices in various dialogs, notably the Preferences and Properties dialog, are
- indicated like this:<br />
- <kbd class="option">Edit > Preferences > Audio > Some
- Option</kbd>.<br />
- Each successive item indicates either a (sub-) menu or a tabbed dialog
- navigation. The final item is the one to choose or select.
-</p>
-
-<p>
- If you are requested to deselect an option, you will see something like
- this:<br />
- <kbd class="optoff">Edit > Preferences > Audio > Some other
- Option</kbd>.<br />
-</p>
-
-<h3>User Input</h3>
-
-<p>
- Some dialogs or features may require you to type in some <kbd class="input">data such as this</kbd>. In rare cases, you will be required to perform certain operations at the command line of your operating system:
-</p>
-
-<kbd class="cmd lin">cat /proc/cpuinfo</kbd>
-<kbd class="cmd mac">sleep 3600</kbd>
-<kbd class="cmd win">ping www.google.com</kbd>
-
-<h3>Program Output</h3>
-
-<p>
- Important messages from Ardour or other programs will be displayed <samp>like this</samp>.
-</p>
-
-<h3>Notes</h3>
-
-<p class="note">
- Important notes about things that might not otherwise be obvious are shown in this format.
-</p>
-
-<h3>Warnings</h3>
-
-<p class="warning">
- Hairy issues that might cause things to go wrong, lose data, impair sound quality, or eat your proverbial goldfish, are displayed in this way.
-</p>
-
-
---
title: About Ardour's documentation
include: _manual/01_welcome-to-ardour/02_about-ardour-documentation.html
+link: about-ardour-doc
part: subchapter
---
---
title: Stem Exports
-include: _manual/08_working-with-sessions/05_interchange-with-other-daws/03_using-aatranslator.html
+include: _manual/08_working-with-sessions/05_interchange-with-other-daws/02_stem-exports.html
part: subchapter
---
part: chapter
---
+---
+title: Files and Directories Ardour Knows About
+include: _manual/28_appendix/03_files-and-directories.html
+exclude: yes
+part: chapter
+---
+
projects / ardour-manual-diverged / commitdiff
