Ryuichi Yamamoto

郷に入っては郷に従えということで、僕は https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt に習っています。Parameters, Returns, See Also, Examples などは、すべてnumpydocに従うものです。他はあまり知らないですが、chainerは異なるフォーマットを利用しているみたいです

返信おそくなりました。すいません > そもそも何故sprocketの開発を始めたかというと，Voice Conversion Challenge 2018(予定)のベースラインシステム（VCC2016のチャンピオンシステムを少し改良した手法 [Kobayashi et al., SLT 2016]）として，再現性のあるコードを提供する事が目的です． なるほどです。素晴らしいと思います。 > 1. VCC2018のために．SLTで提案した手法を再現出来る事 > 2. 動的時間伸縮で結合特徴量を作成出来る事 > 3. 現状の高品質な分析合成系を使える事 ライブラリとして考えると、この内重要なのは2でしょうか。 今後の方向性として、一つの案としては、このリポジトリでは2にフォーカスする、というのがいいと思いました。1は、そのライブラリを活用した一例として、再現性を担保する目的で、別リポジトリに切り分ける、という方法です。現状、両者を一緒にしてしまっていることが良くないように思います。特に、`リポジトリトップ/sprocket` と `リポジトリトップ/scripts/src` の2つを整理する必要があると思います。この方針は、汎用性を担保しやすい一方で、声質変換におけるごく一部のパートのみを提供することになり、ユーザが自分で書かないといけないコードはそれなりに多くなります（特徴抽出、モデル学習、変換、合成、etc）。研究者向けなら、何の問題もないとは思いますが、一般ユーザも対象にする場合は、優しくないかもしれません。3は、WORLDを使うことで自然と達成されると思います。 別の方向性として、声質変換のフレームワークを目指す方針があると思います。例えば、研究者が重要な部分の研究（モデル？）に専念できるように、それ以外の部分の共通化を目指す、とかです。数年前からずっと考えていますが、いまだに良い案が浮かびません。過去の僕の失敗作として、 https://github.com/r9y9/VoiceConversion.jl があります。 >...

> jntを使ってユーザがDNN.train(jnt)やDNN.convert(x)などの関数を実装して，ユーザの領域で学習と変換を実現すれば良いと考えています．言い換えると，sprocketは，ユーザにjntやxを提供する機能だけを持つという事です． なるほど理解しました。ただ、sprocketの機能を結合特徴量の提供にフォーカスするのは良いと思いますが、その場合、scipts/src内のスクリプトを書き換えて使用する、というユースケースは、ふさわしくないのではないでしょうか。スクリプトには結合特徴量の抽出以外の処理が多くあり、それを使わせるということは、（結合特徴量の抽出以外の機能を提供しているという点で）そもそもの目的に反するように思います。また、ユーザにsprocket内の流儀に出来る限り従わせたくないという意味でも、スクリプトの使用を想定する場合、決まったディレクトリ構造、ファイルフォーマット等をユーザに強制することになってしまいます。 もちろんユースケースとしてはscripts内のような方法も当然あるのですが、ライブラリの設計を考える上では、もう少し詳細に、どのモジュールのどのクラス/関数を、どのように（組み合わせて、拡張して）使用するのか、というユースケースを考えた方が良いかなと思います。ユーザーにとってのインタフェースは、`import hoge` する部分であり、それを通して呼び出す関数、クラスであるので。 `jnt.twf_refine(cv_x, tar)` みたいなインタフェースがあると、便利だと思います もし `import hoge` ではなく、スクリプトをちょっといじって使用してもらう想定であれば、スクリプトをいじらなくて済むようにオプションを充実させた、コマンドラインツールとしての提供もありかもしれません

再現性の保証ではなく、ライブラリを有用なものにするためにどうすればいいか、という点について、話を進めます。まずは今後の方針が不明確に感じるので、明確にしていきたいと思います。まず、声質変換の研究者向けとするのか、（声質変換、音声処理に詳しくない）一般ユーザ向けとするのか、をはっきりさせるのが良いと思います。 #30 のコメントと https://github.com/TakedaLab/sprocket/issues/23#issuecomment-312481778 から想像するに、high-levelなインタフェース（≒blackboxとして動く、声質変換、音声処理の専門外ユーザ向け）を想定しているのだと思いますが（※もし間違っていたら指摘してください）、個人的には、これは一般ユーザにも研究者にも役に立たないものになりかねない、と危惧しています。 high-levelであるということは、low-levelな実装は隠蔽されているので、low-levelな部分を変えたい場合には、自分で書かなければなりません。例えばscikit-learnは、機械学習の一般ユーザ寄りのライブラリです。GMMを使って何かを学習したい人にはうってつけですが、GMMの学習アルゴリズムについて研究している研究者には、あまり役に立たず結局自分で書かなければならない、といったようにです（GMMは例です）。 声質変換は、多くの要素技術からなる応用寄りの技術で、要素技術として他の技術のベースに使用されることは少ないように思います。要素技術として活きる技術であれば、blackboxとして動くツールの価値は大きいと思いますが（WORLD, STRAIGHTなどがそうです）、そうでない場合、あまり価値が見いだせないのではないか、と思いました。つまり、high-levelなインタフェースでは、声質変換の専門外の人にとっても役に立たないのではないか、ということです。 > たとえば，import sprocket as spr と宣言して，gmm = spr.model.GMM(混合数など）を読み込むと，gmm.train(jnt)やgmm.convert(x)が出来るような枠組みをsprocketでは提供出来ればと思います． 言い換えれば、このような使い方をする人がそもそもいないんじゃないか？ということです。研究者はtrain/convertの中身をいじりたいし、convertしたあとの結果を使って何か別の応用をするユーザなんてほぼいないんじゃないか、と で、今後の方向性について僕の意見をまとめると、high-levelなライブラリは、low-levelなライブラリの上に必要であれば作ることができる、という意味でも、声質変換の研究者をターゲットとして、low-levelなライブラリにする方針がよいと思っていますが、いかがでしょうか。僕が気づいていないだけで、high-levelなインタフェースにはこんな価値がある、などあれば、教えてください。

> このレポジトリで開発しはじめた頃から考えていたのは，pythonとVCに初めて触れたB4の学生くらいが研究の事始めとして使えるレポジトリになれば良いと思ってました． 無意識に汎用的であることを重視していろいろ考えていましたが、ふと思いつきで意見すれば、B4などを対象とした教育目的なコードを提供する、という方針はありですかね？（あまり深く考えずに言っています

ちなみに bndap ってband aperiodicity の略で合っていますか（省略形が、何の略なのかわからないことが多いです、、

はい、そのほうがわかりやすいと思います

``` % nm -extern-only SPTK-3.dll | grep agexp 65d9e180 T agexp ``` seems exported, but falling: https://ci.appveyor.com/project/r9y9/sptk-jl/build/1.0.120/job/rq33xkuxqnrelgx4

No. However, SPTK is writter in C and I think it should work on android.

Looks like https://github.com/r9y9/pysptk/issues/91. Did you use python 3.10?