Ryuichi Yamamoto

For the record, I built the latest Cxx.jl (https://github.com/Keno/Cxx.jl/commit/bce1fdf7b354f3984d9dd39ae83fd6f9e6ef9930) on top of Julia master (https://github.com/JuliaLang/julia/commit/d4749d2ca168413f3db659950a1855530b58686d) based on llvm 3.7.1 and confirmed that this behavior still happens.

I see. Thank you for the clarification.

Using `PRESERVE_INPUT` flag in FFTW.Plan and removing `copy!` in istft roop make much faster. So the backward plan would be: ``` backward_plan{T

@gummif Thanks for your comment. I was thinking about replacing: ``` julia copy!(tmp1, 1, S, 1+(k-1)*size(S,1), length(tmp1)) FFTW.execute(p, tmp1, tmp2) ``` with ``` julia FFTW.execute(p, sub(S,1:size(S,1), k), tmp2) ``` Though...

Oh, I had the same segfaults. Could you modify backward_plan as follows and try again? ``` julia backward_plan2{T

Sorry for my insufficient benchmarks. I agree with @gummif

I think one possible reason is that there's no windowing process in STFT. https://github.com/ksw0306/ClariNet/blob/b03f99a64087e6eaf7682536b04379f1fe71b38a/modules.py#L117 Without windowing, we will see unexpected high-frequency values in the spectrum domain due to the discontinuity...

一応補足しておくと、戸田先生の論文 https://www.cs.cmu.edu/~pmuthuku/mlsp_page/lectures/Toda_VC.pdf における式22, 23に現れる逆行列の部分を指していました。それぞれ、A^-1bの形になっているので、少なくとも式を素直に計算しようとすると、linalg.solveで速くなると思います。僕が過去にGMM声質変換 (https://gist.github.com/r9y9/88bda659c97f46f42525) を（ナイーブに）実装して、少し高速化された経験から、イシューを立てました。 が、今考えると、式22の期待値の計算を、A^-1 bの形で解こうとすると、`t` のループがでてきてしまうので、A^1 を明示的に計算して、`t`のループをなくす方が速そうです。式23に関しては、それ単体でみればA^1 b の形を解く方が速くなると思いますが、式22の計算の時点で元話者の共分散の逆行列を明示的に求めていれば、それをそのまま使えばよいので、linalg.solveを使う必要はなくなりますね。 まとめると、現状の実装にあるlinalg.invは、np.linalgn.solve によって置き換えられるものではなく、すでに効率の良い実装になっている、と思いました。あまり実装をちゃんと見ずに、流し読みでイシューを立ててしまっていました、すいません。 言い訳になってしまいますが、コードを見て`A`、`b`って何・・・ってなった記憶があるので、コードと論文の対応がわかりやすくなっていると（式番号の参照を書く、論文と同じ記号を使う、など）、読み手にとっては助かるので、今後検討してもらえると幸いです

sphinxが使いやすいと思います。僕は https://github.com/librosa/librosa をよく参考にしています。ドキュメントのホスティングには、 - https://readthedocs.org/ - https://pages.github.com/ の２つは使ったことがあります。前者は、何より楽なのが良いです。githubのタグイベントをホックして、自動でバージョンごとのドキュメントのビルド、URLの切り替え（latest/stable）をやってくれます。デメリットとしては、例えばlibrosaのドキュメントにあるように (例. http://librosa.github.io/librosa/generated/librosa.core.stft.html#librosa.core.stft )、コードコメント中にpyplot.plot などを挟んで、ドキュメントに画像をはさみたい場合に、readthedocsのドキュメントビルド環境には画像を表示するバックエンドがないので、sphinxでドキュメントのビルド時に画像を生成できない、といったことがあります（sphinxでは、コードコメントにplot(x) 的なコードを書いて、ドキュメントビルド時に画像を生成して挿入する、といったことができます）。後者は、自由度が何よりのメリットでしょうか。自分でビルドしてプッシュすればよいので、何でもできます。ただし、その分手間は増える、といった感じです。

> ibrosaのドキュメントのドメインが，librosa.github.ioになってるのは，pages.github.comをホスティングとして利用しているからなのかな？ そうです。 librosaは何年も前から使ってますが、とても良くテストされていて、ドキュメントも豊富で、レビューもきっちりやっていて、ソフトウェアの開発、運用の参考になると思います。 librosaに初めてPRを出した時、あまりのレビューの丁寧さに感動した覚えがあります。