Lojban In General

On 11/8/08, A. PIEKARSKI <totus@rogers.com> wrote:
> I just installed eSpeak and tried it out. It is interesting, but has
> enough problems to limit its usefulness.
>
> Then I discovered some relevent messages in the mail archives with
> your name appended - sounds like you were trying to make some
> improvements in September.
>
> Can you let me know the current status, please? By the way, the thing
> that I found most awkward is the way it races through without pausing
> before the {ni'o}s.

I'm not sure of it's current status as a version 1.39 has been
released while I tried modifying version 1.38 and I'm not sure if the
upstream author made any changes based on what I was experimenting
with. I should check. I also have done very little as I'm not sure
what to do about the x and z phomemes. I was completely stuck on
those.

I did make some updates to lihertadji.pl , including some incomplete
stuff to add commas to words. I also want to beef up the fixup
function so only valid pronounceable lojban words make it through into
the output. Some of that I'm worried that the definition of what is
and isn't a valid syllable, isn't well defined and agreed upon. I
thought that adding the commas would help espeak pronounce syllable
boundaries a little better; I haven't tested how espeak actually
respondes to having commas all over the place.

I also have long time goal of having li'ertadji output SSML so you can
mix lojban and other languages with zoi , la'o and la'oi . I'm
attaching what I have even though it's ugly and has known errors and
incomplete spots in it. Yes I know some of it is embarrassing, but
it's a work-in-progress .

I will check to see what if anything got changed for version 1.39 .

Ok just downloaded it and checked and it looks the exactly the same.

espeak-1.39-source]$ sha1sum dictsource/jbo_*
15e2321ccc869369e70bf5cf358261187d40598b dictsource/jbo_list
4081ab03f16a9e1bd75c47146f8b7a844216dbe2 dictsource/jbo_rules

espeak-1.38-source]$ sha1sum dictsource/jbo_*
15e2321ccc869369e70bf5cf358261187d40598b dictsource/jbo_list.orig
4081ab03f16a9e1bd75c47146f8b7a844216dbe2 dictsource/jbo_rules.orig

I think the upstream guy thought that some of my changes were too extreme.
I will redo some of my work and only fix things that are clearly
wrong, some of it wasn't wrong persay, just not really needed.

short to do list:
1) get rid of { a } to { abu }, { e } to { ebu }, etc from jbo_list
That's obviously and clearly a proper fix. espeak would change {le
broda e le brode} into {le broda ebu le brode} and { u bu co'e} into {
ubu bu co'e} which goes without saying is bogus.

2) get rid of { m } to { my }, { l } to { ly } from jbo_list
espeak shouldn't be touching any of the single consonants words, l,m,
n, and r should be syllabics and according to at least some lojbanists
should be valid cmevla.
{ b } to { by } shouldn't really be that harmful . The cll would
classify them as cmevla , but they aren't really made up of any
syllables . I would prefer if they got altered to be { b } to { yb } ,
I think I will made li'ertadji do that in the future. the preprocessor
should be able to handle more invalid words then what espeak tries to
do.
The reason I prefer { b } to { yb } over { by } is because it
preserves it's cmevla status and doesn't change the word into a lerfu
valsi . I need feedback from others on if they should be considered
valid one letter click names and thus be left alone, or whether they
are invalid words that the cll underspecified on.
As far as I know nobody use single letter cmevla in real life, so it's
not a big deal.

The upstream maintainer was reluctant to take a patch from me that got
rid of them all, because he said some of the consonants would sound
merely like a click noise; I think that is valid concern, but it
should be the responsibility of the writer not to give bogus input to
espeak. Using the preprocesser with fixups will hopefully ensure that
little to no invalid input reaches espeak in the first place.
Also I am not sure; I didn't test whether the syllabics sound like
clicks or if the if they are recongizable.

3) Get rid of the stuff which stresses cmavo from jbo_list but leave
the upstream authors pausing in place . cmavo should never be stressed
unless someone capitalized some of it's letters. The stress doesn't
invalidate the meaning of the words, so isn't critically wrong, but
isn't strictly correct either.

It also will stress cmevla without capital letters which also isn't
wrong really, it might even be the right thing to do according to some
I've talked to. I'd prefer if it didn't stress cmevla and leave that
up to the writer, but I could be wrong about that. I request feedback.

