[espeak-ng:master] new issue: A phoneme of a child table is not used if that phoneme is not also defined in its parent table
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Issue Created by BenTalagan:
#679 A phoneme of a child table is not used if that phoneme is not also defined in its parent table
Hi, I'm not totally sure if it's a bug or not, but it's a bit obscure to me. Here is my use case. For transcription purpose, I'd like to rewrite my own phoneme tables for english, and I've stumbled on the following oddity. I keep the original
I'm declaring the new phoneme table like this (in the
Note that it does not inherit from the Finally, I'm declaring the
Now, if I try to translate the following example, the
The strange thing is, if I add the phoneme to
then the phoneme is used, and it is taken from the child table :
Finally, if I remove the
To summarize, here are the four possible cases for the parent and child tables : Parent : not defined, Child : not defined => Not translated (pretty logical) Parent : defined, Child : defined => translated, uses child table definition (pretty logical) Parent : defined, Child : not defined => translated, uses parent table definition (pretty logical) Parent : not defined, Child : defined => Not translated (seems odd) Is this behavior really normal? I would have expect the
|
|
[espeak-ng:master] new issue: No voice on Windows10
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Issue Created by arnaudschd:
#678 No voice on Windows10
After building from source and installing eSpeak on Windows10, there is no voices showing up on the Speech Synthesizer personnalisation . How can I fix this?
|
|
Updates to Github
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
By valdisvi:
[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
Under MacOS, it seems egrep and grep are the same binary.
|
|
Updates to Github
#github
espeak-ng@groups.io Integration <espeak-ng@...>
1 New Commit:
[espeak-ng:master] By BenTalagan <ben_talagan@...>:
Modified: tests/language-replace.test
[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
I've merged this commit by cherry-picking the last commit. Thanks for the fix.
[espeak-ng/espeak-ng] Pull request closed by rhdunn:
#677 Fixing "Language Replace" tests under MacOS A small PR for fixing the
[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
Ok! Thanks a lot.
|
|
Updates to Github
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
By rhdunn:
Why not replace it directly with
[espeak-ng/espeak-ng] Pull request updated by BenTalagan:
#677 Fixing "Language Replace" tests under MacOS A small PR for fixing the
[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
Good point! I wasn't sure. I have done the change, just waiting for the tests to be over.
[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
Good point! I wasn't sure. I have made the change, just waiting for the tests to be over... done.
|
|
Updates to Github
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng/espeak-ng] Pull request opened by BenTalagan:
#677 Fixing "Language Replace" tests under MacOS A small PR for fixing the language-replace.test script under MacOS. The
[espeak-ng/espeak-ng] Pull request updated by BenTalagan:
#677 Fixing "Language Replace" tests under MacOS A small PR for fixing the
[espeak-ng/espeak-ng] Pull request updated by BenTalagan:
#677 Fixing "Language Replace" tests under MacOS A small PR for fixing the
|
|
new espeak-ng windows builds
Simon Eigeldinger <simon.eigeldinger@...>
Hi all,
Uploaded new builds this morning. Enjoy. Greetings, Simon
|
|
Updates to Github
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] Label added to issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation by BenTalagan.
[espeak-ng:master] Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation closed by BenTalagan.
|
|
Updates to Github
#github
espeak-ng@groups.io Integration <espeak-ng@...>
4 New Commits:
[espeak-ng:master] By BenTalagan <ben_talagan@...>:
Modified: emscripten/Makefile
[espeak-ng:master] By BenTalagan <ben_talagan@...>:
Modified: src/libespeak-ng/dictionary.c
[espeak-ng:master] By BenTalagan <ben_talagan@...>:
Modified: src/libespeak-ng/readclause.c
[espeak-ng:master] By Reece H. Dunn <msclrhd@...>:
Modified: emscripten/Makefile
[espeak-ng/espeak-ng] Pull request closed by rhdunn:
#676 Rule alignment fixes for non compliant platforms / Fix for emscripten demo This is a fix for #584, but the PR scope may be potentially larger : without this fix, the handling of compiled rules is not guaranteed to be compliant across platforms, since casting to int* may happen on non aligned char* , which has to be avoided. Some minor options also have to be added to the emscripten compilation workflow to make it work again with newer versions.
[espeak-ng:master] New Comment on Pull Request #676 Rule alignment fixes for non compliant platforms / Fix for emscripten demo
That's what tests are for :). Thanks for the fix.
|
|
[espeak-ng:master] reported: Rule alignment fixes for non compliant platforms / Fix for emscripten demo
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Pull Request #676 Rule alignment fixes for non compliant platforms / Fix for emscripten demo
By BenTalagan:
Pheew! I really need some rest, you saved me from pushing some really silly code. Looks better now.
|
|
[espeak-ng:master] reported: Rule alignment fixes for non compliant platforms / Fix for emscripten demo
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Pull Request #676 Rule alignment fixes for non compliant platforms / Fix for emscripten demo
By rhdunn:
They are passing on the master branch. The failing test is https://travis-ci.org/espeak-ng/espeak-ng/jobs/613903437#L2232.
|
|
Pull Request Updated
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng/espeak-ng] Pull request updated by BenTalagan:
#676 Rule alignment fixes for non compliant platforms / Fix for emscripten demo This is a fix for #584, but the PR scope may be potentially larger : without this fix, the handling of compiled rules is not guaranteed to be compliant across platforms, since casting to int* may happen on non aligned char* , which has to be avoided. Some minor options also have to be added to the emscripten compilation workflow to make it work again with newer versions.
|
|
[espeak-ng:master] reported: Rule alignment fixes for non compliant platforms / Fix for emscripten demo
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Pull Request #676 Rule alignment fixes for non compliant platforms / Fix for emscripten demo
By BenTalagan:
Hum, checks failed, but I've verified locally and it looks like that they were already broken before these changes. Is it normal?
|
|
Updates to Github
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng/espeak-ng] Pull request opened by BenTalagan:
#676 Rule alignment fixes for non compliant platforms / Fix for emscripten demo This is a fix for #584, but the PR scope may be potentially larger : without this fix, the handling of compiled rules is not guaranteed to be compliant across platforms, since casting to int* may happen on non aligned char* , which has to be avoided. Some minor options also have to be added to the emscripten compilation workflow to make it work again with newer versions.
[espeak-ng:master] New Comment on Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
@rhdunn : Thanks for your answer ! I have prepared a PR (#676), and limited myself to add a function to test sequential bytes to zero. It's very close to what was intended originally and non intrusive (the original code only tests four bytes, but after that they are still read one by one, not 4 by 4).
|
|
[espeak-ng:master] reported: emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
By rhdunn:
Thanks for the analysis. It looks like a version of
|
|
[espeak-ng:master] reported: emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
By BenTalagan:
Ok, after fixing the condition in
|
|
[espeak-ng:master] reported: emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
By BenTalagan:
After implementing a temp fix :
the parsing of the rules looks ok now, but the translation is still messed up. Found at least one suspicious place (within commit 55c6403) :
|
|
Updates to Github
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
By BenTalagan:
After taking time to investigate, I think I have found the problem. It comes from the following lines : They behave differently when compiled with llvm and emscripten. Under llvm, like with gcc, this will have what I would call an 'expected' behaviour : the cast to unsigned int from any position in the char* buffer will take into account the fact that we are not aligned to a multiple of 4 bytes. Under emscripten it doesn't : shifting by n+0, n+1, n+2 or n+3 bytes leads indifferently to the same result when casting to an int. One of the rules of the 'en' dictionary falls under this case, so the condition of having 4 successive bytes at 0 is not met and the rule parser explodes. @rhdunn, I'd like your opinion on that issue : should we implement a simple fix for this (like testing the four bytes instead of casting to unsigned int), are there any other part of the code that may be concerned?
[espeak-ng:master] New Comment on Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
After taking some time to investigate, I think I have found the problem. It comes from the following lines : They behave differently when compiled with llvm and emscripten. Under llvm, like with gcc, this will have what I would call an 'expected' behaviour : the cast to unsigned int from any position in the char* buffer will take into account the fact that we are not aligned to a multiple of 4 bytes. Under emscripten it doesn't : shifting by n+0, n+1, n+2 or n+3 bytes leads indifferently to the same result when casting to an int. One of the rules of the 'en' dictionary falls under this case, so the condition of having 4 successive bytes at 0 is not met and the rule parser explodes. @rhdunn, I'd like your opinion on that issue : should we implement a simple fix for this (like testing the four bytes instead of casting to unsigned int), are there any other part of the code that may be concerned?
[espeak-ng:master] New Comment on Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
Add : after reading a bit on the net, it really looks like this should be rewritten. Some refs : https://stackoverflow.com/questions/26995151/how-to-cast-char-array-to-int-at-non-aligned-position
|
|
Updates to Github
#github
espeak-ng@groups.io Integration <espeak-ng@...>
2 New Commits:
[espeak-ng:master] By BenTalagan <ben_talagan@...>:
Modified: src/libespeak-ng/compiledata.c
[espeak-ng:master] By Reece H. Dunn <msclrhd@...>:
Modified: src/libespeak-ng/compiledata.c
[espeak-ng/espeak-ng] Pull request closed by rhdunn:
#675 Fixing ungetc bad behavior under macOS Catalina This is a fix for (#674). For archiving purpose, the problem was the following : it seems that the The fix consists in avoiding such a situation.
[espeak-ng:master] New Comment on Pull Request #675 Fixing ungetc bad behavior under macOS Catalina
Merged. Thanks.
[espeak-ng:master] Label added to issue #674 Build fails on MacOS Catalina by BenTalagan.
[espeak-ng:master] Issue #674 Build fails on MacOS Catalina closed by BenTalagan.
|
|
[espeak-ng:master] reported: Build fails on MacOS Catalina
#github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
By BenTalagan:
PR ready (#675) :-) Thanks a lot for having taken such time to help!
|
|