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

[qryxip]

内容

VOICEVOX COREのバージョン0.15をリリースするにあたってのタスクリストをここにまとめます。

Pros 良くなる点

changelogを書くために、一度ここにまとめていこうと思います。

• APIが更新されます。
  • Python APIでは主要なAPiがasync化します。C APIでも並列実行をサポートする予定です。
  • 音声モデルはVVMファイルという形で扱われ、それらを実行時に明示的に読む形式となります。
  • その他諸々の改善/変更があります。
• ONNX Runtimeのバージョンが上がります。

Cons 悪くなる点

• APIに破壊的変更があります。

実現方法

タスクリストは随時更新します。

• 新APIのE2Eテスト
  • C API
    • 基本的なttsとか
    • accent_phrase系
    • get_version等
  • Python API
• C APIの健全性(soundness)の確認
  • [project-vvm-async-api] ZSTにポインタキャストして提供するのをやめる #512
  • [project-vvm-async-api] extern "C"の生ポインタをABI互換のに置き換え #514
  • C APIで&mut VoicevoxSynthesizer (VoicevoxSynthesizer*)を引数に取っている関数があるが、これを&VoicevoxSynthesizer (const VoicevoxSynthesizer*)にする
    • Rustでは&mutが複数誕生すること自体が禁忌であるため、複数スレッドからの実行を禁止する必要がある。ただ非同期実行を念頭に置いたAPIであるので、規約で禁止するよりも内部可変性 (interior mutability)を持つ方向にした方がよい。
    • mutabilityとasyncnessを仕上げる #552
• [project-vvm-async-api] whlに"modelディレクトリ"を埋め込むのをやめる #522
• async/await周りを精査する
  • モデルを実行するところとかはtokio::task::spawn_blockingで囲ったりするべきでは?
    • 音声合成の処理を丸ごとスレッド分離して実行する #692
  • [議論] プロセス分離などして、モデルの実行を同時にできるようにするべきか?
    • [調査] Synthesizerを複数コンストラクトしておけばcancellable_synthesisの機能を手直しし、「コアの並列実行機能」としてリリースする voicevox_engine#677のようにできるはずだが、それで並列実行がちゃんとできるのか?
  • IOが発生するメソッドをすべてasync化する #667
  • ONNX Runtimeとモデルのシグネチャを隔離する #675
  • 入力テンソルをvisitor patternで捌く #680
• 間違ったchar*の解放を明示的に拒否する #500と[project-vvm-async-api] いくつかのC関数を定数にする #503を噛み合わせる ([project-vvm-async-api] mainをマージする #516 (comment))
  [project-vvm-async-api] Fix up #500 #521
• [バグ] Python APIで__init__.pyでのre-exportからStyleMetaが漏れている
• APIの形について
  • [議論] 文字列の_free系のAPIについて (新クラス設計API #370 (comment))
  • [project-vvm-async-api] voicevox_{,synthesizer_}is_loaded_voice_model #523
  • [議論] voicevox_synthesizer_audio_query → voicevox_synthesizer_create_audio_query? (新クラス設計API #370 (comment))
  • [project-vvm-async-api] いくつかのC関数を定数にする #503
  • [project-vvm-async-api] get_supported_devices_jsonをfallibleに #502
  • [議論] Open JTalkは"text analyzer"のように抽象化した方がいいのではないか? (名前の破壊的変更をやるなら今がベスト)
  • [議論] ロガーの初期化はオプションなりで明示的にする?
    • アイデア：C APIで、stderr以外からログを受け取れるようにする #556
      延期
    • Java API：ログをSystem.Logger経由で吐くようにする #592
  • [project-vvm-async-api] C/Python APIクレート側のバージョンを出す #507
  • cbindgenがextern constへのコメントを吐いてくれないので、調査して対応を考える ([project-vvm-async-api] いくつかのC関数を定数にする #503 (comment))
  • cbindgenが荒ぶってアイテムの順序が変わるので、sort_by = trueにしてアルファベット順にするのはどうか? ([project-vvm-async-api] いくつかのC関数を定数にする #503 (comment))
  • [議論] Python APIでstyle_idとかが生のintのままだが、Rust API内のようにnewtype化すべきでは?
    • Python APIにNewTypeを導入 #678
  • [議論] 各所のnew_with_initializeは単なるnewでいいのでは?
    • "new_with_initialize" → "new" #669
  • [議論] OpenJtalkってよく考えたらOpenjtalkかOpenJTalk(pyopenjtalkはこれ)であるべきでは?
  • [議論] C APIにOpenTtalkRcがあるが、肝心の「参照カウント型としての複製」のAPIが無いのでは?
  • [議論] OpenJtalkRcをOpenJtalkにしたり、APIの名称から_rcを省いても良いのでは？
  • kana: boolをやめ、"_from_kana"を復活させる #577
  • Change!: C APIの名前を少し変更 #576
  • [議論] inference_coreとstatusの役割が似ているのでどちらかに統一する？
    • SynthesisEngineとInferenceCoreを解体する #686
  • Synthesisのload_all_modelsを廃止する #582
    • load_all_modelsを廃止する #587
  • VVMをまとめて読み込むショートハンドを用意する #588
  • エラー
    • VoicevoxResultCodeをC APIに移動 #580
    • Rust APIが公開するエラーの種類をErrorKindとして表現する #589
    • C APIのエラー表示をtracing::error!にする #600
    • InvalidStyleId, InvalidModelId, UnknownWordを…NotFoundにする #622
    • UnloadedModel → ModelNotFound #623
    • エラーメッセージにおけるcontextとsourceを明確に区分する #624
    • C APIのセーフティネットのメッセージを改善する #625
    • Error::InferenceFailedにsourceとしてOrtErrorを持たせる #668
• VVMのマニフェストの形式の再考 #581
• ドキュメント
  • [project-vvm-async-api] ドキュメントの表記ゆれを解消 #501
    • (Voicevox)Synthesizerのはずだが、ドキュメントではいくつかVoiceSynthesizerのままになっている
    • 「音声合成モデル」と「音声モデル」で表記ゆれ
  • # ドキュメントを刷新する #532
    • example下の"speaker_id"を、"style_id"に直す #562
    • APIドキュメントにコード例を書く #563
    • APIが投げうるエラーについて網羅的にまとめてAPIドキュメントに書く #564
  • VVMのマニフェストのデータ構造に関してメモをどこかに書く
• APIの変化についてドキュメントを残す(keep a changelog形式のような手書きのリリースノートとか)
  • keep a changelog形式のchangelogを手書きする #704

タスクリスト (オプショナル)

• 以前のAPIをdeprecatedなものとして残す
  • C API
  • Python API

VOICEVOXのバージョン

N/A

OSの種類/ディストリ/バージョン

• Windows
• macOS
• Linux

その他

[Hiroshiba]

[議論]となっているいくつかはこちらのコメントで少し議論が進んでいるのでメモ。
#497 (comment)
#497 (comment)

[Hiroshiba]

exampleの案内もタスクに含めておくと良いのかなとちょっと思いました！
と思ったけどもうexampleは完成している･･･？

[Hiroshiba]

メモです！
inference_coreとstatusはやっているがかなり似ているので、どっちかに統一できると良さそうに感じました。
まあリリースまでにやるべきか微妙ですが、例えばタスクリストに書いておくのはいいかも？

- [ ] \[議論\] `inference_core`と`status`の役割が似ているのでどちらかに統一する？

---

開発者向けに、VVMのマニフェストの構造に関してのメモがどこかにあると良いなと感じました。

- [ ] VVMのマニフェストのデータ構造に関してメモをどこかに書く

（とりあえずissueの編集がコンフリクトすると良くないのでここにメモって書いています）

---

Pythonのテストを書くのもここに含めておくと良さそう？

- [ ] Pythonのe2eテストを書く

[qryxip]

三つとも追加しました。

[Hiroshiba]

追加ありがとうございます！
（editedになってない＆見当たらないので、もしかしたら追加されてないかも･･････？）

[qryxip]

あ、確定してませんでした...

[Hiroshiba]

実際に製品版のVVMを作ろうとしていたのですが、以前できていたことができなくなっていることに気づきました。
ということでissue立ててみました。時間ある時にやっておこうかなと思います。

• [vvm] styleIdとsession.runに渡す数値が異なっているVVMでも音声合成できるようにする #548

マニフェストファイルって本来、対象がどういう情報を持っているかを外向けに公開するものな気がしてきました。バージョンとか名前とか。
だからどちらかというとmetas.jsonの方がマニフェストっぽくて、今manifest.jsonとなっているものはなんか別のものな気がしました。
時間あったらこの辺整理してもいいかもですね。。

[Hiroshiba]

製品版のvvmファイルを作成したので共有です！
ここにあるディレクトにあるvvmファイルが読めるはずです。
https://github.com/VOICEVOX/voicevox_fat_resource/tree/main/core/model

このvvmを読めるコアをプレビュービルド中です。
https://github.com/VOICEVOX/voicevox_core/releases/tag/0.15.0-preview.5

[Hiroshiba]

なるほどです！少なくともデメリットが大きいので1は避けたい…！
2ですが、ファイルディスクリプタはユーザーに露出させない（privateにする）のもありかも…？

個人的には2の方針にプラスで、ファイルディスクリプタはプライベート変数で持たせて、ファイルへの参照を持ってることはドキュメントで案内しつつ、load等はRust API内で完結させるのがメンテの面で楽かなと思いました！

[Hiroshiba]

0.15リリース時にユーザー向けのドキュメントを１ファイルほど追加しようかなと考えてて、まだ固まってないのですがメモ書きがてら共有＆相談です 🙏

何が必要か・どこに書くかを考えてたんですが、とりあえず./docsの下にhow_to_use.mdみたいなの作ってリポジトリREADMEから飛ばす形が良いのかなと思ったのですがどうでしょう？
C API/index.htmlに書き足す形でも良さそうなのですが、他の言語のAPIにも言及しやすいのと、別にC特有の言及がほとんどないのでC API下である必要があまりないなぁと。
あるいはhttps://voicevox.github.io/voicevox_core/apis/でも良いのですが、デザインを考える必要が出てくるのと、別にGithub内にドキュメントがあってもまだ不思議じゃないかなぁと。
（将来的に方針がしっかり固まってからドキュメント用のページをしっかり作るのはあり。まず簡単に./docs下に、みたいな。）

書く内容の候補は「コアを使いたい人が使い方の流れがわかるもの」にしようかなと。
書く内容はこんな感じかなと。

• そもそも何ができるのか
• 環境構築はどうすればいいのか（Pythonで説明予定）
• SynthesizerとVVMとは何なのか
• 実際に音声合成する方法
• 調整を変更する方法
• キャラクターを変える方法

何にせよ、とりあえず1回書いてみないとちょっとわかんないなと思っています。方針としておかしな点とか考慮すべき点とかあれば 🙏

[qryxip]

API referenceと独立して作るのは良いと思います。docs下に置くなら慣習的な名前だとusage.md, quickstart.md, guide.mdあたりでしょうか? 個人的にはguide.mdに一票を入れたいと思ってます。

コード例などが混じる言語依存の説明については、 Cを除く Cを含めた 全言語で併記するのも無理ではないように思っています。例えばPolarsのUser guideの構成が参考になると思っています。

(素のGFMだと流石に厳しいため、docs下に書くうちはPythonのみになるとは思います)

素のGFMでもこんな感じでいけるかと。

Python

from voicevox_core import Synthesizer

Rust

use voicevox_core.Synthesizer;

Java

import jp.hiroshiba.voicevoxcore.Synthesizer;

C

#include "./path/to/voicevox_core.h"

[Hiroshiba]

自分もいろんな言語でのコードサンプルを書くのに賛成です！
でも一番初めはとりあえず1つの簡単めな言語だけでドキュメントを作るところから始めるのがいいかなと思ってます！

[Hiroshiba]

@qryxip 11月末のリリースは難しかったのですが、いつ頃ならリリースできそうでしょうか 👀
一応自分のタスクとしてはここにメモっていて、それ以外でここはマストで変えておいた方がいいものを全て完了するのがいつになるかな～～～と･･･！

（なんとなくリストを眺めていて必須なのはあと「VVMマニフェストの見直し」だけかもと思ったのですが、どうでしょうか･･･？）

[qryxip]

このあたりはやっておいた方がよいかなと思いました。

• VoiceModel → VoiceModelFile ([2月末リリース予定!] v0.16 #545 (comment)、issue未作成)
• "OpenJtalk" → "OpenJTalk" (あるいは"Openjtalk") (issue未作成)
• OpenJtalkRcのRcを外す (issue未作成)
• Javaの"style id"とかを、RustとPython同様にnewtype化する (issue未作成)

[qryxip]

#704 も入れました。

 - [ ] APIの変化についてドキュメントを残す([keep a changelog形式](https://keepachangelog.com/en/1.1.0/)のような手書きのリリースノートとか)
+    - [ ] #704

[Hiroshiba]

@qryxip それら5つに関しての優先度感的には、全部shouldとwantの間ぐらいかなと思いました！
あった方がいいけど、無いままリリースするのもやぶさかではない、みたいな･･･！
（将来たぶん変更するような内容ですし、できる限り実装してあげたいですが･･･）

[Hiroshiba]

スケジュールの引き直しをしたいのですが、12月の後半と1月いっぱいはVOICEVOX全体が他のタスクでいっぱいいっぱいになる予感がしていて、そこらあたりのリリース予定を現状で立てづらいという思いがあります。
となると予定の立て方としては次の3つがありそうです。

1. 12月前半の最後の12月15日リリース予定にする
2. 2月以降のリリース予定にする
3. あげられた5つの項目（＋マニフェストの更新）が揃ったらリリースする

@qryxip さん的な思いを伺えると嬉しいです･･･！ 🙇

[Hiroshiba]

予定のバージョンとリリース予定日が変わったので、タイトルをちょっと変えさせていただきます！
ちなみにバージョンは0.16、リリース日は2月末を予定してます！！

[qryxip]

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

• 予定は次の通り。残りはベストエフォート
  • 2024-03-10 (日) project-s ブランチをmainブランチにマージしたい #737 (@qryxip)
  • 2024-03-17 (日) VVMのマニフェストの形式の再考 #581 (comment)に従ってVVMのmanifest.json更新 (@qryxip)
  • 2024-03-17 (日) VVM・asyncのドキュメントが見終わっている (@Hiroshiba)
  • 2024-03-24 (日) VVMモデルの更新 (@Hiroshiba)
  • 2024-03-29 (金) コア0.16リリース
  • 2024-03-30 (土) OSS生放送

---

ただし今となっては、これより遅れる予定。

[Hiroshiba]

最近のVOICEVOX COREの開発優先度についてヒホと @qryxip で議論したののメモ

• 優先度が高いものはない
  • 強いて言うならエンジンビルドを簡単にしたいが、ソングmergeとプロプラonnxruntimeが必要になり、遠い
  • であれば、qryxipさんが描くやっときたい順序どおりでOK
  • プロプラonnxruntime制作を続行
• ノンプロプラ・プロプラ版のonnxruntime.dllが２ついる
  • ノンプロプラ版は公式に配布されてるonnxruntime.dllでも良さそう
• 同じ名前にして配布する
  • 別の名前にすると、iOS版も考慮すると静的・動的×名前２種類になって大変になるから
• 名前はなんでもいい、何でも良いならlibvoicevox_onnxruntime.dllとかが良い
  • 内臓のonnxruntime.dllを参照しないようにするため
• 見分けがつけられるようにする、プロプラ版の方だけでシンボルをexportする
  • DIRECTMLのPyInstallerのなんかで設定したやつみたいに

[Hiroshiba]

こちらの方針について、ちょっと生放送で議論していたのでメモ。

リリースにあたって考える事項の整理。

• ソング系API
  • compatible engine含め、0.16に含めない
  • voicevox_onnxruntimeができればコアのアップデートはめちゃくちゃ気軽に行える
  • リリースした直後にマイナーバージョンでも良いからアップデートすればエンジンから使えるようになる
• Node版
  • マージしたい気持ちはあるが、グッとこらえて後回しにする
  • 0.16に含めたいというより、メンテナンス性の観点から早めにマージしたい気持ちが大きい
  • であれば0.16をリリースしてすぐにマージを目指すのでも良い
• マイグレーションガイド
  • 書いても良さそう。
  • でもまあドキュメント見てもらえればわかるっちゃわかりそう
• render API系
  • シグネチャーや関数名がまだ完全にfixしてない
    • (compatible engineはほぼfixしてる)
  • 別言語での実装もまだ
  • ということで0.16での実装は見送る
  • Python APIが露出するので、mainブランチにはそのままにしつつ、0.16用ブランチではコメントアウトする

その他メモ

• リリースはこまめに行わないと、新機能リリースを行えなくなるので、こまめにリリースするべき
  • 依存ライブラリのアップデートと一緒
    • こまめにアップデートするのは使いたい機能が入った時にすぐにアップデートできるようにするため
• これ以上項目をなるべく増やさないで、太らないようにする