maybe nice to have but dropped:
1) in jbo_rules h, q, and w aren't really legal lojban characters,
pause if they occur at the ends of a word ; y always needs pausing if
it occurs at the end of words .. li'ertadji foreign word detection and
fixup routines should handle the h,q,and w stuff even better than
these espeak rules. The preproccesor also handles y stuff very well .
2) dj and tc but not ts and dz has special support in jbo_rules, my
earlier patch had dropped that not sure if that's an improvement or
not. Someone who knows better should figure out of affricitives are at
their best.
3) Someone should check to see if the rules that change the sounds for
l, n , r based on adjacent letters make sense. My earlier patch just
made them more consistent.
4) Give extra pause to lo'u and le'u the error quote stuff and zo and
zoi the regular quote stuff

I had also just ripped out some pausing stuff as the rules didn't
really require them, and they don't hurt anything AFAIK. Unless anyone
complains about too much pause; I won't touch them again. I'm more
likely to push for a few more things to get pauses.

Also I did nothing to change the x and the z, I doubt the upstream
espeak maintainer did anything either. I haven't tested yet and
hopefully I'm wrong.

Not sure how much pause you want before ni'o and no'i . It shouldn't
be that fast especially since most people put newlines before sections
as well as using ni'o, and I think espeak is whitespace sensitive
enough to do extra pause if you have a few newlines in place.

The critical fix is getting rid of the { .a } to { .abu } snafu. If
1.40 had nothing else but that, it would be a significant improvement.
Getting rid of the stressing of some cmavo and not adding "y" to
single consonant cmevla would be nice, but the x and z issue is more
important, but sadly I don't think I can do anything about it.

I also have no idea what the upstreams schedule is like.

Anyway it's getting late and tomorrow I'm traveling out of town with
some friends, so I won't be able to do anything 'till Monday afternoon
anyway.

I attached the simple but critical patch. Something like the below
should be done before 1.40 is released.

diff -U2 jbo_list jbo_list.crit

---

+++ jbo_list.crit 2008-11-08 23:17:52.000000000 -0800

@@ -19,23 +19,14 @@

-_a abu
b b@
c S@
d d@
-_e ebu
f f@
g g@
-_i ibu
j Z@
k k@
-l l@
-m m@
-n n@
-_o obu
p p@
-r R@
s s@
t t@
-_u ubu
v v@
x x@

To unsubscribe from this list, send mail to lojban-list-request@lojban.org
with the subject unsubscribe, or go to http://www.lojban.org/lsg2/, or if
you're really stuck, send mail to secretary@lojban.org for help.

Thanks for your quick reply.  Obviously, you have put in an enornous
amount of work, so I hope that you will be successful!

Given that lojbanists have no oppoprtunity to hear or speak lojban, your work
should be seen as critical by all.  I hope you are getting the support you need.

