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

Hiroshiba commented 6 months ago

内容

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

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

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

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

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

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 に分散するだけなので）

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

それぞれ追加が必要そう

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

qryxip commented 5 months ago

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

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

compatible_engine対応のときに、Statusを3つ持つようにする → Statusに3種類を扱わせた方がよくないか? (#761)
ソングを本格的に実装するときis_model_loaded(StyleId)をどうするか? → よく考えたらcompatible_engineにしかないはずなので考えなくてよいのでは?

Hiroshiba commented 5 months ago

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

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