Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Voice patches

Re: Voice patches

From: Daniel Dalton <daniel.dalton47_at_gmail.com>
Date: Mon, 08 Oct 2007 16:43:37 +1000

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
Received on 2007-10-08

Page was last modified "Jan 10 2012" The Rockbox Crew
aaa