I am new to lojban, and do not have a technical background, so much of
what you wrote was lost on me.  But please note my comment on {ni'o}.

>
> Not sure how much pause you want before ni'o and no'i . It shouldn't
> be that fast especially since most people put newlines before sections
> as well as using ni'o, and I think espeak is whitespace sensitive
> enough to do extra pause if you have a few newlines in place.
>
I'm confused here - maybe I'm doing something wrong.  If I paste text from
an existing document into TTSApp, the white space between 'paragraphs'
gets ignored.  Is there some special character that needs to be inserted
before the {ni'o}s?

totus

To unsubscribe from this list, send mail to lojban-list-request@lojban.org
with the subject unsubscribe, or go to http://www.lojban.org/lsg2/, or if
you're really stuck, send mail to secretary@lojban.org for help.

On Sun, Nov 9, 2008 at 4:15 AM, Stephen Pollei <stephen.pollei@gmail.com> wrote:
>
> The reason I prefer { b } to { yb } over { by } is because it
> preserves it's cmevla status and doesn't change the word into a lerfu
> valsi .

I agree. I believe that handling these single letter cmene was the
reason I had a consonant coda allowed in front of a cmevla in the
preceding version of the peg morphology, before the zifcme idea. And
my idea too was that they could always be supported by a leading {.y}
(not only single letter cmevla, but any cmevla that begins with a
consonant cluster that can't be a syllable onset with the usual
rules).

> I'd prefer if it didn't stress cmevla and leave that
> up to the writer, but I could be wrong about that. I request feedback.

In principle I share your preference, but I'd have to listen to some
examples to be sure.

> 2) dj and tc but not ts and dz has special support in jbo_rules, my
> earlier patch had dropped that not sure if that's an improvement or
> not. Someone who knows better should figure out of affricitives are at
> their best.

Consistency is probably the best idea, either affricate them all, or none.

mu'o mi'e xorxes

To unsubscribe from this list, send mail to lojban-list-request@lojban.org
with the subject unsubscribe, or go to http://www.lojban.org/lsg2/, or if
you're really stuck, send mail to secretary@lojban.org for help.

On 09 Nov, Stephen Pollei <stephen.pollei@gmail.com> wrote:
> On 11/8/08, A. PIEKARSKI <totus@rogers.com> wrote:

> > I just installed eSpeak and tried it out. It is interesting, but
> > has enough problems to limit its usefulness.

Hello, I'm the author of eSpeak. But I don't know much about lojban.

The latest version (currently 1.39.23) is at:
http://espeak.sf.net/test/latest.html

> > By the way, the thing that I found most awkward is the way it
> > races through without pausing before the {ni'o}s.

There is a list of words in dictsource/jbo_list which have a pause
before them. Since lojban doesn't use commas to indicate pauses and
clause boundaries, we must rely on words. Please amend the list and
give me the updates.

This seems to be a problem with lojban, long sentences with no
punctuation. How to know where to pause and where the intonation
should indicate end-of-clause. Pauses and intonation are important to
indicate structure. You can't read a long sentence out aloud without
pauses and intonation.

In the jbo_list file, you can specify for a word (or a phrase) that it
has a pause before or after the word, or that it has an end-of-clause
pause (which also changes the intonation). With English and other
natural languages, eSpeak uses a pause before conjunctions such as
"and", "if", "which", and to indicate brackets and quotation marks.
The end-of-clause pause is used for a comma or semicolon.

With lojban, it should be possible to determine the structure and
therefore where pauses should occur (but not by me, because I don't
know lojban). Can this be done simply by associating pauses with
certain words?

> I also have done very little as I'm not sure what to do about the x
> and z phomemes. I was completely stuck on those.

I've changed the sound of x phoneme recently, so try the latest
version. You previously said that it was difficult to distinguish
between 'c', 's', 'z' (phonemes S s z). These are the same
phoneme sounds which eSpeak uses for English and most other languages,
and I've not heard of any problem distinguishing them. For example,
English "ship, sip, zip" sound distinct, as are "gash, gas, gaz".
Perhaps the problem occurs with certain combinations of consonants?

> I thought that adding the commas would help espeak pronounce syllable
> boundaries a little better; I haven't tested how espeak actually
> respondes to having commas all over the place.

What do you mean by "pronounce syllable boundaries correctly"?

> 1) get rid of { a } to { abu }, { e } to { ebu }, etc from jbo_list

This has been done. eSpeak will only pronounce 'a','e','i','o','u' as
"abu" etc, if a program (such as a screen-reader) explicitly asks for
the letter name.

> 2) get rid of { m } to { my }, { l } to { ly } from jbo_list
> espeak shouldn't be touching any of the single consonants words, l,m,
> n, and r should be syllabics and according to at least some lojbanists
> should be valid cmevla.

Changed now.

> { b } to { by } shouldn't really be that harmful . The cll would
> classify them as cmevla , but they aren't really made up of any
> syllables . I would prefer if they got altered to be { b } to { yb } ,

That's a simple change, when you decide.

> The upstream maintainer was reluctant to take a patch from me that got
> rid of them all, because he said some of the consonants would sound
> merely like a click noise; I think that is valid concern, but it
> should be the responsibility of the writer not to give bogus input to
> espeak.

Yes, but it's also the responsibility of eSpeak to try to pronounce
text even if it's not valid language. A single lone letter is a common
typo error.

> 3) Get rid of the stuff which stresses cmavo from jbo_list but leave
> the upstream authors pausing in place . cmavo should never be stressed
> unless someone capitalized some of it's letters.

