project-s ブランチをmainブランチにマージしたい

[Hiroshiba]

内容

長い間別ブランチになっていたproject-s ブランチが役目を果たしました。今はrelease-0.15ブランチになっています。

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

なのでmainブランチにマージしたいのですが、あまりにも API 構成が変わりすぎているので、どうしていくべきかを考えられる場を作ってみました･･･。

実現方法

とりあえず問題になりそうな箇所を列挙してみます。

style_typeが違う場合の扱い

スタイルごとのタイプが今まで1つだったのが、4つになりました。

• talk: 今までと同じ、TTS用のスタイル。TalkModelに対応。
• sing_teacher: 歌い方を生成できるスタイル。SingTeacherModelに対応
• sf_decode: 歌い方から音声を生成できるスタイル。原理上、別に歌じゃなくても良いので名前にsingが入ってない。SfDecodeModelに対応。
• sing: sing_teacherとsf_decodeの機能を持つスタイル。

これ関連でややこしいことが３つ思いつきます。

• singスタイルはモデルが2つ必要
  • 可能であれば１つのVVMに２種類のモデルを持てるようにしたい
    • この時のコメントでも同じようなこと言ってました
  • metas.jsonやmanifest.jsonで、typeをsingにするのかsf_decodeとsing_teacher２つを持たせるのか、どっちがいいかわからない
    • まあ互換性がなくなったらmanifest_versionを上げれば良いだけなので、どっちでもいいっちゃ良い
• 同じスタイルID・別のスタイルTypeがありえる
  • A.vvmにはsing_teacherが、B.vvmにはsf_decoderが、みたいな
• １つのvvmの中に複数のスタイルTypeを含めたい
  • 例えば、sf_decodeしかないスタイルと、singも持ってるスタイルを同じvvmに含めたい
    • もうちょっというとmodel.onnxを共有できるため
  • あと将来的なことも考えると、1つのキャラの全スタイルが入った vvm が作れるようになるので嬉しいかも
    • namine_ritsu.vvm（トーク・ハミング・ソングがある、みたいな）
  • これは最悪切っても良い（容量が非効率的だったり、複数の vvm に分散するだけなので）

InferenceDomainが増えそう

style typeごとに一つdomainを作るのか、sing domainは作らないのか、どっちが良いかパッとわかりませんでした･･･。

使い方・サンプル

それぞれ追加が必要そう

その他

もし何か問題がありそうだったら、破壊的変更しちゃってもいい気がします。
かなり説明が曖昧なところがあると思うので、不明な点があれば何も聞いてください 🙇

[qryxip]

@Hiroshiba さん、 @y-chan さん、 @qryxip の3名で行った2024-03-04のミーティングから:

• 0.16にはcompatible_engineだけでも入れる (優先度を高くする)

---

ただし、ミーティング中に話した次の2点についてはミーティング後に気付いたことがあります。

• compatible_engine対応のときに、Statusを3つ持つようにする
  → Statusに3種類を扱わせた方がよくないか? (StyleMeta::r#typeを追加し、トークという区分を実装に導入する #761)
• ソングを本格的に実装するときis_model_loaded(StyleId)をどうするか?
  → よく考えたらcompatible_engineにしかないはずなので考えなくてよいのでは?

[Hiroshiba]

どの概念が3種持つべきかぱっとわからないんですよねぇ…。

is model loadedはたしか今世に出てる製品版コアだと、そのスタイルで扱うモデルが全部読み込まれてたらtrueとかだったと思います！