13
0
livetrax/manual/xml/why_is_it_called_ardour.xml
Tim Mayberry 56e384349b Add the ardour manual converted to docbook format with only a few minor
additions.

Add dbhelper.vim key stroke mappings I use for working with docbook source.

There are no xsl or css files for customizing the html output so it will 
look really boring...this will only be temporary.

Support for content localization and generation of pdf's is planned.



git-svn-id: svn://localhost/ardour2/trunk@1405 d708f5d6-7413-0410-9779-e7cbd77b26cf
2007-02-02 04:29:55 +00:00

208 lines
7.3 KiB
XML

<?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>