Are you sure?
"Stress" here doesn't mean "emphasized". It just means that eSpeak
will give them the same stress as other words. jbo_list contains a few
cmavo which are "not unstressed". I don't know what they mean ("cai"
"cu'i", "pei" etc), but someone told me to include them because they
may carry more stress in normal speech than others.

The important question is not, "is it strictly correct", but rather
"does it sound right" and "does it help intelligibility".

> It also will stress cmevla without capital letters which also isn't
> wrong really, it might even be the right thing to do according to some
> I've talked to. I'd prefer if it didn't stress cmevla and leave that
> up to the writer, but I could be wrong about that. I request feedback.

Again, I think you misunderstand what eSpeak means here by "stress".
It's just the normal stress on the penultimate syllable of most words.
Not "special emphasis". I think the lojban capital letter convention
is used when the stressed syllable is other than the default. So no
capital letter means "stress on the penultimate syllable".

If there is a way in lojban text to indicate an emphasized word in a
sentence, then you can indicate that to eSpeak by using SSML (speech
synthesis markup language).

> maybe nice to have but dropped:
> 1) in jbo_rules h, q, and w aren't really legal lojban characters,

They may occur in foreign names.
Accented characters such as 'ö' and ñ are not in the English alphabet,
but eSpeak should cope if it sees them.

> pause if they occur at the ends of a word ; y always needs pausing if
> it occurs at the end of words

> .. li'ertadji foreign word detection and
> fixup routines should handle the h,q,and w stuff even better than
> these espeak rules. The preproccesor also handles y stuff very well .

> 2) dj and tc but not ts and dz has special support in jbo_rules, my
> earlier patch had dropped that not sure if that's an improvement or
> not. Someone who knows better should figure out of affricitives are at
> their best.

The "dj" and "tc" sounds are nearly always considered as single
phonemes (tS and dZ) in other languages. "ts" and "dz" are often
not (eg. in English). Listen for which sounds better.

> 3) Someone should check to see if the rules that change the sounds for
> l, n , r based on adjacent letters make sense. My earlier patch just
> made them more consistent.

> 4) Give extra pause to lo'u and le'u the error quote stuff and zo and
> zoi the regular quote stuff

I don't understand that one.

> I had also just ripped out some pausing stuff as the rules didn't
> really require them, and they don't hurt anything AFAIK.

Better to keep pauses if they help listening. Human speakers need to
breath occasionally even if the semantics don't require it.

In English eSpeak, I put short pauses before words such as "if",
"which", "since", "as".

> Also I did nothing to change the x and the z,

What did you want to change?

> The critical fix is getting rid of the { .a } to { .abu } snafu.

Fixed since eSpeak 1.38

> Getting rid of the stressing of some cmavo

Consider how they are spoken in real speech.

> and not adding "y" to single consonant cmevla would be nice,

I doubt it, if the consonant can't be a syllable by itself.

> but the x and z issue is more important, but sadly I don't think I
> can do anything about it.

I don't know what the problem is.

You wrote earlier that eSpeak is too fast. Most blind users of other
languages say that eSpeak is too slow, even at its fastest speed! But
with lojban, people are not native speakers and are not fluent. Just
use a slower speed ( -s option if you are using the command line, or
the speed slider if you are using a GUI application).

Another idea is to add the following line to the end of the file
espeak-data/voices/jbo (or if it's not there, then
espeak-data/voices/test/jbo):

words 1

That will speak words separately, not merged together. The speech
won't flow as smoothly, but it's probably easier to listen to. You can
use larger values in the range 1 to 4 to give longer gaps between words.

To unsubscribe from this list, send mail to lojban-list-request@lojban.org
with the subject unsubscribe, or go to http://www.lojban.org/lsg2/, or if
you're really stuck, send mail to secretary@lojban.org for help.

On 11/11/08, Jonathan Duddington <jsd@clara.co.uk> wrote:
> On 09 Nov, Stephen Pollei <stephen.pollei@gmail.com> wrote:
> > On 11/8/08, A. PIEKARSKI <totus@rogers.com> wrote:

> Hello, I'm the author of eSpeak. But I don't know much about lojban.
>
> The latest version (currently 1.39.23) is at:
> http://espeak.sf.net/test/latest.html

