Incrementality changes take3 #217
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The problem was that the numbers are calculated precisely and only afterwards is the returned value limited to a maximum of 19 (for compatibility with flite). It's not really worth finding out that the utterance contains 92 words when we then `rail' to 19 anyways, especially given that DOM traversal is relatively slow.
Synthesis (at least HMM synthesis) re-creates the Targets, again from XML. We can simply use the DOM objects' UserData facility to cache the Target objects for later re-use (after all, even though we have sped up the generic feature processing two checkins ago, it's still quite slow).
make methods and constants static when they can be, replace LinkedLists with ArrayLists in ModuleRegistry remove redundant null/truth check, generic iterator instead of casting, combine multiple calculations into one formula
It appears that nobody ever sets nor gets them.
Previously, processTargetList() filled in the data into a model given as a parameter (C-style)
clarify code, move boundary check into HTSPStream, also, remove debug output from HMM optimization, and adapt some other code to interface changes
turn the vocoder into real Java, by acquiring variables only as needed and then making all functions static for which it is feasible. Also, this patch removes most of the unused options (lpcVocoding, debug output, gaussian noise, NGAIN) and some potential debug/standalone code. I hope this is acceptable, I had to somehow reduce complexity to be able to analyze what's happening.
also, store duration errors from CART selection directly in HTSModel
an arguable change to get rid of HTSDWin as a a separate object and icorporating HTSPStream into it. I don't believe that the current modularization would work with any other windowing implementation anyway, so very little is lost. At the same time, I found quite a runtime difference when I profiled the inlined vs. non-inlined versions (some time ago, though). Conflicts: marytts-runtime/src/main/java/marytts/modules/HTSEngine.java
add a few methods, make a bunch of static methods public (instead of private) and one more protected.
if the complete array given to interpolateNonZeroValues consists of zeros, then findNextIndexNonZero immediately returns -1, the j-counter starts at i=0, and countour[j-1] is the -1'th index -> FAIL. This fix adds a ?-expression to ascertain that j never starts below 1.
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.