内容

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

その他