Ok I will have to download that and check it out. The last one I
downloaded was http://master.dl.sourceforge.net/sourceforge/espeak/espeak-1.39-source.zip
from http://espeak.sourceforge.net/download.html .

I'll get http://espeak.sourceforge.net/test/espeak-1.39.23.zip right now.

> > > By the way, the thing that I found most awkward is the way it
> > > races through without pausing before the {ni'o}s.

> There is a list of words in dictsource/jbo_list which have a pause
> before them. Since lojban doesn't use commas to indicate pauses and
> clause boundaries, we must rely on words. Please amend the list and
> give me the updates.

I can probably look through and find more words that indicate structure.
I'd like to be careful not to over do it though.

I'm not sure if I agreed with the ni'o issue as you can string them
together { ni'o ni'o ni'o} and adding a three big pauses would be
excessive. I think the way eSpeak deals with new lines solves the
issue good enough for me. It seems to pause enough using that imho.

> This seems to be a problem with lojban, long sentences with no
> punctuation. You can't read a long sentence out aloud without
> pauses and intonation.

Yes you have to catch your breath some time and the only time with
lojban you have to pause is only at certain times, in canonical text
those times would be indicated by "." which I presume should be a full
glottal stop. I noticed that you have different length of pauses and
am not sure exactly which one is perfect for that. English and other
languages use puncuation to represent pauses. Modern puncuation can a
little bit after the printing press.
In lojban you don't need them, but humans are likely to catch their
breathes from time to time and it's likely that they might grab some
of the habits of when to do so from other languages.

> With lojban, it should be possible to determine the structure and
> therefore where pauses should occur (but not by me, because I don't
> know lojban). Can this be done simply by associating pauses with
> certain words?

It probably can as all of the structure is associated with specific
cmavo type of words.

> > I also have done very little as I'm not sure what to do about the x
> > and z phomemes. I was completely stuck on those.

> I've changed the sound of x phoneme recently, so try the latest
> version.

I will have to try out the new version

> You previously said that it was difficult to distinguish
> between 'c', 's', 'z' (phonemes S s z). These are the same
> phoneme sounds which eSpeak uses for English and most other languages,
> and I've not heard of any problem distinguishing them. For example,
> English "ship, sip, zip" sound distinct, as are "gash, gas, gaz".
> Perhaps the problem occurs with certain combinations of consonants?

I think the problem I noticed with mostly with "zo" and a few other
words. I think it was just the z that I noticed. I had a jbo_test.txt
that is fairly big, I was planing on making a jbo_problems.txt that
only had stuff which people had complaints about.

I will retest and try making another test file that highlights only
things that are potentialy less than optimal.

> > I thought that adding the commas would help espeak pronounce syllable
> > boundaries a little better; I haven't tested how espeak actually
> > respondes to having commas all over the place.

> What do you mean by "pronounce syllable boundaries correctly"?

I mean that lojban has some ideas on where syllables should be split.

http://www.lojban.org/tiki/tiki-index.php?page=The+Lojban+Reference+Grammar
http://www.lojban.org/tiki/tiki-download_wiki_attachment.php?attId=195
[[ ... The commas represent new syllable breaks, but prohibit the use
of pauses or glottal stop. ... 9. Syllabication And Stress ... ]]

The Lojban Reference Grammar aka Complete Lojban Language aka cll has
some guidlines of where these syllable breaks should occur. I beleive
that your eSpeak program implements commas by adding a tiny bit more
time in between the timing of the adjecant phonemes. I think it might
help break apart some otherwise potentialy problematic consonant
clusters. I have an almost complete slaka_sepli function which means
syllable splitter, that should do the right things for stage 4 fu'ivla
and cmene; however I want it to split differently for lujvo and have
one extra step for stage 3 fu'ivla. Anyway a bunch of jargon, sorry.

I had also hoped that it would maybe fix some of the vague prosody
complaints I heard from others. I could be on the wrong track with
this.

basicly lihertadji.pl changes :
{ni'o la alfas bravos carlis deltas ekos fokstrot golf xoTEL indias
juliet kilos limas maik novembr oskar paPAS keBEK romios
sieras tangos Uniform viktas uiskis eksreis iankis zulus cu co'e }
into something like
{ ni'o la . al,fas . . bra,vos . . car,lis . . del,tas . . e,kos . .
fok,strot . . golf . . xo,TEL . . in,dias .
. ju,liet . . ki,los . . li,mas . . maik . . no,vemb,r . . o,skar . . pa,PAS .
. ke,BEK . . ro,mios .
. sie,ras . . tan,gos . . U,ni,for,m . . vik,tas . . ui,skis . .
ek,sreis . . ian,kis . . zu,lus . cu co'e}

adds pauses(".") based on dotside variant of the lojban rules which is
more than I want to put into your c++ code and adds commas also using
rules that I'd prefer doing in perl than trying to wedge into your c++
code.

Where to put the comma can change based on some somethimes subtle
rules; {porpi} becomes {pOr,pi} and {renro} becomes {rE,nro}.

The code I have for adding commas is incomplete in many ways, and under tested.

> > 1) get rid of { a } to { abu }, { e } to { ebu }, etc from jbo_list

> This has been done. eSpeak will only pronounce 'a','e','i','o','u' as
> "abu" etc, if a program (such as a screen-reader) explicitly asks for
> the letter name.

I checked your documentation and noticed that I had a
misunderstanding. However I don't know by what means do they ask for
this behavior?
./speak --help didn't say how to do request this behavior.

A full letter by letter spell out mode might be useful. I was
thinking of something like that for urls .
"http://example.com/" might be pronounced { hy ty ty py relba'a bu
katna bu katna bu e bu xy a bu my py ly e bu denpa bu cy o bu my katna
bu} or more formally { hy ty ty py rel,bA'a bu kAt,na bu kAt,na bu .e
bu xy .a bu my py ly .e bu dEn,pa bu cy .o bu my kAt,na bu} .
I was especially think of that if someone wrote {zoi url
http://example.com/ url}, much later feature. Also just in case there
is any misunderstanding about commas and periods; they are optional
and the two ways I wrote them out should in theory not effect how the
words are pronounced.

I just did a diff and see that some things were changed:
"l l@" into "_l l@"
and by http://espeak.sourceforge.net/dictionary.html section 4.6.1 I
can see that maybe I was wrong about the meaning of the leading
underscore. For some reason I was thinking it was matching whitespace
or something. I think it was a misunderstanding on my part.
Sorry for the confusion.

> > 2) get rid of { m } to { my }, { l } to { ly } from jbo_list
> > espeak shouldn't be touching any of the single consonants words, l,m,
> > n, and r should be syllabics and according to at least some lojbanists
> > should be valid cmevla.

> Changed now.
Yes I saw that in the diff.

> > { b } to { by } shouldn't really be that harmful .
> > . I would prefer if they got altered to be { b } to { yb } ,

> That's a simple change, when you decide.

I think that for changing text that I'd like to do stuff like that in
the perl preprocessor.
There are a few other things like voiced and unvoiced consonants
shouldn't touch and a few other rules that I like to simply enforce in
the fixup function.

> > The upstream maintainer was reluctant to take a patch from me that got
> > rid of them all, because he said some of the consonants would sound
> > merely like a click noise; I think that is valid concern, but it
> > should be the responsibility of the writer not to give bogus input to
> > espeak.

> Yes, but it's also the responsibility of eSpeak to try to pronounce
> text even if it's not valid language. A single lone letter is a common
> typo error.

Sure but their are other common typo errors like when forming lujvo
forgeting to put a y in place . {bacybau} might be mispelled {bacbau}
for example. I think the preproccessor can catch more stuff without
polluting your c++ with very language specific rules.

I don't think it's a big deal either way.

> > 3) Get rid of the stuff which stresses cmavo from jbo_list but leave
> > the upstream authors pausing in place . cmavo should never be stressed
> > unless someone capitalized some of it's letters.

> Are you sure?
> "Stress" here doesn't mean "emphasized". It just means that eSpeak
> will give them the same stress as other words. jbo_list contains a few
> cmavo which are "not unstressed". I don't know what they mean ("cai"
> "cu'i", "pei" etc), but someone told me to include them because they
> may carry more stress in normal speech than others.

http://www.lojban.org/tiki/tiki-download_wiki_attachment.php?attId=195
I use the terms as it's used in this section of the cll . I know that
cmavo can be stressed: example 9.13) e'u bridi
e'u BRI,di
E'u BRI,di
e'U.BRI,di

