ATTENTION: This library is currently pre-release!
I found the interesting project Festival. It stands out as a modular kit for innovating with voice synthesis, and the default implementations have very nice vocalization compared to competitors like espeak-ng. NB. Festival takes much longer to vocalize text than espeak-ng. With this in mind, I decided to bind a sensible portion of the c++ bindings from festival.h for Haskell, so we can enjoy high quality text to speech and wave.
- Provide access to the main tts and ttw functions of festival for Haskell.
- All foreign memory shall be wrapped with `ForeignPtr`, such that no foreign memory will leak from using this library. CAVEAT: If someone runs the cleanup routine some foreign memory might be invalidated.
- Produce a small, easily comprehensible, and unsafe API. There are many ways to handle initialization and finalization of impure resources in haskell applications. I plan on creating at least one higher level library to utilize festival as a pluggable backend. I want to encroach on abstraction and driver code for users of festival as little as possible, therefore the scope of this library shall remain narrow.
- Provide some tests AND examples. We will have some tests that rely on DeepSpeak by mozilla. It works quickly, and it is based on solid research. Find it on github. I installed the binary version from the AUR, because I really wanted to avoid the gnarly java dependencies (plus more stuff in the AUR). That is a pain point, but these tests will be isolated in their own suite. If anyone knows an stt engine with a smaller build time dependency footprint feel free to suggest it, but it needs to understand our computer speech consistently.
- Keep festival from using its async engine. Their docs reference needing to wait on the async runtime after a specific procedure. Every such procedure shall not be bound by this library.
- Using the festival framework. For messing with models I think everyone is better off using the c++ project directly. I don’t plan on digging far into their implementation. It is out of my domain, and from my experience making this small library I think it would be a horrible time trying to their object oriented modularity through haskell bindings. Alternatively you could probably use the SIOD lisp embedded in festival (which this library doesn’t expose).
- Providing easy abstractions for haskell clients out of the box. These bindings, as stated above, should be as small and simple as is reasonable to provide most of the tts and ttw functionality of festival. Further abstractions will be too opinionated, so it is left to client code.