### 24.3 Defining a new voice ¶

As there are a number of voices available for Festival and they may or may not exists in different installations we have tried to make it as simple as possible to add new voices to the system without having to change any of the basic distribution. In fact if the voices use the following standard method for describing themselves it is merely a matter of unpacking them in order for them to be used by the system.

The variable `voice-path` conatins a list of directories where voices will be automatically searched for. If this is not set it is set automatically by appending `/voices/` to all paths in festival `load-path`. You may add new directories explicitly to this variable in your `/etc/festival.scm` file or your own `.festivalrc` as you wish.

Each voice directory is assumed to be of the form

    LANGUAGE/VOICENAME/

Within the `VOICENAME/` directory itself it is assumed there is a file `festvox/VOICENAME.scm` which when loaded will define the voice itself. The actual voice function should be called `voice_VOICENAME`.

For example the voices distributed with the standard Festival distribution all unpack in `festival/lib/voices`. The Amercan voice `ked_diphone` unpacks into

    festival/lib/voices/english/ked_diphone/

Its actual definition file is in

    festival/lib/voices/english/ked_diphone/festvox/ked_diphone.scm

Note the name of the directory and the name of the Scheme definition file must be the same.

Alternative voices using perhaps a different encoding of the database but the same front end may be defined in the same way by using symbolic links in the langauge directoriy to the main directory. For example a PSOLA version of the ked voice may be defined in

    festival/lib/voices/english/ked_diphone/festvox/ked_psola.scm

Adding a symbole link in `festival/lib/voices/english/` ro `ked_diphone` called `ked_psola` will allow that voice to be automatically registered when Festival starts up.

Note that this method doesn’t actually load the voices it finds, that could be prohibitively time consuming to the start up process. It blindly assumes that there is a file `VOICENAME/festvox/VOICENAME.scm` to load. An autoload definition is given for `voice_VOICENAME` which when called will load that file and call the real definition if it exists in the file.

This is only a recommended method to make adding new voices easier, it may be ignored if you wish. However we still recommend that even if you use your own convetions for adding new voices you consider the autoload function to define them in, for example, the `/etc/festival.scm` file or `.festivalrc`. The autoload function takes three arguments: a function name, a file containing the actual definiton and a comment. For example a definition of voice can be done explicitly by

    (autooad voice_f2b  "/home/awb/data/f2b/ducs/f2b_ducs"
         "American English female f2b")))

Of course you can also load the definition file explicitly if you wish.

In order to allow the system to start making intellegent use of voices we recommend that all voice definitions include a call to the function `voice_proclaim` this allows the system to know some properties about the voice such as language, gender and dialect. The `proclaim_voice` function taks two arguments a name (e.g. `rab_diphone` and an assoc list of features and names. Currently we require `language`, `gender`, `dialect` and `description`. The last being a textual description of the voice itself. An example proclaimation is

    (proclaim_voice
     'rab_diphone
     '((language english)
       (gender male)
       (dialect british)
       (description
        "This voice provides a British RP English male voice using a
         residual excited LPC diphone synthesis method.  It uses a
         modified Oxford Advanced Learners' Dictionary for pronunciations.
         Prosodic phrasing is provided by a statistically trained model
         using part of speech and local distribution of breaks.  Intonation
         is provided by a CART tree predicting ToBI accents and an F0
         contour generated from a model trained from natural speech.  The
         duration model is also trained from data using a CART tree.")))

There are functions to access a description. `voice.description` will return the description for a given voice and will load that voice if it is not already loaded. `voice.describe` will describe the given given voice by synthesizing the textual description using the current voice. It would be nice to use the voice itself to give a self introduction but unfortunately that introduces of problem of decide which language the description should be in, we are not all as fluent in welsh as we’d like to be.

The function `voice.list` will list the potential voices in the system. These are the names of voices which have been found in the `voice-path`. As they have not actaully been loaded they can’t actually be confirmed as usable voices. One solution to this would be to load all voices at start up time which would allow confirmation they exist and to get their full description through `proclaim_voice`. But start up is already too slow in festival so we have to accept this stat for the time being. Splitting the description of the voice from the actual definition is a possible solution to this problem but we have not yet looked in to this.