From: BlueChip <cs_bluechip_at_webtribe.net>
Date: Sun, 20 Jun 2004 02:45:06 +0100

>Here is how I could imagine it:
>
>A string bank of phrases is stored in the .rock file as a resource
>A program, on the computer, looks through all these .rock's and creates
>a file for each one.

you need to add language support to that bit of the idea.
I also suggest that the reader might analyse a seperate header file, NOT
data embedded in a .rock

>The file would be named after a hash of the phrase and they'd all be
>stored in the same directory.

You mean each phrase gets a seperate voice file?
that way the disk has to spin up every time it needs a (new) sample.
I think all samples required for a single rock, in a single voice file

>When a plugin asks for a phrase, hashes (pre-compile time or run time)
>the phrase and plays that MP3 file.
>
>This way:
>1. It would be easy to keep the MP3 files in one place
>2. You could download a whole premade directory if you wish to use voice
>features but don't wish to make the voices yourself
>3. It wouldn't add to the rock files (You could have the MP3s and the
>rocks separately)
>4. If there are two phases the same, only one would exist, because
>they'd hash into the same string

good idea, but this is what would cause loads of disk spin-ups
of course, I suppose the rock could pre-load all required files?

"Loading. Please Wait..." LOL

>5. No individual files to carry around for the Voice features - all the
>data needed to create them is in the rock.

hmm, but then people have to write utils that will read binary files to
create voice fonts, this will scare a lot of people.
Perhaps a plugin could be written to extract the voice info from plugins to
a text-readable format?

>...But then I don't do this type of programming :)
>
>On Fri, 2004-06-18 at 17:10, Cristian wrote:
> > Joerg wrote:
> > >(forgive me, I don't want to spark another flamewar)
> >
> > Sorry, this was not my intent, as person and as blind I think that any
> additional feature is welcome, voice is for us necessary to be able to
> use all the features. Your first vocal interface, is great, I
> think that the audio capabilityes of the BC audio plugin are also very
> nice, for the moment being I find it a nice idea to include blind
> support there, if, however, a more organized and predictible structure
> or architecture could be implemented for speech output enabled
> plugins, as you where suggesting Joerg, I think it would be even better,
> I hope that we can get there, if any plugin has its own vocal
> file, let's say a audio.voice file, and the plugin could use the core
> components to speak, I think it would be OK, since it would give all
> the plugin's developers the freedom to make it vocal or not, and to make
> a suited vocal output for the plugins. If the voices in the end are not
> consistent, I mean the type of voice, I wouldn't care, important is that a sor!
> t !
> > ov speech output is there. Plus, vocalizing all the plugins to
> me doesn't make much sense, since I think that only a couple could
> be beneficial to us, and I don't think that vocalized plugins could
> meet the need of sighted people, not even while driving. As for the
> audio plugin, I think it can improve the quality of the audio under
> certain circumstances and if Bluechip could help to integrate it in the
> normal firmware, I think that it would be nice, although, I personally
> appreciate that it is a rather advanced tweaking interface, and
> that perhaps it should be put under a rather hidden submenue.
> >
> > Hope this helps, just a modest opinion of a user, whose intent is not
> to spark anything, just to help to make the project grow.
> >
> >
> > Bye, and thanks again to all developers.
> >
> > In the mean while, a question to BC: is there a ucl file for your
> modifyed version? and, I think I wrote it before, is it possible to
> update the vocal interface so as to read _talk files? I could use the
> normal flashed version, and when I need the plugin I could rolo to your
> firmware, but at the moment, the folders are nolonger read.
> >
> > Bye, Cris.
> >
> >
> > it follows your original message.
> >
> >
> > >Bluechip hacked the plugin interface and a few other points of the core to
> > >force his audio control in. This gives quick success, an incompatible
> fork,
> > >but worst of all a badly maintainable architecture. The latter not being a
> > >virtue in itself, but we can't let loose completely.
> > >
> > >Exporting the talk API has issues. Plugins could "re-use" the existing
> > >vocabulary, but we certainly don't want to extend that for the superset of
> > >all possible plugins. Same goes for language IDs and localization. For
> > >talking, what's required is a way for the plugins to bring in smaller
> > >"sub-voicefiles" with their vocabulary extension. Remaining problem is how
> > >to have that more or less consistant, you may have different speakers
> then.
> > >
> > >In general, first we have to build the infrastructure, then the features.
> > >
> > >Jörg
> > >
> > >--
> > >+++ Jetzt WLAN-Router für alle DSL-Einsteiger und Wechsler +++
> > >GMX DSL-Powertarife zudem 3 Monate gratis* http://www.gmx.net/dsl
> > >
> > >_______________________________________________
> > >http://cool.haxx.se/mailman/listinfo/rockbox
> >
> > _______________________________________________
> > http://cool.haxx.se/mailman/listinfo/rockbox
>
>_______________________________________________
>http://cool.haxx.se/mailman/listinfo/rockbox

_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on 2004-06-20