[project-s] Core APIを用意する

[y-chan]

内容

本Issueはproject-s用です。

project-s向けに、VOICEVOX Coreに対して「f0輪郭(フレームf0)予測」と「フレーム音量予測」、「子音長予測」、「長音対応decoder」のモデルを導入し、C APIでインターフェースを用意したいです。

少し急ですが、今月中に用意したいため、最新のmainから派生するのではなくて、現状のproject-sブランチの状態である0.14派生から作りたいです。 また、実装の速さ重視で、今までと同様のAPIのほうがエンジンから扱いやすい関係上、新APIの方を一旦無視して(0.15から大きく変わるので、0.14時点のところに生やしてもあまり意味がないという認識です)compatible_engine.rsにだけAPIを生やして運用したいです。 今のところ、f0輪郭予測についてはpredict_contour/yukarin_sosf_forwardとして生えていますが、フレーム音量予測に合わせてpredict_frame_f0に改名・統一し、それ以外はpredict_frame_volume、predict_consonant_length、source_filter_decodeでインターフェース名をそろえようかなと。

インターフェースは一旦これでいいと考えているのですが、内部でのモデルの持ち方を少し検討中です。将来的にはvvmにすることになると思うのですが、今みたいにmodelsとして統一して持つと、上記のproject-s用特殊モデルがあるもの・ないものが同時に共存して、扱いに困る気がしています。 もちろん、一部モデルをオプショナルにして統一して持つのもいい気はするのですが、project-sモデルとttsモデルは必要なモデルがほぼ排反になるはずなので、別でモデルを持つ場所を用意したほうがいいのかなーと...!

かなり急ではあるのですが、 @qryxip さん、ご意見いただけると非常に助かります...!

Pros 良くなる点

project-sが進行する

Cons 悪くなる点

特になし...?

[Hiroshiba]

issueまとめ助かります！！

predict_frame_f0 predict_frame_volume source_filter_decode predict_consonant_length

良さそうに感じました！

predict_出力データ名だと、将来入力データの種類を変えたくなったときに名前衝突が起こるだろうなと感じました。 けどまあ、そのときは不要な入力引数はNULLを渡すとかでC APIも互換性維持しつつ拡張できなくもないので、この方針で行ってみても良いのかなと。

内部でのモデルの持ち方を少し検討中です

たしかにどう実装すべきかパッとわからないですね･･･。 VVM・Async化でAPIが大きく変わるので、compatible_engine.rsのAPIを考慮しつつ、0.14からなるべく差分が無い形で実装できると嬉しそう･･･？

あと内部での持ち方に加えて、ファイルとしてどう持つのか、エンジンにどう伝えるのかも考慮ポイントかなと感じました！

[y-chan]

将来入力データの種類を変えたくなったときに名前衝突が起こるだろうな

確かに、少なくともpredict_frame_f0やpredict_frame_volumeに関しては、入力データがテキストやアクセントになる可能性も否定できないのかなと思いました。 まあ、互換性無視してv2みたいな形でAPIを増やすというのもありな気がしているので、一旦これで行きたいと思います。

ファイルとしてどう持つのか

これは0.14時点ではmodel_files.rsにファイル名を追加すればいいはずなので、あまり気にしなくていいかな？と思いました。 vvmになれば、manifestにsingかどうかを記載するフィールドを用意すればいいのかなと。

エンジンにどう伝えるのか

たしかに、これは少し考える必要がありそうです。 話者を露出させるためにsing_speakersAPIがほしいかも...? あと、source_filter_decodeの対応話者とpredict_frame_f0などの対応話者は変化する可能性があるので、それ用にもAPIが欲しくなりそうです... sing_speakers内で、機能の対応/非対応を書いてあげると良いですかね...?

[Hiroshiba]

将来入力データの種類を変えたくなったときに名前衝突が起こるだろうな

互換性無視してv2みたいな形でAPIを増やすというのもありな気がしているので、一旦これで行きたいと思います。

たしかにです！　賛成です。

ファイルとしてどう持つのか

これは0.14時点ではmodel_files.rsにファイル名を追加すればいいはずなので、あまり気にしなくていいかな？と思いました。

こちらも同感です！

エンジンにどう伝えるのか

話者を露出させるためにsing_speakersAPIがほしいかも...? あと、source_filter_decodeの対応話者とpredict_frame_f0などの対応話者は変化する可能性があるので、それ用にもAPIが欲しくなりそうです... sing_speakers内で、機能の対応/非対応を書いてあげると良いですかね...?

考えてたのですが、speakerとsing_speakerを分けるのは避けるべきな気がしました！ speakerではなくスタイルによって対応非対応の差が出たりとかありそうなので。（まあなんとかなるとは思いますが、より良い方法がありそう）

まだ考えきれてないのですが、一旦sing関係なく、モデルの能力とかモデルのタイプをmetas.jsonのスタイルごとに書くとかどうでしょう？ 能力は「フレームレベルのf0をスコアから作れる」とか「フレームf0とフレームphonemeから音声合成できる」とかを想定してます。 モデルのタイプはsing用とか長音用とかTTS用とか。

ただ、能力とタイプを両方書くべきなのか、片方で良いのかとかはちゃんと考えきれてないです。。。 （なんとなくモデルタイプはモデル読み込みに、モデル能力はエンジン側から使うときに必要になるものだから両方あるべきな気がするけど、能力がどれくらい細分化していくか不明なので、最初はモデルタイプだけでも良いかも･･･？）

[Hiroshiba]

こちら一旦完了かなと思うのでclose します！お疲れ様でした！！

でもまあ多分もっと API 増やしたいんですよね。ありはインターフェイスを変えるか。 生成範囲指定と、逐次生成（streaming？）と、生成結果の固定化と。そのあたりはまた別issueかなと！