From: Stéphane Doyon <s.doyon_at_videotron.ca>
Date: Mon, 08 Oct 2007 00:33:06 -0400 (EDT)

On Sat, 6 Oct 2007, Daniel Dalton wrote:

> Would it help if I tried to get some included on irc?
> I am not a very good coder myself (As you probably know) but I got a couple
> of my voicing patches excepted by asking on irc.

Well you are persistent, I'll give you that :-).

>> interrupting voice quickly while music is playing,
>
> What exactly do you mean by this?

When we want to interrupt an already playing talk utterance to start a new
one: if music isn't playing then the PCM buffer can be flushed, but if
music is playing the voice is already mixed in and the response time is a
lot longer. So much so that even if the mixing thing is cool, whenever
possible I stop playback when I have a lot of menu navigation to do.

>> -I'm considering implementing an alternate quick screen for blind users:
>> something to put a few key functions closer at hand. We would like a
>> quick way to have the time spoken, the Rockbox info menu is just too
>> far. I'd like to put in a function that temporarily overrides file and
>> dir .talk clips, for those times where you can't make out what the
>> synthesizer was saying in that .talk clip, because it's a weird band name
>> that you haven't heard before, and you need it spelled out jus this
>> once.
>
> So that would be in the quick screen thing?
>
>> Also a quick way to adjust volumes when browsing files or
>> menus.
>
> Is this sort of thing likely to be implemented into rockbox.
> I am not saying at all it is not a good idea. Personally I think it is a
> great idea but most of the devs are sighted and may think it is a waste of a
> button.

That's why I'm thinking of perhaps putting those voice/blind related
hotkeys under a common context. That way I need only one button mapping
for several functions. And as it happens, the quickscreen already has a
defined button mapping for many players and is accessible in many contexts
(except I'd have to add it in menus though). And the quickscreen
functionality is a lot less useful nowadays because it can all be done
with not too many more keypresses through the root menu context menus. So
if I added a configurable setting to choose between the old quickscreen
and this new one, no one should really mind that I steal that button
mapping. My voice/blind oriented quickscreen idea still feels a little
clunky because it ties to several unrelated functions... but I'll upload
a patch for it soon and we can try it out and see if it makes sense in
real life. Comments welcome of course.

> Also I am working on a long press of rec to say the time and a short press to
> go to the radio.

See, that's what I mean.

Of course my quickscreen idea doesn't solve the problem of what function
needs quick access. Going to the radio IMHO does not need a hot key. But I
suppose you only want that for yourself and not for Rockbox in general.

>> Perhaps a hot key to toggle tracklock / study mode (P6188).
>
> Actually I already implemented a button press for x5 and h300 in your track
> lock patch. See my last comment.

You mean you brought back the button I had in my earlier patch :-). It's
true the tracklock setting in the settings menu is really too far for
comfort, but OTOH it's not worth a hot key either IMHO.

> Or do you mean in that quick screen.

Yes.

> That's a good idea. What about a beep function for the recording screen? Or
> is that too difficult. I was browsing the mails from a while a go and I think

Recording currently stops all playback, including beeps. Haven't looked at
how hard it would be to change that.

>> -Infrastructure to load secondary voice files. Use that to make plugins
>> talk, without having to increase the size of the main voice file.
>>
>
> Yes.
> Obviously voicing all the useful plugins for blind users and just using the
> normal voice file would not work. The voice file would become very large.
> But I see two problems with this:
> 1. A lot of voice files. Remember one for every language and every player.

True. They could be packaged in one archive I suppose.
Or we could come up with a way to combine voice files into one and load
only part of that big consolidated blob.

> 2. What about if we want to use strings for plugins that are already in the
> main voice file?
> We will need to have duplicates of the same strings.

I'm sure we can arrange to reuse existing strings. There is a similar
issue with translations I believe. OTOH there would still be duplication
between plugins, but I guess that's not too much of an problem.

>> -Make some basic WPS info accessible, at least time position and trac
>> duration. Perhaps in a list like the id3 screen.
>>
>
> Do you just mean some very basic info

Dunno... for starters anyway. Sighted users have this elaborate pluggable
WPS screen thing. I wouldn't want anything that complicated. In any case,
speech is linear so we need to be able to ask for what we want rather than
have lots of info listed back to back.

Any metadata info from a talking id3 screen wouldn't have to be duplicated
that in a talking WPS info screen.

> not like your other patch that voices
> the whole id3 screen?

Well it really mostly spells it all out. Useful, but you really have to
want to know something badly to bother looking it up.

>> -See if we could implement DAISY, or a subset of it, by preprocessing the
>> DAISY on the host machine and coming up with a cue sheet for each DAISY
>> level. We'd need to have a playlist backed by multiple cue sheets and the
>> ability to switch between them. I'm not entirely sure this makes sense,
>> would need to look into it more seriously.
>>
>> -Spontaneous battery level warning, say at 50% and 20%.
>>
>
> speak it automatically?

Yes. Well configurable through a setting of course, in case you're
recording the output and don't want it messed up, or some other reason...
Possibly disabled by party mode too...

> I also wanted rockbox to say charging when I insert the cable. Not sure what

Good idea.

> Oh yeah and what about putting the info screen into a list.

Right. I need to know what effect this would have on the visual interface.
If the effect is negative then we'd have to implement something that
affects only voice.

On Sun, 7 Oct 2007, RaZorbacK wrote:

>> P7653 also is good, although perhaps the setting I added in there is
>> overkill and should always be on.
>
> Personnally, having the ability to turn this one on or off should not be
> suppressed.

OK then. Since you guys both agree, then I'll leave it in.

Thanks a lot for the feedback.

-- 
Stéphane Doyon
<s.doyon_at_videotron.ca>
http://pages.videotron.com/sdoyon/

Received on 2007-10-08