From: Tim S. <tp...@ma...> - 2006-07-14 21:19:38
|
On Fri, July 14, 2006 14:48, Matthew Williams said: > Ok, I've taken a look and to my eyes there are two problems. The first is > that there is no way to specify a default voice for many of the engines. > I've correct that problem in rev 775. There is a new parameter > "voice_text_default_voice". Cool. > Now, the second problem is strange. It think that there is a flaw in > Voice_Text.pm that has been there since Dec 2002. It seems that the code > that reads in the voice_names parameter is broken. I would appreciate > other > people's opinion here before I change it. > > In Voice_Text::read_parms, %voice_names is loaded with the requested > translations. I.e. 'male' will be transformed to 'Cepstral Frank'. But > then the next line reverses the hash. In other words, 'Cepstral Frank' > will > be transformed into 'male'. I do not see the purpose of the reverse, > except > to break the code. :) That's where I gave up trying to weed out the problem. > If you look at Voice_Text::read_parms, you can see that %voice_names is > used > to transform the requested voice into the parameter needed by the various > engines. In other words, the intent is for a voice parameter of 'male' to > be transformed into a voice parameter of 'Cepstral Frank'. See line 168 > for > an example of how this is done. Right. > I only have one voice available, so I can't test my theory. Does the > voice > selection stuff work for anyone right now? Am I missing something here. > If > you agree with me, then please comment out the "reverse" line in > Voice_Text::read_parms and see if the voice selection stuff works better. The voice selection actually works at the moment, for Linux/Cepstral. Not that I understand why. The problem I was having was missing speak events due to not finding a matching voice, which I couldn't find where that was happening. Tim -- Tim Sailer Coastal Internet, Inc. www.buoy.com 631-399-2910 |