<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.52
from ../festival.texi on 2 August 2001 -->
<TITLE>Festival Speech Synthesis System - 6 Installation</TITLE>
</HEAD>
<BODY bgcolor="#ffffff">
Go to the <A HREF="festival_1.html">first</A>, <A HREF="festival_5.html">previous</A>, <A HREF="festival_7.html">next</A>, <A HREF="festival_35.html">last</A> section, <A HREF="festival_toc.html">table of contents</A>.
<P><HR><P>
<H1><A NAME="SEC12" HREF="festival_toc.html#TOC12">6 Installation</A></H1>
<P>
This section describes how to install Festival from source in a new
location and customize that installation.
</P>
<H2><A NAME="SEC13" HREF="festival_toc.html#TOC13">6.1 Requirements</A></H2>
<P>
<A NAME="IDX9"></A>
In order to compile Festival you first need the following
source packages
</P>
<DL COMPACT>
<DT><CODE>festival-1.4.2.tar.gz</CODE>
<DD>
Festival Speech Synthesis System source
<DT><CODE>speech_tools-1.2.2.tar.gz</CODE>
<DD>
The Edinburgh Speech Tools Library
<DT><CODE>festlex_NAME.tar.gz</CODE>
<DD>
<A NAME="IDX10"></A>
The lexicon distribution, where possible, includes the lexicon input
file as well as the compiled form, for your convenience. The lexicons
have varying distribution policies, but are all free except OALD, which
is only free for non-commercial use (we are working on a free
replacement). In some cases only a pointer to an ftp'able file plus a
program to convert that file to the Festival format is included.
<DT><CODE>festvox_NAME.tar.gz</CODE>
<DD>
You'll need a speech database. A number are available (with varying
distribution policies). Each voice may have other dependencies such as
requiring particular lexicons
<DT><CODE>festdoc_1.4.2.tar.gz</CODE>
<DD>
Full postscript, info and html documentation for Festival and the
Speech Tools. The source of the documentation is available
in the standard distributions but for your conveniences it has
been pre-generated.
</DL>
<P>
In addition to Festival specific sources you will also need
</P>
<DL COMPACT>
<DT><EM>A UNIX machine</EM>
<DD>
Currently we have compiled and tested the system under Solaris (2.5(.1),
2.6, 2.7 and 2.8), SunOS (4.1.3), FreeBSD 3.x, 4.x Linux (Redhat 4.1,
5.0, 5.1, 5.2, 6.[012], 7.[01] and other Linux distributions), and it
should work under OSF (Dec Alphas) SGI (Irix), HPs (HPUX). But any
standard UNIX machine should be acceptable. We have now successfully
ported this version to Windows NT nad Windows 95 (using the Cygnus GNU
win32 environment). This is still a young port but seems to work.
<DT><EM>A C++ compiler</EM>
<DD>
<A NAME="IDX11"></A>
<A NAME="IDX12"></A>
<A NAME="IDX13"></A>
Note that C++ is not very portable even between different versions
of the compiler from the same vendor. Although we've tried very
hard to make the system portable, we know it is very unlikely to
compile without change except with compilers that have already been tested.
The currently tested systems are
<UL>
<LI>Sun Sparc Solaris 2.5, 2.5.1, 2.6, 2.7:
GCC 2.7.2, egcs 1.1.1, egcs 1.1.2, GCC 2.95.1
<LI>Sun Sparc SunOS 4.1.3:
GCC 2.7.2
<LI>FreeBSD for Intel 3.x and 4.x
GCC 2.95.1, GCC 3.0
<LI>Linux for Intel (RedHat 4.1/5.0/5.1/5.2/6.0):
GCC 2.7.2, GCC 2.7.2/egcs-1.0.2, egcs 1.1.1, egcs-1.1.2, GCC 2.95.[123],
GCC "2.96", GCC 3.0
<LI>Windows NT 4.0:
GCC 2.7.2 plus egcs (from Cygnus GNU win32 b19), Visual C++ PRO v5.0,
Visual C++ v6.0
</UL>
Note if GCC works on one version of Unix it usually works on
others.
<A NAME="IDX14"></A>
We have compiled both the speech tools and Festival under Windows NT 4.0
and Windows 95 using the GNU tools available from Cygnus.
<PRE>
<A HREF="ftp://ftp.cygnus.com/pub/gnu-win32/">ftp://ftp.cygnus.com/pub/gnu-win32/</A>.
</PRE>
<DT><EM>GNU make</EM>
<DD>
Due to there being too many different <CODE>make</CODE> programs out there
we have tested the system using GNU make on all systems we use.
Others may work but we know GNU make does.
<DT><EM>Audio hardware</EM>
<DD>
<A NAME="IDX15"></A>
You can use Festival without audio output hardware but it doesn't sound
very good (though admittedly you can hear less problems with it). A
number of audio systems are supported (directly inherited from the
audio support in the Edinburgh Speech Tools Library): NCD's NAS
(formerly called netaudio) a network transparent audio system (which can
be found at <A HREF="ftp://ftp.x.org/contrib/audio/nas/">ftp://ftp.x.org/contrib/audio/nas/</A>);
<TT>`/dev/audio'</TT> (at 8k ulaw and 8/16bit linear), found on Suns, Linux
machines and FreeBSD; and a method allowing arbitrary UNIX
commands. See section <A HREF="festival_23.html#SEC96">23 Audio output</A>.
</DL>
<P>
<A NAME="IDX16"></A>
<A NAME="IDX17"></A>
<A NAME="IDX18"></A>
Earlier versions of Festival mistakenly offered a command line editor
interface to the GNU package readline, but due to conflicts with the GNU
Public Licence and Festival's licence this interface was removed in
version 1.3.1. Even Festival's new free licence would cause problems as
readline support would restrict Festival linking with non-free code. A
new command line interface based on editline was provided that offers
similar functionality. Editline remains a compilation option as it is
probably not yet as portable as we would like it to be.
</P>
<P>
<A NAME="IDX19"></A>
In addition to the above, in order to process the documentation you will
need <TT>`TeX'</TT>, <TT>`dvips'</TT> (or similar), GNU's <TT>`makeinfo'</TT> (part
of the texinfo package) and <TT>`texi2html'</TT> which is available from
<A HREF="http://wwwcn.cern.ch/dci/texi2html/">http://wwwcn.cern.ch/dci/texi2html/</A>.
</P>
<P>
<A NAME="IDX20"></A>
However the document files are also available pre-processed into,
postscript, DVI, info and html as part of the distribution in
<TT>`festdoc-1.4.X.tar.gz'</TT>.
</P>
<P>
Ensure you have a fully installed and working version of your C++
compiler. Most of the problems people have had in installing Festival
have been due to incomplete or bad compiler installation. It
might be worth checking if the following program works if you don't
know if anyone has used your C++ installation before.
<PRE>
#include <iostream.h>
int main (int argc, char **argv)
{
cout << "Hello world\n";
}
</PRE>
<P>
Unpack all the source files in a new directory. The directory
will then contain two subdirectories
<PRE>
speech_tools/
festival/
</PRE>
<H2><A NAME="SEC14" HREF="festival_toc.html#TOC14">6.2 Configuration</A></H2>
<P>
First ensure you have a compiled version of the Edinburgh
Speech Tools Library. See <TT>`speech_tools/INSTALL'</TT> for
instructions.
</P>
<P>
<A NAME="IDX21"></A>
The system now supports the standard GNU <TT>`configure'</TT> method
for set up. In most cases this will automatically configure festival
for your particular system. In most cases you need only
type
<PRE>
gmake
</PRE>
<P>
and the system will configure itself and conpile, (note you
need to have compiled the Edinburgh Speech Tools
<TT>`speech_tools-1.2.2'</TT> first.
</P>
<P>
<A NAME="IDX22"></A>
In some case hand configure is require. All of the configuration
choise are held in the file <TT>`config/config'</TT>
</P>
<P>
<A NAME="IDX23"></A>
For the most part Festival configuration inherits the configuration from
your speech tools config file (<TT>`../speech_tools/config/config'</TT>).
Additional optional modules may be added by adding them to the end of
your config file e.g.
<PRE>
ALSO_INCLUDE += clunits
</PRE>
<P>
Adding and new module here will treat is as a new directory in
the <TT>`src/modules/'</TT> and compile it into the system in the
same way the <CODE>OTHER_DIRS</CODE> feature was used in
previous versions.
</P>
<P>
<A NAME="IDX24"></A>
<A NAME="IDX25"></A>
If the compilation directory being accessed by NFS or if you use an
automounter (e.g. amd) it is recommend to explicitly set the variable
<CODE>FESTIVAL_HOME</CODE> in <TT>`config/config'</TT>. The command <CODE>pwd</CODE> is
not reliable when a directory may have multiple names.
</P>
<P>
There is a simple test suite with Festival but it requires the three
basic voices and their respective lexicons install before it will work.
Thus you need to install
<PRE>
festlex_CMU.tar.gz
festlex_OALD.tar.gz
festlex_POSLEX.tar.gz
festvox_don.tar.gz
festvox_kedlpc16k.tar.gz
festvox_rablpc16k.tar.gz
</PRE>
<P>
If these are installed you can test the installation with
<PRE>
gmake test
</PRE>
<P>
To simply make it run with a male US Ebglish voiuce it is
sufficient to install just
<PRE>
festlex_CMU.tar.gz
festlex_POSLEX.tar.gz
festvox_kallpc16k.tar.gz
</PRE>
<P>
Note that the single most common reason for problems in compilation and
linking found amongst the beta testers was a bad installation of GNU
C++. If you get many strange errors in G++ library header files or link
errors it is worth checking that your system has the compiler, header
files and runtime libraries properly installed. This may be checked by
compiling a simple program under C++ and also finding out if anyone at
your site has ever used the installation. Most of these installation
problems are caused by upgrading to a newer version of libg++ without
removing the older version so a mixed version of the <TT>`.h'</TT> files
exist.
</P>
<P>
Although we have tried very hard to ensure that Festival compiles with
no warnings this is not possible under some systems.
</P>
<P>
<A NAME="IDX26"></A>
Under SunOS the system include files do not declare a number of
system provided functions. This a bug in Sun's include files. This
will causes warnings like "implicit definition of fprintf". These
are harmless.
</P>
<P>
<A NAME="IDX27"></A>
Under Linux a warning at link time about reducing the size of some
symbols often is produced. This is harmless. There is often
occasional warnings about some socket system function having an
incorrect argument type, this is also harmless.
</P>
<P>
<A NAME="IDX28"></A>
The speech tools and festival compile under Windows95 or Windows NT
with Visual C++ v5.0 using the Microsoft <TT>`nmake'</TT> make program. We've
only done this with the Professonal edition, but have no reason to
believe that it relies on anything not in the standard edition.
</P>
<P>
In accordance to VC++ conventions, object files are created with extension
.obj, executables with extension .exe and libraries with extension
.lib. This may mean that both unix and Win32 versions can be built in
the same directory tree, but I wouldn't rely on it.
</P>
<P>
To do this you require nmake Makefiles for the system. These can be
generated from the gnumake Makefiles, using the command
<PRE>
gnumake VCMakefile
</PRE>
<P>
in the speech_tools and festival directories. I have only done this
under unix, it's possible it would work under the cygnus gnuwin32
system.
</P>
<P>
If <TT>`make.depend'</TT> files exist (i.e. if you have done <TT>`gnumake
depend'</TT> in unix) equivalent <TT>`vc_make.depend'</TT> files will be created, if not
the VCMakefiles will not contain dependency information for the <TT>`.cc'</TT>
files. The result will be that you can compile the system once, but
changes will not cause the correct things to be rebuilt.
</P>
<P>
In order to compile from the DOS command line using Visual C++ you
need to have a collection of environment variables set. In Windows NT
there is an instalation option for Visual C++ which sets these
globally. Under Windows95 or if you don't ask for them to be set
globally under NT you need to run
<PRE>
vcvars32.bat
</PRE>
<P>
See the VC++ documentation for more details.
</P>
<P>
Once you have the source trees with VCMakefiles somewhere visible from
Windows, you need to copy
<TT>`peech_tools\config\vc_config-dist'</TT> to
<TT>`speech_tools\config\vc_config'</TT> and edit it to suit your
local situation. Then do the same with
<TT>`festival\config\vc_config-dist'</TT>.
</P>
<P>
The thing most likely to need changing is the definition of
<CODE>FESTIVAL_HOME</CODE> in <TT>`festival\config\vc_config_make_rules'</TT>
which needs to point to where you have put festival.
</P>
<P>
Now you can compile. cd to the speech_tools directory and do
<PRE>
nmake /nologo /fVCMakefile
</PRE>
<P>
and the library, the programs in main and the test programs should be
compiled.
</P>
<P>
The tests can't be run automatically under Windows. A simple test to
check that things are probably OK is:
<PRE>
main\na_play testsuite\data\ch_wave.wav
</PRE>
<P>
which reads and plays a waveform.
</P>
<P>
Next go into the festival directory and do
<PRE>
nmake /nologo /fVCMakefile
</PRE>
<P>
to build festival. When it's finished, and assuming you have the
voices and lexicons unpacked in the right place, festival should run
just as under unix.
</P>
<P>
We should remind you that the NT/95 ports are still young and there may
yet be problems that we've not found yet. We only recommend the use the
speech tools and Festival under Windows if you have significant
experience in C++ under those platforms.
</P>
<P>
<A NAME="IDX29"></A>
<A NAME="IDX30"></A>
Most of the modules <TT>`src/modules'</TT> are actually optional and the
system could be compiled without them. The basic set could be reduced
further if certain facilities are not desired. Particularly:
<TT>`donovan'</TT> which is only required if the donovan voice is used;
<TT>`rxp'</TT> if no XML parsing is required (e.g. Sable); and <TT>`parser'</TT>
if no stochastic paring is required (this parser isn't used for any of
our currently released voices). Actually even <TT>`UniSyn'</TT> and
<TT>`UniSyn_diphone'</TT> could be removed if some external waveform
synthesizer is being used (e.g. MBROLA) or some alternative one like
<TT>`OGIresLPC'</TT>. Removing unused modules will make the festival binary
smaller and (potentially) start up faster but don't expect too much.
You can delete these by changing the <CODE>BASE_DIRS</CODE> variable in
<TT>`src/modules/Makefile'</TT>.
</P>
<H2><A NAME="SEC15" HREF="festival_toc.html#TOC15">6.3 Site initialization</A></H2>
<P>
<A NAME="IDX31"></A>
<A NAME="IDX32"></A>
<A NAME="IDX33"></A>
<A NAME="IDX34"></A>
<A NAME="IDX35"></A>
Once compiled Festival may be further customized for particular sites.
At start up time Festival loads the file <TT>`init.scm'</TT> from its
library directory. This file further loads other necessary files such
as phoneset descriptions, duration parameters, intonation parameters,
definitions of voices etc. It will also load the files
<TT>`sitevars.scm'</TT> and <TT>`siteinit.scm'</TT> if they exist.
<TT>`sitevars.scm'</TT> is loaded after the basic Scheme library functions
are loaded but before any of the festival related functions are
loaded. This file is intended to set various path names before
various subsystems are loaded. Typically variables such
as <CODE>lexdir</CODE> (the directory where the lexicons are held), and
<CODE>voices_dir</CODE> (pointing to voice directories) should
be reset here if necessary.
</P>
<P>
<A NAME="IDX36"></A>
<A NAME="IDX37"></A>
<A NAME="IDX38"></A>
The default installation will try to find its lexicons and voices
automatically based on the value of <CODE>load-path</CODE> (this is derived
from <CODE>FESTIVAL_HOME</CODE> at compilation time or by using the <CODE>--libdir</CODE>
at run-time). If the voices and lexicons have been unpacked into
subdirectories of the library directory (the default) then no site
specific initialization of the above pathnames will be necessary.
</P>
<P>
The second site specific file is <TT>`siteinit.scm'</TT>. Typical examples
of local initialization are as follows. The default audio output method
is NCD's NAS system if that is supported as that's what we use normally
in CSTR. If it is not supported, any hardware specific mode is the
default (e.g. sun16audio, freebas16audio, linux16audio or mplayeraudio).
But that default is just a setting in <TT>`init.scm'</TT>. If for example
in your environment you may wish the default audio output method to be
8k mulaw through <TT>`/dev/audio'</TT> you should add the following line to
your <TT>`siteinit.scm'</TT> file
<PRE>
(Parameter.set 'Audio_Method 'sunaudio)
</PRE>
<P>
Note the use of <CODE>Parameter.set</CODE> rather than <CODE>Parameter.def</CODE>
the second function will not reset the value if it is already set.
Remember that you may use the audio methods <CODE>sun16audio</CODE>.
<CODE>linux16audio</CODE> or <CODE>freebsd16audio</CODE> only if <CODE>NATIVE_AUDIO</CODE>
was selected in <TT>`speech_tools/config/config'</TT> and your are
on such machines. The Festival variable <CODE>*modules*</CODE> contains
a list of all supported functions/modules in a particular installation
including audio support. Check the value of that variable if things
aren't what you expect.
</P>
<P>
If you are installing on a machine whose audio is not directly supported
by the speech tools library, an external command may be executed to play
a waveform. The following example is for an imaginary machine that can
play audio files through a program called <TT>`adplay'</TT> with arguments
for sample rate and file type. When playing waveforms, Festival, by
default, outputs as unheadered waveform in native byte order. In this
example you would set up the default audio playing mechanism in
<TT>`siteinit.scm'</TT> as follows
<PRE>
(Parameter.set 'Audio_Method 'Audio_Command)
(Parameter.set 'Audio_Command "adplay -raw -r $SR $FILE")
</PRE>
<P>
<A NAME="IDX39"></A>
<A NAME="IDX40"></A>
<A NAME="IDX41"></A>
<A NAME="IDX42"></A>
<A NAME="IDX43"></A>
For <CODE>Audio_Command</CODE> method of playing waveforms Festival supports
two additional audio parameters. <CODE>Audio_Required_Rate</CODE> allows you
to use Festivals internal sample rate conversion function to any desired
rate. Note this may not be as good as playing the waveform at the
sample rate it is originally created in, but as some hardware devices
are restrictive in what sample rates they support, or have naive
resample functions this could be optimal. The second addition
audio parameter is <CODE>Audio_Required_Format</CODE> which can be
used to specify the desired output forms of the file. The default
is unheadered raw, but this may be any of the values supported by
the speech tools (including nist, esps, snd, riff, aiff, audlab, raw
and, if you really want it, ascii).
</P>
<P>
For example suppose you run Festival on a remote machine and are not
running any network audio system and want Festival to copy files back to
your local machine and simply cat them to <TT>`/dev/audio'</TT>. The
following would do that (assuming permissions for rsh are allowed).
<PRE>
(Parameter.set 'Audio_Method 'Audio_Command)
;; Make output file ulaw 8k (format ulaw implies 8k)
(Parameter.set 'Audio_Required_Format 'ulaw)
(Parameter.set 'Audio_Command
"userhost=`echo $DISPLAY | sed 's/:.*$//'`; rcp $FILE $userhost:$FILE; \
rsh $userhost \"cat $FILE >/dev/audio\" ; rsh $userhost \"rm $FILE\"")
</PRE>
<P>
Note there are limits on how complex a command you want to put in the
<CODE>Audio_Command</CODE> string directly. It can get very confusing with respect
to quoting. It is therefore recommended that once you get past a certain
complexity consider writing a simple shell script and calling it from
the <CODE>Audio_Command</CODE> string.
</P>
<P>
<A NAME="IDX44"></A>
A second typical customization is setting the default speaker. Speakers
depend on many things but due to various licence (and resource)
restrictions you may only have some diphone/nphone databases available
in your installation. The function name that is the value of
<CODE>voice_default</CODE> is called immediately after <TT>`siteinit.scm'</TT> is
loaded offering the opportunity for you to change it. In
the standard distribution no change should be required. If you
download all the distributed voices <CODE>voice_rab_diphone</CODE> is
the default voice. You may change this for a site by adding
the following to <TT>`siteinit.scm'</TT> or per person by changing
your <TT>`.festivalrc'</TT>. For example if you wish to
change the default voice to the American one <CODE>voice_ked_diphone</CODE>
<PRE>
(set! voice_default 'voice_ked_diphone)
</PRE>
<P>
Note the single quote, and note that unlike in early versions
<CODE>voice_default</CODE> is not a function you can call directly.
</P>
<P>
<A NAME="IDX45"></A>
<A NAME="IDX46"></A>
A second level of customization is on a per user basis. After loading
<TT>`init.scm'</TT>, which includes <TT>`sitevars.scm'</TT> and
<TT>`siteinit.scm'</TT> for local installation, Festival loads the file
<TT>`.festivalrc'</TT> from the user's home directory (if it exists). This
file may contain arbitrary Festival commands.
</P>
<H2><A NAME="SEC16" HREF="festival_toc.html#TOC16">6.4 Checking an installation</A></H2>
<P>
Once compiled and site initialization is set up you should test
to see if Festival can speak or not.
</P>
<P>
Start the system
<PRE>
$ bin/festival
Festival Speech Synthesis System 1.4.2:release July 2001
Copyright (C) University of Edinburgh, 1996-2001. All rights reserved.
For details type `(festival_warranty)'
festival> ^D
</PRE>
<P>
If errors occur at this stage they are most likely to do
with pathname problems. If any error messages are printed
about non-existent files check that those pathnames
point to where you intended them to be. Most of the (default)
pathnames are dependent on the basic library path. Ensure that
is correct. To find out what it has been set to, start the
system without loading the init files.
<PRE>
$ bin/festival -q
Festival Speech Synthesis System 1.4.2:release July 2001
Copyright (C) University of Edinburgh, 1996-2001. All rights reserved.
For details type `(festival_warranty)'
festival> libdir
"/projects/festival/lib/"
festival> ^D
</PRE>
<P>
This should show the pathname you set in your <TT>`config/config'</TT>.
</P>
<P>
If the system starts with no errors try to synthesize something
<PRE>
festival> (SayText "hello world")
</PRE>
<P>
Some files are only accessed at synthesis time so this may
show up other problem pathnames. If it talks, you're in business,
if it doesn't, here are some possible problems.
</P>
<P>
<A NAME="IDX47"></A>
If you get the error message
<PRE>
Can't access NAS server
</PRE>
<P>
You have selected NAS as the audio output but have no server running on
that machine or your <CODE>DISPLAY</CODE> or <CODE>AUDIOSERVER</CODE> environment
variable is not set properly for your output device. Either set these
properly or change the audio output device in <TT>`lib/siteinit.scm'</TT> as
described above.
</P>
<P>
Ensure your audio device actually works the way you think it does. On
Suns, the audio output device can be switched into a number of different
output modes, speaker, jack, headphones. If this is set to the wrong
one you may not hear the output. Use one of Sun's tools to change this
(try <TT>`/usr/demo/SOUND/bin/soundtool'</TT>). Try to find an audio
file independent of Festival and get it to play on your audio.
Once you have done that ensure that the audio output method set in
Festival matches that.
</P>
<P>
Once you have got it talking, test the audio spooling device.
<PRE>
festival> (intro)
</PRE>
<P>
This plays a short introduction of two sentences, spooling the audio
output.
</P>
<P>
Finally exit from Festival (by end of file or <CODE>(quit)</CODE>) and test
the script mode with.
<PRE>
$ examples/saytime
</PRE>
<P>
A test suite is included with Festival but it makes certain assumptions
about which voices are installed. It assumes that
<CODE>voice_rab_diphone</CODE> (<TT>`festvox_rabxxxx.tar.gz'</TT>) is the default
voice and that <CODE>voice_ked_diphone</CODE> and <CODE>voice_don_diphone</CODE>
(<TT>`festvox_kedxxxx.tar.gz'</TT> and <TT>`festvox_don.tar.gz'</TT>) are
installed. Also local settings in your <TT>`festival/lib/siteinit.scm'</TT>
may affect these tests. However, after installation it may
be worth trying
<PRE>
gnumake test
</PRE>
<P>
from the <TT>`festival/'</TT> directory. This will do various tests
including basic utterance tests and tokenization tests. It also checks
that voices are installed and that they don't interfere with each other.
These tests are primarily regression tests for the developers of
Festival, to ensure new enhancements don't mess up existing supported
features. They are not designed to test an installation is successful,
though if they run correctly it is most probable the installation has
worked.
</P>
<H2><A NAME="SEC17" HREF="festival_toc.html#TOC17">6.5 Y2K</A></H2>
<P>
<A NAME="IDX48"></A>
Festival comes with <EM>no</EM> warranty therefore we will not make
any legal statement about the performance of the system. However a
number of people have ask about Festival and Y2K compliance, and
we have decided to make some comments on this.
</P>
<P>
Every effort has been made to ensure that Festival will continue running
as before into the next millenium. However even if Festival itself has
no problems it is dependent on the operating system environment it is
running in. During compilation dates on files are important and
the compilation process may not work if your machine cannot assign
(reasonable) dates to new files. At run time there is less
dependence on system dates and times. Specifically times
are used in generation of random numbers (where only relative time
is important) and as time stamps in log files when festival
runs in server mode, thus we feel it is unlikely there will
be any problems.
</P>
<P>
However, as a speech synthesizer, Festival must make explicit decisions
about the pronunciation of dates in the next two decades when people
themselves have not yet made such decisions. Most people are still
unsure how to read years written as '01, '04, '12, 00s, 10s, (cf. '86,
90s). It is interesting to note that while there is a convenient short
name for the last decade of the twentieth century, the "ninties" there
is no equivalent name for the first decade of the twenty-first century
(or the second). In the mean time we have made reasonable decisions
about such pronunciations.
</P>
<P>
Once people have themselves become Y2K compliant and decided what to
actually call these years, if their choices are different from how
Festival pronounces them we reserve the right to change how Festival
speaks these dates to match their belated decisions. However as we do
not give out warranties about compliance we will not be requiring our
users to return signed Y2K compliant warranties about their own
compliance either.
</P>
<P><HR><P>
Go to the <A HREF="festival_1.html">first</A>, <A HREF="festival_5.html">previous</A>, <A HREF="festival_7.html">next</A>, <A HREF="festival_35.html">last</A> section, <A HREF="festival_toc.html">table of contents</A>.
</BODY>
</HTML>