Shows three different ways that are valid to stress this example. The
third way requires a pause(glottal stop) to separate the words. The
one reason I don't like eSpeak stressing cmavo is because there is a
way for the writer to mark stress, but no way for him/her to indicate
it shouldn't be stressed. If it's left upto the author then he has
full control, but if eSpeak decides to stress certain cmavo and not
others then the range of choice is reduced. I think it could be
something that could be addressed with having alternative voices. A
full control version that stesses nothing and another voice that
stresses certain things be default.

http://espeak.sourceforge.net/voices.html

> The important question is not, "is it strictly correct", but rather
> "does it sound right" and "does it help intelligibility".

My main point was not correctness, but control. I think that the best
answer might be two dictionary files, that can be selected between
using your voice mechanism.

> > It also will stress cmevla without capital letters which also isn't
> > wrong really, it might even be the right thing to do according to some
> > I've talked to. I'd prefer if it didn't stress cmevla and leave that
> > up to the writer, but I could be wrong about that. I request feedback.

> Again, I think you misunderstand what eSpeak means here by "stress".
> It's just the normal stress on the penultimate syllable of most words.
> Not "special emphasis". I think the lojban capital letter convention
> is used when the stressed syllable is other than the default. So no
> capital letter means "stress on the penultimate syllable".

