From: Rocker <rocker_at_shaw.ca>
Date: Mon, 08 Oct 2007 09:32:34 -0600

Today's Topics:

   3. Re: Voice patches (St?phane Doyon)
   4. Re: Voice patches (St?phane Doyon)
   5. Re: Voice patches (Daniel Dalton)


----------------------------------------------------------------------

Message: 3
Date: Mon, 08 Oct 2007 00:33:06 -0400 (EDT)
From: St?phane Doyon <s.doyon_at_videotron.ca>
Subject: Re: Voice patches
To: Rockbox development <rockbox-dev_at_cool.haxx.se>
Message-ID: <alpine.LFD.0.99.0710072344340.11890_at_odo.sdoyon.internal>
Content-Type: text/plain; charset="iso-8859-15"

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.

***I've been following this thread closely and just wanted to commend yall
for your most excellent theorizing and implementation of enhancements of
voicing for blind users.
If I may suggest: one feature I would love to see included in the quick
menu is the sleep timer. Also, I love the idea of enhanced navigation
through large files such as audio books. Something called "GoTo" for
example. Perhaps in increments of 10 percentages?

Yall are really getting me excited about rockbox voicing potentials. You
likely know that I'm not a coder. Don't even know how to insert a patch
((sheepish grin).
Having said this, if there's anything I can do to help like say, test some
builds or what ever, just let me know at my usual email address. I've got
the Toshiba F60 and the Sansa E280.

Keep up the great work dudes...rocker


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/
------------------------------
Message: 4
Date: Mon, 08 Oct 2007 00:39:13 -0400 (EDT)
From: St?phane Doyon <s.doyon_at_videotron.ca>
Subject: Re: Voice patches
To: Rockbox development <rockbox-dev_at_cool.haxx.se>
Message-ID: <alpine.LFD.0.99.0710080033280.11890_at_odo.sdoyon.internal>
Content-Type: text/plain; charset="iso-8859-15"
On Sat, 6 Oct 2007, Marianne Arnold wrote:
> to answer one of St?phane Doyon's questions in an earlier mail...
>
>> This one is the aspect I am not too sure how to handle. It suggests an
>> interesting question however: among the remaining hwcodec users, is there
>> anyone at all using voice?
>
> Yes, I do even though I'm not blind. I like being able to control my Ondio
> without having to look at the display and as long as it as a "stock" Ondio
> without backlight it was almost a necessity if I wanted to use it in the
> dark. I know at least one more dev who uses the voice UI on his Archos(es) 
> in
> the car and I believe that this feature is not unpopular among Archos 
> users
> in general...
OK good to know.
> I can't imagine what problem you see with voice on hwcodec, you just need 
> to
Well for one, there's this bit in bookmark.c:
/* disabled, because transition between talkbox and voice UI clip is not 
nice *
#if 0
It works well enough on my SWCODEC players though. I'm not sure what the
issue was.
> Having said this, I'm willing to test any voice patches on hwcodec, just
> can't test always and anytime but I was a tester for quite a few other
> features. Sometimes it needs some nagging and pointing to the patch entry 
> in
> the tracker though. ;)
Wonderful. I'll call on you at some point then.
-- 
St?phane Doyon
<s.doyon_at_videotron.ca>
http://pages.videotron.com/sdoyon/
------------------------------
Message: 5
Date: Mon, 08 Oct 2007 16:43:37 +1000
From: Daniel Dalton <daniel.dalton47_at_gmail.com>
Subject: Re: Voice patches
To: Rockbox development <rockbox-dev_at_cool.haxx.se>
Message-ID: <4709D199.6090806_at_gmail.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
On 8/10/2007 2:33 PM, St?phane Doyon wrote:
> 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 :-).
I guess I have to be with this sort of thing it isn't easy. I think I
need to study my book more and write some of my own programs. Like you
said to me off list. This is probably off topic though.
>
>>> 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.
Ok thanks for explaining that.
>
>>> -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
  Why do you need to add it to the menus?
I don't usually disagree with what you say but I disagreed with one
thing you said.
About the spelling option.
I think we should be able to make it spell the file or directory we are
over. We don't want to change the setting.
So if I am over a folder called music
I could just hit spell and it would say:
"m u s i c"
I would still have my settings the same.
What do you think?
Maybe your idea is better.
I will try and write up a quick patch to night and then you can make
improvements.
What do you think?
> 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.
Good idea about using the same quickscreen code.
>
>> 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.
Yes.
>> 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
You could say that. :-) But i did add a keymap for the h300 and h100 I
think. you didn't have this before.
> 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.
Yes your right. But since I couldn't work out how to move the setting to
the wps context menu I just used the button.
Anyway if it got excepted we could just remove the button stuff. I would
probably write myself a patch with the button for my own use like the radio.
BTW Does the button work on x5?
>
>> Or do you mean in that quick screen.
>
> Yes.
Ok so what will be in the quick screen? Remember if you choose to use
the current quickscreen you can only have 3 options in there.
Will there be spell, info, volume and tracklock?
If so unfortunately that won't work. Think about the ipods for example.
>
>> 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.
Well if you are going to fix this and the paused playback issue let me
know. I would like to help out with something.
I have only written some very basic patches like:
-talking alarm
- 12 hour voicing of the time
-shutdown option in root menu
-voice total disk size patch (now in your info screen patch)
>
>>> -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.
Yes again if you want help with this I would be happy to help with some
code or testing.
>
>> 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.
If we have one plugin voice file (For all plugins) then what is the
problem with duplicates between plugins?
>
>>> -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.
Yes.
>
>>> -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.
Well do you know what file to look at? Then I will see if I can write a
quick patch.
>
>> 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.
Yes
>
Also are you getting my emails off list? If so have you replied? Not
sure if all my email is being downloaded.
And don't worry about the rec button patch idea I had (I think I sent
you the patch) but your idea is better.
Probably needs resyncing as well since my other patch (7897 was excepted.)
> 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.
Good
>
Thanks for your help.
-- 
Daniel Dalton
http://members.iinet.net.au/~ddalton/
daniel.dalton47_at_gmail.com
------------------------------
_______________________________________________
rockbox-dev mailing list
rockbox-dev_at_cool.haxx.se
http://cool.haxx.se/cgi-bin/mailman/listinfo/rockbox-dev
End of rockbox-dev Digest, Vol 25, Issue 10
******************************************* 

Received on 2007-10-08