内容

本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 悪くなる点

特になし...?