[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The flite distribution consists of two distinct parts:
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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_val
s. 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 won’t change often.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |