You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
47 lines
2.8 KiB
47 lines
2.8 KiB
Implementation
|
|
|
|
At a more detailed level, the analysis and synthesis phases of the MITalk sys-
|
|
tem have been broken into a set of modules with well-defined interfaces at their
|
|
boundaries. In this way, it is possible to break up the overall transformation
|
|
process into well-specified but smaller transformations which serve to reduce the
|
|
overall complexity of the system, and to provide the means for focusing on dif-
|
|
ferent aspects and different representations within the system. Since the system 1s
|
|
oriented to pass information forward from module to module, using temporary data
|
|
bases as well, it is possible to have well-formed boundaries and to test and evaluate
|
|
each module on a module-by-module basis. This is an important consideration
|
|
since quality measures can be assigned to each module, and local optimization of
|
|
the modules can be expected to incrementally contribute to the overall quality of
|
|
the output synthetic speech. Of course, the degree to which various refinements
|
|
within the modules increase measures of intelligibility and naturalness at the out-
|
|
put will vary substantially, but there is little need to consider the detailed way in
|
|
which the results of several modules are integrated when one is working on im-
|
|
provements for a particular module. In this way, it has been possible to develop the
|
|
individual modules of the system in parallel, while providing an overall system
|
|
framework that permits separate module development. By keeping the interfaces
|
|
and data base formats carefully specified, it is possible to pinpoint deficiencies in
|
|
the system at various levels, and in this way to provide guidance for the allocation
|
|
of research effort to the various parts of the system. In retrospect, this modular
|
|
approach to the overall representation and development of the system has served
|
|
very well, and continues to be the major framework in which further improvements
|
|
|
|
are being made.
|
|
|
|
14.2 Development system
|
|
|
|
Given the rapid improvements in both software and hardware technology, it is not
|
|
very useful to describe in detail the earlier development environments which are
|
|
relevant to the 1960s and the 1970s. But it is useful to have an idea of the evolu-
|
|
tion of the computational research framework. Initially, a small single-user mini-
|
|
computer was used with an analog hardware synthesizer. While some code was
|
|
written in assembly language as the work evolved, particularly with the introduc-
|
|
tion of the modular organization, most of the symbolic computing was done in a
|
|
variant of the BCPL language, while the phonemic synthesis was done in
|
|
FORTRAN. During the 1970s, a large time-shared machine was introduced with a
|
|
|
|
special purpose hardware vocal tract model (Miranker, 1978). This system was
|
|
exceedingly useful since it provided the framework for several researchers to ef-
|
|
|
|
fectively collaborate and to share information in an ongoing, highly interactive
|
|
|
|
173
|