"stress on the penultimate syllable" is the mandatory rule for
brivla(gismu,lujvo,fu'ivla) but for cmavo and cmene it's acceptable
for there to be no stress at all. Again it's not really a correctness
issue but a control issue; I think having at least two dictionary
files would be best.

> If there is a way in lojban text to indicate an emphasized word in a
> sentence, then you can indicate that to eSpeak by using SSML (speech
> synthesis markup language).

yes the word {ba'e} emphasizes the next word.
http://espeak.sourceforge.net/ssml.html says eSpeak supports the <emphasis> tag.
I was thinking of outputing ssml just because lojban supporting
quoting things from other languages and so it would be nice to be able
to switch to english, or french, or german, or whatever as the
occasion might arise.

> > maybe nice to have but dropped:
> > 1) in jbo_rules h, q, and w aren't really legal lojban characters,

> They may occur in foreign names.
> Accented characters such as 'ö' and ñ are not in the English alphabet,
> but eSpeak should cope if it sees them.

yes the can occur in foreign words, which should always be properly
quoted using {zoi}, {la'o}, or {la'oi}, in which case the best thing
would be to switch languages temporarily.

I also have some rules in fixup that gets rid of these invalid letters
in maybe a slightly more intelligent way. Like "h" can be into either
{x" or {'} depending on the situation, or simply droped. I have about
20 regexs that deal with getting rid of this characters in the fixup
function. Ideally the fixup should only happen for things not quoted
and should be rare.

> > 2) dj and tc but not ts and dz has special support in jbo_rules,

> The "dj" and "tc" sounds are nearly always considered as single
> phonemes (tS and dZ) in other languages. "ts" and "dz" are often
> not (eg. in English). Listen for which sounds better.

Yes I'm not sure which is best, I know that in lojban "dj" is
considered as two phomemes, I also would need to ask others more
experinced in lojban for their opinion.
I see an option to write raw phonemes to stdout is available, but I'm
not sure hao to get eSpeak to use that directly to create a wav file,
if I did I could create a test file that had both pronounciations for
some sample text and see which people liked better.
Oh well I can always splice files together if needed to things a more
difficult way.
-x Write phoneme mnemonics to stdout

> > 3) l, n , r My earlier patch just made them more consistent.

Again I should make a test for that and see what people like best.

>
> > 4) Give extra pause to lo'u and le'u the error quote stuff and zo and
> > zoi the regular quote stuff

> I don't understand that one.

lo'u and le'u are used to surround a group of lojban words that might
otherwise be ungrammatical, so I think it best to slow done around
them. if it's ungrammatical it's likely to be something tricky. My
test file uses {lo'u} and {le'u} a lot because some of my tests are
just words strung together which are nonsense.

