内容

長い間別ブランチになっていた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は作らないのか、どっちが良いかパッとわかりませんでした･･･。

使い方・サンプル

それぞれ追加が必要そう

その他

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