FS#6331 - Voice and features for FM radio
Opened by Stephane Doyon (sdoyon) - Wednesday, 15 November 2006, 03:00 GMT
Last edited by Stephane Doyon (sdoyon) - Wednesday, 07 November 2007, 02:15 GMT
This patch adds voice to the FM radio, re-does some menus and adds a few
First of all, someone made it possible for the voice to talk while the
radio is playing. I'm pretty sure that wasn't working two months ago. Big
thanks to whoever did that.
Requires P#6159 and P#6236.
First I had all the splashes and dialogs talk (just use ID2P, see
P#6159). Just that helps a lot. First thing that happens when going into
the radio screen for the first time is the auto-scan dialog, which was
I have it say the tune mode (scan vs preset) when it changes.
If the voice file preference is to say numbers, I have it say the index
of the preset, otherwise if the setting is for spelling and the preset
name is something else than the default auto-scan name, I have it spell
that. Obviously it's convenient only for very short names or call
letters. If the preference is for spelling but there's no name, or if
we're in scan mode, then I have it also say the current frequency. I'm
assuming it's OK to speak only one decimal place instead of the two that
But then I came to the radio_menu and the presets menu.
The radio_menu has three unusual elements: the menu item contains both a
field name and a value, and clicking it changes the value in place. They
are the entries for force mono mode, region, and scan mode. I added
ordinary full-blown submenus for those options. Until I can get some
feedback, I have it use the submenus if the talk_menu setting is enabled,
and the original method otherwise. At least for force mono and region,
I think I would prefer having a submenu, for uniformity and the ability
to cancel a change. And those two are not changed often. I'm not sure
what to make of the button preprocessor function, and it does say
#if 0 /* this screen needs fixing! */
The presets menu is even more of a problem: menu entries are preset
names. I need to have those spelled. The menu structure seems a bit
convoluted to me. There's this preset_menu_items array that needs to be
constantly rebuilt with copies of the preset names from presets]. There's
some elaborate manipulations to keep both lists in sync. Oh and there's
that button preprocessor function, the purpose of which I don't really
get. I chose to reimplement the presets menu using a gui_synclist. An
alternative might have been to come up with some menuing infrastructure
to allow arbitrary speech for each menu entry, perhaps through some sort
of voice callback. The gui_synclist made it easier to add a few new
functions however. And the callback avoids the duplicated preset lists.
cvs log tells me this menuing code stuff isn't old, so I may be taking
apart fairly recent code here. Comments appreciated, or if anyone wants
to educate me wrt RB menus, or has a good idea how to handle complex
voice output for menu entries... Some other menu entries in RB that can't
be spoken are: recording directory, simple equalizer.
I added two new functions to the preset context menu:
-Ability to move a preset,
-Ability to insert a new preset at a given spot in the list.
I was certainly influenced by the playlist_viewer which I just worked
with. I even put in the icons to indicate the currently playing
preset and the preset being moved. Oh and I indicate both the preset name
and frequency. If a sighted person could tell me whether this all works
right, it would be appreciated.
And in the radio_menu, I added a new function to sort the presets by frequency.
Oh and I fixed a little glitch when deleting the last preset: access
beyond array bounds, uses uninitialized data, tunes to frequency to 0.0
which seems to confuse my hardware...
Wednesday, 07 November 2007, 02:15 GMT
Reason for closing: Accepted