Go to the first, previous, next, last section, table of contents.

6 Structure

The flite distribution consists of two distinct parts:

6.1 cst_val

This is a basic simple object which can contain ints, floats, strings and other objects. It also allows for lists using the Scheme/Lisp, car/cdr architecture (as that is the most efficient way to represent arbitrary trees and lists).

The cst_val structure is carefully designed to take up only 8 bytes (or 16 on a 64-bit machine). The multiple union structure that it can contain is designed so there are no conflicts. However it depends on the fact that a pointer to a cst_val is guaranteed to lie on a even address boundary (which is true for all architectures I know of). Thus the distinction between between cons (i.e. list) objects and atomic values can be determined by the odd/evenness of the least significant bits of the first address in a cst_val. In some circles this is considered hacky, in others elegant. This was done in flite to ensure that the most common structure is 8 bytes rather than 12 which saves significantly on memory.

All cst_val's except those of type cons are reference counted. A few functions generate new lists of cst_val's which the user should be careful about as they need to explicitly delete them (notably the lexicon lookup function that returns a list of phonemes). Everything that is added to an utterance will be deleted (and/or dereferenced) when the utterance is deleted.

Like Festival, user types can be added to the cst_vals. In Festival this can be done on the fly but because this requires the updating of some list when each new type is added, this wouldn't be thread safe. Thus an explicit method of defining user types is done in `src/utils/cst_val_user.c'. This is not as neat as defining on the fly or using a registration function but it is thread safe and these user types wont changes often.

Go to the first, previous, next, last section, table of contents.