Closed y-chan closed 7 months ago
あ、ちなみにgenerate APIのテストが落ちてるのはcargo xtask generate-c-header
でヘッダー更新すれば解決すると思います!
source filter decode
-> sf_decode
sing style model
-> sing teacher model
source filter model
-> sf_decode_model
上記のように変更しました! また、レビューいただいた点を反映しました! generate APIのテストが落ちているのはよくわかりませんでした... 手元では動いたけど、GitHub Actions上だとダメそうな感じで...
shpinx-autoapi
パッケージのバージョンを上げればいい...?
https://stackoverflow.com/questions/77257145/sphinx-autoapi-error-module-object-has-no-attribute-doc-with-various-sphi
generate API
v0.15ではSphinxはv6に上げることで解決してました。(https://github.com/VOICEVOX/voicevox_core/pull/626)
0.14だともうgenerate API documents
だけ :x: のまま通してしまうか、起動しないようにするというのもありかと思います。
0.15の方で質問なのですが、"sing teacher"と"sf decode"が別VVMに入ることってありそうですか? もしそうであるなら、パブリックAPIの形をちょっと考えなおす必要がありそうです(歌声を触りたい人がどれだけいるかはわかりませんが)。
たしかに、0.15(ハミング)で更新されるのはcompatible engineの部分だけで、ドキュメントに現れるAPIは1個も変わらないですね! なのでgenerate API documentは切ってしまっても確かに問題なさそう。 けどまあ後で元に戻さないといけないですし、サクッとできるなら #626 をcherry-pickするのもありかも。 どっちでも良さそう!
0.15の方で質問なのですが、"sing teacher"と"sf decode"が別VVMに入ることってありそうですか? もしそうであるなら、パブリックAPIの形をちょっと考えなおす必要がありそうです
ある想定です!
歌い方生成対応キャラ(sing teacher
)はなかなか増えないけど、ハミング対応キャラ(sf decode
)は増えていくので。
あ、あとモデルの種類が変わるとStyleIdも必ず変えるようにする予定・・・・・だったのですが、今思うとsing teacher model
とsf_decode_model
は同じStyleIdにしたくなりそうですね・・・・・・・。
(トークとハミングはStyleIdを変える、というところまでは考えてました。)
VVMでの制約について考えていなかったのですが、1つのVVM内では1つのInferenceDomainしか持てない、みたいな制約は設けられる・・・かも・・・?
歌声を触りたい人がどれだけいるかはわかりませんが
僕も需要は分かりませんが、自分が知る範囲では歌が生成できる動的ライブラリを見たことがないです。 それが無料で、有名なキャラクターもいて、マルチOS対応なものがリリースできれば、まあ結構楽しいことになるんじゃないかな~~~~と期待してます。
内容
題の通りです。 テストは一旦無視しています。 また、ダミーモデルも既存のものを適当に刺しているため、動きません。
関連 Issue
その他
各ネーミングは適当なので、後で書き換えたほうがいいかもしれない...?