feat!: liberate VOICEVOX CORE

[qryxip]

内容

1. manifest.jsonの"…_filename"部分を変更し、.binを認識できるようにします。.binの場合、change: liberate VOICEVOX CORE ort#8で追加されるSessionBuilder::commit_from_vv_binを用います。

       "predict_duration": {
         "type": "onnx",
         "filename": "predict_duration.onnx"
       },
       "predict_intonation": {
         "type": "onnx",
         "filename": "predict_intonation.onnx"
       },
       "decode": {
         "type": "onnx",
         "filename": "decode.onnx"
       },

       "predict_duration": {
         "type": "vv-bin",
         "filename": "pd.bin"
       },
       "predict_intonation": {
         "type": "vv-bin",
         "filename": "pi.bin"
       },
       "decode": {
         "type": "vv-bin",
         "filename": "d.bin"
       },

2. Onnxruntime::LIB_NAMEを"onnxruntime"から"voicevox_onnxruntime"にします。

   compatible_engineの場合だけ、"voicevox_onnxruntime"で失敗すると"onnxruntime"にフォールバックするようにしています。
   （モック目的で使えるように）

3. change: liberate VOICEVOX CORE ort#8でログのフィルタリングをやめる代わりに、C APIのログフィルタのort=infoをort=warnにします。

   （現行のONNX Runtime v1.17.3とsample.vvmだとログが大量に出てしまいました）

4. build_and_deployのis_production周りを吹き飛ばします。

関連 Issue

Resolves VOICEVOX/voicevox_project#24.
Resolves #388.
Resolves #722.

その他

[qryxip]

a5f009c (#825)
.binの呼び方をbinからvv-binとしました。

      "type": "vv-bin",

[Hiroshiba]

draft状態ですけどちょっと見させていただきました！
コードは良さそう！！

---

製品版周りの扱いに関して相談があります！

VOICEVOXエンジンやエディタは、OSSリポジトリのreleasesで製品版をリリースしています。
コアも同じ感じにしていたのですが、このプルリクエストでis_productionフラグが消えて、一部製品版ではないものをビルドする方に倒されてるかもと感じました！

そのため製品版のonnxruntimeであるvoicevox_onnxruntimeを使っているけど、READMEは製品版のものに変えず、製品版のVVMのサポートが外れ、代わりにOSSサンプルのVVMがビルドされる形になっていそうです。
is_producrionフラグを消すのは賛成で、更に全部製品版に寄せるのが手っ取り早い気がしました。

この辺りは考え方いろいろあると思います！
とりあえずエンジンとエディターに合わせる感じとかどうかなと思い、その前提でちょっと色々コメントしてみました。

[Hiroshiba]

（ただのコメントです）
ここのフォールバックは将来必要なくなるかもですね！
まあまだ色々わからないけど。

[qryxip]

• 80345e5 (#825): 嘘コメントのリバート
• 148fa5d (#825): ↑で修正したところのコメントに従い、install_name_toolsでのrpath変更をvoicevox_onnxruntime.framework宛てに

[qryxip]

voicevox_onnxruntime自体の用意ができていませんが、多分時間がかかりそうであることを考えるとこのPRはさっさとマージした方がよいですかね？
（その場合 VOICEVOX/voicevox_project#24 と #388 のlinkを外した上でdraftを外します）

[Hiroshiba]

@qryxip ちょっと迷いどころですが、 @qryxip さんの都合に合わせてマージしてもいいと思います！

というのも、多分このプルリクエストをマージすると、製品版をビルドしてもVVMがロードできなくなるんですよね～～
別に必ずビルドする必要はないと思うので問題はないのですが、ちょっと後ろ髪を引かれる部分があるなと。

ただこのプルリクエストがマージされていないと進められないタスクもあると思うので、マージするのに反対ではないです。
本当に都合次第だと思います。

まあもしmainブランチで製品版ビルドしたものが動かない状態が微妙というところでしたら、一旦projectブランチを作ってそちらにマージするとかはありかもです。
コンフリクトが発生していくので早くなんとかしたい気持ちもありますが。

ということで、ちょっと問題は生じそうです＋とはいえ進めやすい方法でいいと思います、って感じです！

[qryxip]

そうですね… このPRによってブロックされるというタスクは多分そんなに無い気がするので、draftのままでいいのかなと思ってます。ダウンローダーもVVMについては別で進められるかと。

(projectブランチも作らなくていいのではと思ってます。結局コンフリクト解消の手間をいつ取るのかという話になりそう。)

[qryxip]

30e4b69 (#825): #913 を完遂してRust APIのpackage.licenseも設定

---

@Hiroshiba これで試せるはず？

voicevox_onnxruntimeは: /~https://github.com/VOICEVOX/onnxruntime-builder/releases/tag/voicevox_onnxruntime-999.999.999

[Hiroshiba]

LGTM！！！！

これでvoicevox_onnxruntimeを使うようになる、という理解でいます！
話として後回しになってそうなものを列挙してみました：

README周り（たぶんcore.zip内のreadmeは削除で良さそう？）
#825 (comment)

downloader周り（一旦壊れることになる･･･？いやならなさそうな気がする！）
#825 (comment)

is_productionフラグを失くす？
#825 (comment)

必要とあらば↓に書き足しておくと忘れないかも！

• [2月末リリース予定!] v0.16 #545

お疲れ様でした！！！

[qryxip]

あ、一応ですが私の手元のLinux CUDA版でも動いているっぽいです。
(style_id=0(あまあま四国めたん)でPython exampleを動かしただけですが)