Rockbox mail archiveSubject: Re: rockbox-dev Digest, Vol 25, Issue 10
Re: rockbox-dev Digest, Vol 25, Issue 10
From: Rocker <rocker_at_shaw.ca>
Date: Mon, 08 Oct 2007 09:32:34 -0600
3. Re: Voice patches (St?phane Doyon)
On Sat, 6 Oct 2007, Daniel Dalton wrote:
> Would it help if I tried to get some included on irc?
Well you are persistent, I'll give you that :-).
>> interrupting voice quickly while music is playing,
When we want to interrupt an already playing talk utterance to start a new
>> -I'm considering implementing an alternate quick screen for blind users:
***I've been following this thread closely and just wanted to commend yall
Yall are really getting me excited about rockbox voicing potentials. You
Keep up the great work dudes...rocker
That's why I'm thinking of perhaps putting those voice/blind related
> Also I am working on a long press of rec to say the time and a short press
See, that's what I mean.
Of course my quickscreen idea doesn't solve the problem of what function
>> Perhaps a hot key to toggle tracklock / study mode (P6188).
You mean you brought back the button I had in my earlier patch :-). It's
> Or do you mean in that quick screen.
> That's a good idea. What about a beep function for the recording screen?
Recording currently stops all playback, including beeps. Haven't looked at
>> -Infrastructure to load secondary voice files. Use that to make plugins
True. They could be packaged in one archive I suppose.
> 2. What about if we want to use strings for plugins that are already in
I'm sure we can arrange to reuse existing strings. There is a similar
>> -Make some basic WPS info accessible, at least time position and trac
Dunno... for starters anyway. Sighted users have this elaborate pluggable
Any metadata info from a talking id3 screen wouldn't have to be duplicated
> not like your other patch that voices
Well it really mostly spells it all out. Useful, but you really have to
>> -See if we could implement DAISY, or a subset of it, by preprocessing the
Yes. Well configurable through a setting of course, in case you're
> I also wanted rockbox to say charging when I insert the cable. Not sure
> 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.
On Sun, 7 Oct 2007, RaZorbacK wrote:
>> P7653 also is good, although perhaps the setting I added in there is
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
Page was last modified "Jan 10 2012" The Rockbox Crew