1. Do the bugs in the RES module server may cause trouble for others? In this case a high quality, stable and close to bug-free software is requested that might slow down the development.

There is no reason why the RES system should fail if one RES module server have problem running some user’s module. In worst case, specific RES module server is disconnected after specified timeout and no output is returned to the RES client user. At the same time other users can normally use the RES system and perform different tasks simultaneously.

2. Is there a possibility for groups outside the ECESS consortium to use the existing RES server?

ECESS consortium is a non-funded consortium, where partners are gathering and exchange ideas purely because of their research interests and multilingual issues. Anyone can apply to become the member of the ECESS consortium.

3. The groups of existing collaborators are usually willing to exchange the source code. What is the benefit of using the RES system?

RES system and approach within ECESS does not demand any source code or data resources exchange, but offers common specification development, evaluating, testing, comparing different approaches and solutions between partners in flexible ways without laborious and tedious work. All partners have possibility to run via RES up-to-date modules of other partners without problems, doesn’t matter what changes were made in between (since no code exchange is performed). They always have the same situation over the RES. Only the results and information are improving.  Running RES server (main server) is not time consuming and is strictly devoted to common purpose – speed up progress in speech synthesis through flexible and fast testing and evaluating.

4. Is it true in general that any existing TTS module can have its input/output simply re-formatted to fit into the RES framework.? What if a module requires specific information from a preceding module that is not available?

Within RES the TC-STAR data format is used and partner’s input/output data has to comply those specifications before evaluation can be performed. When more complex architectures are evaluated – connecting in one line several TTS processing tasks, there must be compatibility regarding input/output data. But this is no question any more, after compatibility steps are performed.

5. Is the modularity of the RES system well suited to one of the most popular methods of synthesis at the moment - HMM-based synthesis?

There is no problem to include also such systems. In the RES system you can integrate separate modules or even whole TTS systems, using e.g. TD-PSOLA, HMM based or any other method of synthesis. The logic is – you gave input and want some output. Any task that can fulfill this logic can be integrated in the RES. 

6. Is RES offering anything more than toolkits such as Festival, (Open)Mary or BOSS already offer?

RES system is architecture-framework-skeleton. Its functionality and structure is defined by any number of needed modules. Their behavior can be defined by using XML mechanism. One can integrate modules developed on different platforms. One can also give the content and information one would want from the RES system by selecting resources and modules all over the world. Of course, I/O outputs between selected modules have to be compatible. Therefore, TC-STAR data format is used within the RES system. In this approach, any desired or needed granulation of TTS processing tasks can be defined, or any desired or needed logic processing task sequence can be performed.

7. The RES system relies on several servers running at once. If one of them goes down, does the system fail? Would this imply that a lot of maintenance and a fast response to system or network failures, at multiple sites, are required?

There is no reason why the RES system would fail if one RES module server has problem running some user’s module. In worst case, specific RES module server is just disconnected after specified timeout and no output is returned to the RES client user (with error message). At the same time other users can normally use the RES system and perform different tasks simultaneously.

8. Is the effort required to install and maintain a RES 'module server' greater than to download the remaining parts of the system and to run everything locally?

The installation of RES module server and encapsulation of local modules is a matter of minutes, and requires no special prior knowledge..

9. Has the group running the central server a lot of work to maintain the ECESS server and to write all the parsers to convert formats?

That was one of the main concerns before starting developing RES system. Maintaining RES server consists now just to add one line in the modules list, when new module wants to be added to the RES system. Some users can decide to generate also TC-STAR compliant data format, so for them no parsers are needed. For others, of course parsers have to be written. Nevertheless, as far as TTS systems are concerned, proprietary formats are not that complex or difficult to parse in TC-STAR format. Besides, they can be delivered to the users and loaded at run-time as classes (Java feature). So user is not even aware that something was changed (actually there is no change in the RES module server needed at all). This possibility available to the RES system users is especially useful, when for example specifications for some TTS processing task are in development and are also changing.

10. Can text processing module divided in different module granulation (this module typically will involve many, many small tasks, and some research groups may not be able to implement a fully-fledged module) be efficiently encapsulated within the RES and evaluated?

RES system is totally capable to integrate a desired or needed granular processing task that can be defined within TTS systems and even other processing tasks within speech technology field. Therefore, there is no problem at all to further sub-divide e.g. text processing module into e.g. tokenizer, POS tagger, text normalization etc.