コア（共有ライブラリ）の読み込みにおいてコアの API 変更に追従する #454
Comments
github-actions
bot
added
OS 依存：linux
|
いま qryxip さんがpython wrapperを作るためのPRを作ってるのでengineからはそっちを使用したほうがよいかもしれません |
確かに、デフォルトはコアの共有ライブラリを直接ロードするのではなく PyO3 で作ったモジュールを使用する、という方が良さそうですね！ リリース版のエンジンをデフォルトの設定で使う場合はそれで対応できそうです。 一方、過去のコアや開発版のコアを （おそらく、複数のバージョンのコアを読み込める仕様をこの先も維持する場合、そのコストは増加し続けそうです。個人的には、あるバージョンのエンジンはその時点の最新のコアのみを使用することにする、ということにしても良いような気がしています。 |
と書いたのですが、複数の voicevox_engine が立ち上がっているのは想定されてなかったかも……？ あまりよくわかっていないで書いてしまいました、すみません。 |
|
バージョンを指定する機能に関してですが、読み上げ等でもキャラごとにバージョンを変えたい要望がある場合は、エンジン側（かコア側）に切り替え機能があると喜ばれそうに思いました！ （ちなみに過去バージョン切り替えなのですが、近い将来に全キャラのイントネーションが若干変わる？可能性があって、そのタイミングで必須になりそうに感じています。 |
なるほどです！ それであれば、やはりコアのロードの仕組みには手を入れる必要がありそうですね（PyO3 版は、音声のモデルとコアがまだ分離できていない関係上、複数のバージョンのモデルを切り替える手段を持てないと思うので）。
|
|
すみません、metas にバージョン情報が入っているのをすっかり失念していました……。大丈夫でした！ |
|
Rust 版のコアは |
これそもそもなんですがRust C API版でも大きく前とAPIが変わってますのでRust python API版とそこまでやりやすさは変わらないのではないかと思います。 |
現状の設計の python 版では複数のバージョンの python 版コアを同居させられない（特にビルドされたエンジンで）と思うので、コアのバージョン 0.15 以降を使用するエンジンで過去の python 版コアが使用できなくなると思います（間違っていたらすみません。ただ、これが正しければ python 版ではやりやすさの観点の前に、複数のバージョンの python 版コアを同時に扱うことが現状は不可能だと思います）。なので共有ライブラリをロードできるようにする機能はコアのバージョン 0.14 以降でも必要になってくると思います。このことから、共有ライブラリのロードの仕組みに手を入れるかどうかは
ということを書きました。そして #454 (comment) よりこの機能は維持した方がよさそう（今のところ代替案がない）であり、コアをロードする前にコアのバージョンを知るための何らかの対応策がどうしても必要になる、ということです。 補足：python 版コアをエンジンに導入することに反対している訳ではないです（むしろ賛成です！）。ただし、python 版コアで複数のバージョンの音声モデルを扱う仕組みができるまでは、共有ライブラリをロードする方法も（新しいコアのバージョンに対しても）維持する必要がある、ということを言いたかった感じです。 |
|
もうちょっと考えたのですが、0.14 のコアをデフォルトで使うエンジンについては、共有ライブラリ経由で読み込みたいコアは 0.13 以前のバージョンだと思うので、デフォルトで使用するコアは python 版を使うとして、共有ライブラリ経由の読み込みはまだ急いで対応する必要はなさそうですね！ |
|
pythonについては詳しくないのですが、 動的にimportを行えば良いのかなと思ってたのですがこれだとだめですかね？ |
なるほど、そういう仕組みもあるんですね……（ありがとうございます）。もし上手くいくなら、そちらの方が良いかもしれません！ |
|
いったんバージョン判定の件ですが、先にバージョンを知るのを迂回できる方法として、例えば新APIと過去API用のコアラッパーを用意して、片方でロードできなければもう片方でロードをtryする、というのを思いつきました！ |
|
あ！ そもそもcoreディレクトリにVERSIONファイルがあるので、これでバージョン判定できるかも･･･？ |
|
辞書機能やAudioQuery機能などに関して、互換性維持の観点を完全に念頭から外れていろんな提案をしていました、すみません 🙇♂️ 過去のコアの互換性を考えると、辞書機能やAudioQuery作成などの機能は全てエンジン側に必要になります。 考慮漏れでした、申し訳ないです 🙇 |
わかりました！（多分 Discord で話されていた話題についてですね？）個人的にも、コア側の辞書や AudioQuery 機能を使うようにするのは変化が大きすぎると感じたので、最終的にどんな形になるかはともかく、新しいコアについてもまずは既存の仕組みに組み込むことを目指すのが良さそうだと思いました。 新しいコアに対応する作業工程についてですが、 #454 (comment) や VOICEVOX/voicevox_core#266 (comment) の提案の通り、最初から python API 版コアのみに対応をしぼるということも考えられます。 ただ、新しいコアへの対応にあたって既存のコアのロードの仕組みをちょっとリファクタしておきたいという気持ちがあり、その過程で、まずは共有ライブラリ版コアの読み込みの方でも新しいコアに対応させる方が、移行のやり方としてなだらかでやりやすいと感じています。 共有ライブラリ版コアのバージョン判定の仕組みについては、次のバージョン以降は #454 (comment) の提案の通り、コアの VERSION ファイルを使用するというのが最もシンプルで良さそうと感じました。仕組みとしては以下のようなものを考えています：
現在、エンジンのビルドでは VERSION ファイルを同梱するようにはなっていないので、次のリリースでも共有ライブラリ版コア (core.dll) を使用する場合、含めるようにする必要があります。ただし、ビルド済みエンジンと一緒に VERSION ファイルを同梱すると、それがコアのバージョンなのかエンジンのバージョンなのかわからなくなってしまうので、VOICEVOX_CORE_VERSION などのようにリネームして同梱するのが良いと感じました。 （python API 版も利用可能になった時点で利用したいですが、例えば過去バージョンの python API 版コアの wheel を動的に読み込む方法があるのかどうかまだわかっていません。python API 版コアは内部で numpy や pydantic に依存しているので、それらのバージョンを更新した時に複数のバージョンを共存できるかどうかについて自信がないです……。ぱっと見では、wheel にこれらの依存ライブラリが同梱されているようにも見えませんでした。python API 版の動的読み込みが現実的でない場合は、最新バージョンのコアだけ pip でインストールして使う形になると想像しています。） 追記： VOICEVOX/voicevox_core#256 がマージされたら共有ライブラリの名前が voicevox_core.dll だったら rust 版というように判断できることに気が付きましたが、今後も仕様変更はあり得るので、VERSION ファイルを利用するのが良さそうという考えは今のところそのままです。 |
|
本 issue は以下の複数課題を扱っているかと思います： A. コアAPI変更に追従した現行機能の維持 このうち A および B は関係者の尽力により現在解決されています。 @Hiroshiba Q. 開発方針「VOICEVOX ENGINE は VOICEVOX CORE の全機能に追従していく」は存在するか否か 回答がNOの場合、課題 C は都度個別 issue で議論されるのが適切なため、本 issue は目標達成、close可能かと思います。 |
|
@tarepan
将来的には分かりませんが、このissueの目的はコア0.14への対応（これ）が目的で、コア0.14の全機能には一旦追従しないということになりそうです。 なのでこのissueは完了の形でcloseさせていただこうと思います！ @PickledChair さん、改めてありがとうございました！！！ |
内容
VOICEVOX/voicevox_core#217 がマージされたことにより、コアの API に破壊的変更を伴う改善が入りました。次のバージョンのリリースまでにこの新しい API に対応する必要があります（API の戻り値が
VoicevoxResultCodeに統一されたり、一部の関数が消えたりリネームされたりなど結構変わりました）。作業や考えるべきことがいくつかありそうだったので「実現方法」の欄にリストアップしました。Pros 良くなる点
新しいコアが使える
Cons 悪くなる点
コアのバージョンの自動判別がこれまで以上にややこしくなる
実現方法
思いついた範囲では以下のようなことが考えられました（他に考慮すべきことがあったり、もっと良い対応方法があったりした場合は提案をいただけると助かります！）。
CoreWrapperを実装するCoreWrapperを用いているが、単純にこれに新 API 対応のコードを追加するとコードが肥大すると思うので、別のクラスに実装を分けた方が良い？SynthesisEngineBaseのように抽象基底クラスを定義してそれを継承する実装にするのも良いかもしれない。VOICEVOXのバージョン
0.14.0 リリースまでに実装？
OSの種類/ディストリ/バージョン
その他
VOICEVOX/voicevox_core#213 の作業に関連しています。この Issue には他に #438 （pyopenjtalk の扱う文字コードを新しい openjtalk に合わせて UTF-8 にする）も関係しています。
The text was updated successfully, but these errors were encountered: