[9fans] rsynth, yes enjoyed much

[9fans] rsynth, yes enjoyed much

[forsyth]

The dictionary makes a big difference to the accuracy of the speech.

The libdbm I referred to in the README isn't libgdbm
(though it probably wouldn't be too hard to get that to work,
once you've waded through the usual `configure' nonsense).
It's related to the original one in 7th Edition Unix.
I did it when I still had access to Unix sources,
and I hadn't the right to distribute it.  As I said in the README,
it might just as well use binary search in this application
(there are fancier schemes but the quantity of text you'd like
to hear this way is sufficiently limited that it's hardly worthwhile using them).

[9fans] rsynth, yes enjoyed much

[okamoto]

I've constructed beep-1.0 database for the rsynth.
I used Stevens's dbm in his text book without file
lock/unlock for Plan 9 native C compiler.

The obtained sizes (made by mkdictdb) were as follows:
	original:	7.63 MB   (beep-1.0)
	index file:  7.6 MB    (bDict.idx)
	data file:	2.05 MB   (bDict.dat)

The consumed time to construct this database
was 2 hours and 15 minutes.

After all, the most interesting result by this database
is great, however, wehich does not make me believe
I can hear the long sentences from SB16.

Kenji

[9fans] rsynth, yes enjoyed much

[okamoto]

Thanks for deep discussion on this dbm things, where I learned
much how, in a future,  some database packages should be
implemented into Plan 9.

As Charles pointed out, we need only to read a database in this case
where no one will try to write.   The problem is that I missed my
way when I  saw too many "ifdef" things in the gdbm sources,
which forced me much dissapointed to try to do something
there. ;_;

However, I'm still have an will to do there after taking a good
sleep last night.  I'm now starting with Stevens's dbm package
which has little ifdef things, and is more clear to me.

Kenji

[9fans] rsynth, yes enjoyed much

[forsyth]

>>multiple users in any access method.  With dbm
>>type routines the system will need file locking, etc.

investigation of dbm/libgdbm was prompted by its limited use
in rsynth, where such things aren't really a problem since
both dictionary and index are essentially static.
on the other hand, the argument was that going to the
effort of disentangling libgdbm's source-level dependence
on a posix environment to be able to use <libc.h>,
in order to link it with rsynth.  it has just occurred to
me that i've got another lookup routine that i could
easily use freely instead.  i'll change the rsynth port to use it.

in general, though, you're right!

[9fans] rsynth, yes enjoyed much

[G.David]

>>perhaps you could
>>convert libgdbm to use libc directly.
>
>Yes, however, I'm now begin to doubt it's worth for Plan 9.
>Plan 9 has not any dbm utility other than ndb related, which
>suggets it doesn't important to the system, doesn't it?

Remember that the file servers are accessed by many
terminals and cpu servers and you *must* support
multiple users in any access method.  With dbm
type routines the system will need file locking, etc.

Looking at a 9P data store, there is no reason why
you can't store data using names as keys.  The key
access looks like a hash mechanism (an open/read of
a directory has no particular order).

/* create the data store */
Tcreate tag topdirfid name_table CHDIR|0777 0
Rcreate tag fid qid
Tclunk tag fid
Rclunk tag fid
Twalk tag topdirfid name_table
Rwalk tag dirfid qid

/* for each name */
Tcreate tag dirfid name 0666 1
Rcreate tag fid qid
Twrite tag fid offset length pad data
Rwrite tag fid length
Tclunk tag fid
Rclunk tag fid
...

/* done */
Tclunk tag dirfid
Rclunk tag dirfid

To access the data for a key:

Twalk tag topdirfid name_table
Rwalk tag dirfid qid

/*for each name*/
Twalk tag dirfid name
Rwalk tag fid qid
Topen tag fid 0
Ropen tag fid qid
Tread tag fid offset length
Rread tag fid length pad data
Tclunk tag fid
Rclunk tag fid
...

/* done */
Tclunk tag dirfid
Rclunk tag dirfid

Since 9P is native in the entire system, it seems the
most natural way of handling data.  Performance
requirements, of course, are handled in the
implementation.

David Butler
gdb@dbSystems.com

[9fans] rsynth, yes enjoyed much

[okamoto]

>perhaps you could
>convert libgdbm to use libc directly.

Yes, however, I'm now begin to doubt it's worth for Plan 9.
Plan 9 has not any dbm utility other than ndb related, which
suggets it doesn't important to the system, doesn't it?

Kenji

[9fans] rsynth, yes enjoyed much

[forsyth]

>>to sources of dict.[ch], mkdictdb.c for gdb.h.   Making
>>libgdbm.a is easy, however, I got the following error when
>>I tried to compile "say".

>>after 8l linking say,

>>atexit: redefinition: atexit
>>(434) TEXT atexit+0(SB), $4

it's all my fault: my previous comment about using libgdbm was wrong.
when i ported rsynth i made it use Plan9's libc.h environment directly, not APE.
libgdbm is presumably using APE and the two aren't compatible.  perhaps you could
convert libgdbm to use libc directly.  i do it because it makes the libraries
easier to use from plan9 programs that use graphics, and it's always satisfying
to see all those #ifdefs vanish.

>>The other thing I've been tinkering with is using FreeType to generate
>>bitmap fonts from truetype outlines.  (The bitmap fonts from the

i've got a plan9 port of freetype, if that's any use.
i did an interface to generate plan9 subfont files.

[9fans] rsynth, yes enjoyed much

[okamoto]

Thanks 9fans.

I'm still trying to manage dictionary with say.   I know Russ's
comment, but this is my, say, habit not to be able to abandon
anything on its way.

Anyway, I compile libgdbm.a by pcc, and made a small change
to sources of dict.[ch], mkdictdb.c for gdb.h.   Making
libgdbm.a is easy, however, I got the following error when
I tried to compile "say".

after 8l linking say,

atexit: redefinition: atexit
(434) TEXT atexit+0(SB), $4

write_header:  undefined: sync in write_header

I've never called sync() in the sources.

What does this mean?

Kenji

[9fans] rsynth, yes enjoyed much

[Scott]

"Russ Cox" <rsc@plan9.bell-labs.com> writes:
| It's not the easiest speech to listen to.

Still, I managed to spend the whole weekend playing with it. :-)

The other thing I've been tinkering with is using FreeType to generate
bitmap fonts from truetype outlines.  (The bitmap fonts from the
distribution are pretty small if you run at high res.) Microsoft gives
away some unicode (subset) fonts, bitstream cyberbit used to be freely
available, and the commercial fonts from lucida are really nice.
The next version of FreeType is supposed to support Type1 fonts, too.

Anyone going to usenix?

[9fans] rsynth, yes enjoyed much

[Russ]

I used rsynth with the dictionaries for a little
while to announce my incoming mail
("mail from whoever").  I had to train it to
pronounce most email addresses, since
things like "rsc" don't appear in dictionaries.

Even so, I found that humans could only understand
it if they were so trained as well.  That is, I could
understand it but no one else could.

It's a neat toy, but it's likely you'ld get annoyed pretty
fast trying to have it read your mail to you.

There's a copy of this message, for example, at
www.eecs.harvard.edu/~rsc/rsynth.out
that you can play by doing

	echo -n 'speed 8000' >/dev/volume
	cat rsynth.out >/dev/audio

It's not the easiest speech to listen to.

Russ

[9fans] rsynth, yes enjoyed much

[okamoto]

If this rsynth can read mails for me, it'd be very
confortable to use Plan 9 (not loud volumes, of course).

I thought it might be so because I had no dictionaries
in my system.  (I don't know well what the dictionaries
do for us, though)

Then, I prepared libgdbm.a for my system.  However,
following your sources, dict* functions doesn't work
for gdbm package which I've compiled.  I suppose
you prepared special version of dbm utility for Plan 9,
didn't you?

Kenji

[9fans] rsynth, yes enjoyed much

[forsyth]

>>I forced him(men's voice I suppose) to read README.Plan9
	...
>>Can a native speaker follow his speaking?  In my case, I can do
>>it if I have a written paper on hand.

it would sound better if i'd used shorter sentences in the README,
which would keep the pitch sounding more natural.
as it is, it sounds a little depressive,
or rather it would if it weren't amusing.

on the other hand, rsynth is adequate for playing with speech output.
i used it on our answering machine for a few years.
i fiddled with the text of the message and say's parameters to improve the result.
it still sounded like a Dalek on tranquilisers.

[9fans] rsynth, yes enjoyed much

[okamoto]

Hi

I tried rsynth 2.0 at forsyth's Web page on my Pentium 90
terminal with SB16.  Yes, of course, I had much funs on it!
I played it again and again today.  It's an interesting game
indeed!

I forced him(men's voice I suppose) to read README.Plan9
by Charles, and tried to follow what he is talking...
Well,.... of course, I have much strong handicap to hear English....

How others heard rsynth?   :-)

Can a native speaker follow his speaking?  In my case, I can do
it if I have a written paper on hand.

Kenji