summaryrefslogtreecommitdiff
path: root/manual/xml/why_is_it_called_ardour.xml
diff options
context:
space:
mode:
Diffstat (limited to 'manual/xml/why_is_it_called_ardour.xml')
-rw-r--r--manual/xml/why_is_it_called_ardour.xml207
1 files changed, 207 insertions, 0 deletions
diff --git a/manual/xml/why_is_it_called_ardour.xml b/manual/xml/why_is_it_called_ardour.xml
new file mode 100644
index 0000000000..c4b56f2819
--- /dev/null
+++ b/manual/xml/why_is_it_called_ardour.xml
@@ -0,0 +1,207 @@
+<?xml version="1.0" standalone="no"?>
+
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+
+]>
+
+<section id="sn-why-is-it-called-ardour">
+ <title>Why is it called "Ardour" and other questions</title>
+ <section id="why-ardour">
+ <title>Why "Ardour" ?</title>
+ <para>
+ The name "Ardour" came from considerations of how to pronounce the acronym
+ <glossterm linkend="gt-hdr">HDR</glossterm> (Hard Disk Recorder). The most obvious attempt sounds like a
+ vowelless "harder" and it then was then a short step to an unrelated by
+ slightly homophonic word:
+ </para>
+
+ <para>
+ <emphasis>ardour</emphasis>
+ <quote>
+ n 1: a feeling of strong eagerness (usually in favor of a person or
+ cause); "they were imbued with a revolutionary ardor"; "he felt a kind of
+ religious zeal" [syn: ardor, elan, zeal] 2: intense feeling of love [syn:
+ ardor] 3: feelings of great warmth and intensity; "he spoke with great
+ ardor" [syn: ardor, fervor, fervour, fervency, fire, fervidness]
+ </quote>
+ </para>
+
+ <para>
+ Given the work required to develop Ardour, and the personality of its
+ primary author, the name seemed appropriate even without the vague
+ relationship to <glossterm linkend="gt-hdr">HDR</glossterm> .
+ </para>
+
+ <para>
+ Years later, another interpretation of "Ardour" appeared, this time based
+ on listening to non-native English speakers attempt to pronounce the word.
+ Rather than "Ardour", it became "Our DAW", which seemed poetically fitting
+ for a <glossterm linkend="gt-daw">Digital Audio Workstation</glossterm> whose source code and design belongs to a
+ group of collaborators.
+ </para>
+ </section>
+
+ <section id="why-write-another-daw">
+ <title>Why write another DAW?</title>
+ <para>
+ There are already a number of excellent digital audio workstations. To
+ mention just a few: ProTools, Nuendo, Samplitude, Digital Performer, Logic,
+ Cubase (SX), Sonar, along with several less well known systems such as
+ SADIE, SAWStudio and others. Each of these programs has its strengths and
+ weaknesses, although over the last few years most of them have converged on
+ a very similar set of core features. However, each of them suffers from two
+ problems when seen from the perspective of Ardour's development group:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ they do not run on Linux
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ they are not available in source code form, making modifications,
+ improvements, bugfixes by technically inclined users or their friends or
+ consultants impossible.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </section>
+
+ <section id="why-linux-and-osx">
+ <title>Why Linux (and OS X) ?</title>
+ <para>
+ Not running on Linux is understandable, given the rather small (but
+ growing) share of the desktop market that Linux has. However, when
+ surveying the landscape of "popular operating systems", we find:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ older versions of Windows: plagued by abysmal stability and appalling
+ security
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Windows XP: finally, a version of Windows that seems stable but still
+ suffers from incredible security problems
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ OS X: an amazing piece of engineering that is excellent for audio work
+ but only runs on proprietary hardware and still lacks the flexibility and
+ adaptability of Linux.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ Security matters today, and will matter more in the future as more and more
+ live or semi-live network based collaborations take place.
+ </para>
+
+ <para>
+ Let's contrast this with Linux, an operating system which:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ can stay up for months (or even years) without issues
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ is endlessly configurable down to the tiniest detail
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ is not owned by any single corporate entity, ensuring its life and
+ direction are not intertwined with that of a company (for a contrary
+ example, consider BeOS)
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ is fast and efficient
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ runs on almost any computing platform ever created, including old "slow"
+ systems
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ is one of the most secure operating systems "out of the box"
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ More than anything, however, Ardour's primary author uses Linux and wanted
+ a DAW that ran there.
+ </para>
+
+ <para>
+ Having written a DAW for Linux, it turned out to be relatively easy to port
+ Ardour to OS X, mostly because of the excellent work done by the JACK OS X
+ group that ported JACK to OS X. Although OS X has a number of disadvantages
+ compared to Linux, its ease of use and its presence in many studios already
+ makes it a worthwhile platform.
+ </para>
+ </section>
+
+ <section id="why-doesnt-ardour-run-on-windows">
+ <title>Why doesn't Ardour run on Windows ?</title>
+ <para>
+ There have been several discussions about porting Ardour to Windows. The
+ obstacles are relatively few in number, but rather substantial in
+ significance. Ardour was written to run on operating systems that properly
+ and efficiently support a portable operating system standard called <glossterm linkend="gt-posix">POSIX</glossterm>
+ (endorsed by the US government and many other large organizations). Linux
+ and OS X both do a good job of supporting POSIX, but Windows does not. In
+ particular, the efficiency with which Windows handles certain aspects of
+ the POSIX standard makes it very hard to port Ardour to that platform. It
+ is not impossible that we will port Ardour at some point, but Windows
+ continues to be a rather unsuitable platform for pro-audio work despite the
+ improvements that have been made to it in the last few years.
+ </para>
+ </section>
+
+ <section id="need-dsp-hardware">
+ <title>Don't I need DSP hardware to run a good DAW?</title>
+ <para>
+ Please see XXX
+ for a discussion of the merits of dedicated DSP hardware.
+ </para>
+ </section>
+
+ <section id="ardour-is-complicated">
+ <title>Isn't this a really complicated program?</title>
+ <para>
+ There is no point in pretending that Ardour is a simple, easy to use
+ program. The development group has worked hard to try to make simple things
+ reasonably easy, common tasks quick, and hard and/or uncommon things
+ possible. There is no doubt that we have more to do in this area, as well
+ as polishing the user interface to improve its intuitiveness and work flow
+ characteristics. At the same time, multi-track, multi-channel, non-linear,
+ non-destructive audio editing is a far from simple process. Doing it right
+ requires not only a good ear, but a solid appreciation for basic audio
+ concepts and a robust mental model/metaphor of what you are doing. Ardour
+ is not a simple "audio recorder" - you can certainly use it to record
+ stereo (or even mono) material in a single track, but the program has been
+ designed around much richer capabilities than this.
+ </para>
+ </section>
+<!--
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="Some_Subsection.xml" />
+ -->
+</section>