zo is used to quote one word, no pause mandated but I thought it might
be useful.

zoi is used to quote foreign text
like {da cusku zoi . glibau . hello there this is english . glibau . }
zoi needs certain pauses and is surrounded by lojban words which can
also often be used as hints as to which language is being quoted.
glibau is the lujvo for glico bangu aka english language.

> > I had also just ripped out some pausing stuff as the rules didn't
> > really require them, and they don't hurt anything AFAIK.

> Better to keep pauses if they help listening. Human speakers need to
> breath occasionally even if the semantics don't require it.

Yes I might even put in a few more pausing stuff, but I think maybe at
least two dictionary files might be good. One bare bones and the other
with some frills.

> > Also I did nothing to change the x and the z,

> What did you want to change?
The x sometimes sounded odd, but might have been correct, just odd
sounding to me.
the z sometimes sounded like a n or something. I'm not sure exactly
what or how to change anything.

ni'o zo fi .ezo lei .ezo kei .ezo da .ezo .a. .ezo du'u .ezo xu .ezo pu
valsi ra'a le vomoi djedi

ni'o zo fi . e zo lei . e zo kei . e zo da . e zo . a . e zo du'u . e zo
xu . e zo pu

. xlA,li xlU,ra . xy ry . xrU,ti xrA,ni . zy by . zbA,su zbE,pi . zy
dy . zdA,ni zdI,le
. zy gy . zgA,na zgI,ke . zy my . zmA,du zmI,ku . zy vy . zvA,ti .

It's been awhile but I think the zo words were among the worst sounding.
It's getting too late for me to retest now. Oh also reminded me that
some of the {by} stuff sounded too much alike.

by ly . boi . by ry . boi . cy fy . boi . cy ky . boi . cy ly . boi
. cy my . boi . cy ny . boi . cy py . boi . cy ry . boi . cy ty . boi
. dy jy . boi . dy ry . boi . dy zy . boi . fy ly . boi . fy ry . boi

That might demonstrate it. It's getting past 2 am though, so I must quit.

> > The critical fix is getting rid of the { .a } to { .abu } snafu.

> Fixed since eSpeak 1.38
yes seems it was a misunderstanding on my part. mea culpa . i u'u mi srera

> > Getting rid of the stressing of some cmavo
> Consider how they are spoken in real speech.
Again mostly a control issue, I think another voice for switching
dictionary would work well.

> > and not adding "y" to single consonant cmevla would be nice,
> I doubt it, if the consonant can't be a syllable by itself.

Sure I'm not too worried about it, invalid input can have undefined or
implementation defined outcome.

> > but the x and z issue is more important, but sadly I don't think I
> > can do anything about it.

> I don't know what the problem is.
>
> You wrote earlier that eSpeak is too fast.

sure in jbo_test.sh I use 115 words and like you said is likely
because we have no native speakers, and perhaps less than 30 that are
really expert and really fluent. Most(including me) have some knowlege
but struggle.

1. ! /bin/sh

./lihertadji.pl < jbo_test.txt > jbo_test0.txt
../src/speak -f jbo_test0.txt -v jbo -w jbo_test.wav -s 115

>
> add the following line to the end of the file
> espeak-data/voices/jbo
> words 1
>
> That will speak words separately, not merged together. The speech
> won't flow as smoothly, but it's probably easier to listen to. You can
> use larger values in the range 1 to 4 to give longer gaps between words.

Yes that another reason I made the preprocessor, in writing lojban you
can merge your words together.
{ni'o i coi tirnas dei cu cipra i o'i mu xagji sofybakni cu zvati le purdi} and
{ni'ocoi.tirnas.deicucipra.i.o'imuxAgjisofybAknicuzvAtilepUrdi} mean
the same and should be pronounced the same. The condensed version is
valid, but most lojbanists will get upset if you use it. More common
is stringing cmavo together like {lenu} instead of {le nu} and I did
notice that spliting words apart so that there is always space between
them definately made it sound better. The rules on splitting words are
again to complicated that I didn't want to attempt to pollute your c++
with them.

I thank you for your time, and I apologize for my earlier misunderstanding.
I also apologize for the quality of this email. It's 2:15 am and I'm
getting a bit tired.