FS#6159 - Add voice to roughly 100 splash screens and yes-no menus
Opened by Stephane Doyon (sdoyon) - Tuesday, 10 October 2006, 04:54 GMT
Last edited by Nils Wallménius (nls) - Monday, 06 August 2007, 13:09 GMT
I'm a new Rockbox user, and I'm both blind and a programmer. I noticed
there are a lot of contexts in which my rockbox'ified player remains
silent and leaves me "in the dark". This patch set goes after the
I've split it into four patches to facilitate review.
talkmore-infra: This patch adds tiny bits of infrastructure that help
avoid clutter for the simple cases.
-A function and helper macro to speak a sequence of IDs (from an array),
conditional to talking menus being enabled.
-The ability for gui_syncsplash and gui_syncyesno_run to decode those so
called virtual pointers that can represent either an ordinary string or a
language / voicefont ID. Strings are processed as usual, and encountered
IDs can be spoken.
talkmore-lang: english.lang update, adding about 40 voice strings. There
are only 2 new phrases (for a special case), all the others are existing
phrases that did not have the voice part filled in.
talkmore-doit: Grunt work for lots of simple cases. Just substitutions of
ID2P() in place of str() for about 80 splash screens and 4 yesno
screens. This is not a mindless search&replace however: I've considered
each case. (Well I'm new to this code so I'm not saying I couldn't have
missed some issue...) I've left out some contexts: progress report
splashes (they probably update very fast), some cases in which errors are
reported that imply the voice can't be working, messages before the voice
is initialized, and some spots I just wasn't sure about. As I said, I'm
going for the 80-90% of low-hanging fruit.
talkmore-special: A few slightly more complicated cases where I was just
a bit more creative than a simple substitution. About 11 more splashes, 5
more yesno screens and one menu (eq_advanced_menu). For example: passing
"%s %s" to gui_syncsplash() in order to concatenate two language
IDs. Some variable print messages were given a constant voice
correspondance for simplicity.
Speech for splash screens more or less assumes that the talking will
complete within the splash screen's delay (the time it's shown on the
screen). Usually that's the case, as messages are pretty short and most
splashes last for a full second or more. If the speech lasts longer, it
runs the risk of being interrupted by the next utterance that the
subsequent context will want to voice. One interesting case is those
splashes with a 0 duration. Those that are used for progress report I
haven't touched yet. The most used 0 duration splash is LANG_WAIT
("Loading"). This is used for things that might take anywhere from a
fraction of a second to complete, to a long time. Even a short voice
message is annoying for the frequent cases where the actual waiting is
imperceptible or very short. Yet I do want feedback, even for cases with
moderate waiting, if only to tell me that the player really did pick up
my key press. The solution to this is to play a very short audio clip,
instead of speaking something. I have this 0.15s sound which I put in as
the clip for LANG_WAIT. On hearing that I know the player got my key
press and I just have to wait a bit. With such a short duration, it's not
annoying and not likely to interfere with anything else. It does mean a
new special case for the voice building scripts, but it's exactly like
the VOICE_PAUSE case. And nothing breaks if your voice building script
doesn't handle this case yet or if you have an older voice file: the
entry remains blank and you just don't hear anything on LANG_WAIT.
Monday, 06 August 2007, 13:09 GMT
Reason for closing: Accepted
Additional comments about closing: Committed