Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
45 of 69 tasks
qryxip opened this issue Jul 22, 2023 · 24 comments
Open
45 of 69 tasks

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

qryxip opened this issue Jul 22, 2023 · 24 comments
Labels
OS：linux OS：mac OS：win 機能向上

Comments

@qryxip
Copy link
Member

qryxip commented Jul 22, 2023 •
edited by sevenc-nanashi
Loading

内容

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

Pros 良くなる点

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

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

Cons 悪くなる点

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

実現方法

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

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

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

VOICEVOXのバージョン

N/A

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

  • Windows
  • macOS
  • Linux

その他
@qryxip qryxip mentioned this issue Jul 22, 2023
Merged
67 tasks
@Hiroshiba
Copy link
Member

Hiroshiba commented Jul 22, 2023 •
edited
Loading

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

@Hiroshiba
Copy link
Member

Hiroshiba commented Jul 22, 2023 •
edited
Loading

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

@Hiroshiba
Copy link
Member

Hiroshiba commented Jul 22, 2023 •
edited
Loading

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

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

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

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

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

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

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

@qryxip
Copy link
Member Author

qryxip commented Jul 22, 2023 •
edited
Loading

三つとも追加しました。

@Hiroshiba
Copy link
Member

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

@qryxip
Copy link
Member Author

qryxip commented Jul 22, 2023

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

@Hiroshiba Hiroshiba mentioned this issue Jul 26, 2023
Closed
@Hiroshiba
Copy link
Member

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

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

This was referenced Jul 28, 2023
Merged
Merged
Merged
This was referenced Aug 5, 2023
Merged
Merged
@Hiroshiba
Copy link
Member

製品版の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

@qryxip qryxip mentioned this issue Aug 15, 2023
Merged
This was referenced Aug 23, 2023
Closed
Merged
@Hiroshiba Hiroshiba mentioned this issue Sep 1, 2023
Closed
@qryxip qryxip mentioned this issue Sep 5, 2023
Merged
@sevenc-nanashi sevenc-nanashi mentioned this issue Sep 16, 2023
Open
@Hiroshiba Hiroshiba mentioned this issue Sep 23, 2023
Open
3 tasks
This was referenced Sep 24, 2023
Merged
Merged
Merged
Merged
@qryxip
Copy link
Member Author

qryxip commented Nov 4, 2023

今はVoiceModelがvvmファイルのpathを持っているので責任範囲がずれてしまうように感じました。

今VoiceModelがどうなっているかというと、コンストラクトされるときに id, manifest, metasの情報だけ取得してそれらとpathだけ保持し、モデル本体は要求されてからpathを開いて読むという形になっています。こういう責務になっていることをユーザーが今のAPIのシグネチャから察することは困難だと思うので、私も考えなおした方がよいのではないかと思っています。改名に関係無く。

voicevox_core/crates/voicevox_core/src/voice_model.rs

Lines 29 to 36 in 9ae1110

pub struct VoiceModel {
/// ID。
id: VoiceModelId,
manifest: Manifest,
/// メタ情報。
metas: VoiceModelMeta,
path: PathBuf,
}

構造としては次のうちどちらかにするのがよいかと思います。

  1. 構造体Vvmはid, manifest, metasと共にモデルデータ本体([u8])を保持する。もしVvmをコンストラクトした後に元の.vvmファイルをrmしても、問題無く動き続ける。
  2. 構造体VvmFileはid, manifest, metasと、.vvmファイルのディスクリプタを保持。モデルデータは要求されてから読む。Pythonでは__aenter__/__aexit__を実装。

1.のconsとしては

  • Vvmを全部コンストラクトすると、現状でも800MBくらいRAMを圧迫することになる (ENGINEも影響を受ける)
  • エラーメッセージはどうするのか (IDでも表示する?)

というのがあると思います。個人的には2.のVvmFileがよいのではと思っています。

@Hiroshiba
Copy link
Member

Hiroshiba commented Nov 4, 2023 •
edited
Loading

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

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

@qryxip qryxip mentioned this issue Nov 5, 2023
Merged
@qryxip qryxip mentioned this issue Nov 15, 2023
Merged
@Hiroshiba Hiroshiba mentioned this issue Nov 15, 2023
Merged
This was referenced Nov 16, 2023
Merged
Draft
Merged
@Hiroshiba
Copy link
Member

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
Copy link
Member Author

qryxip commented Nov 23, 2023 •
edited
Loading

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

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

image

(素の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
Copy link
Member

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

This was referenced Nov 25, 2023
Merged
Merged
Merged
@Hiroshiba
Copy link
Member

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

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

This was referenced Dec 1, 2023
Merged
Open
@qryxip
Copy link
Member Author

qryxip commented Dec 3, 2023 •
edited
Loading

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

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

@qryxip
Copy link
Member Author

qryxip commented Dec 3, 2023

#704 も入れました。

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

@Hiroshiba
Copy link
Member

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

@Hiroshiba
Copy link
Member

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

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

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

@Hiroshiba Hiroshiba mentioned this issue Dec 5, 2023
Merged
@Hiroshiba
Copy link
Member

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

@Hiroshiba Hiroshiba changed the title [11月末リリース予定!] v0.15 [2月末リリース予定!] v0.16 Jan 22, 2024
@tarepan tarepan mentioned this issue Mar 7, 2024
Merged
@qryxip
Copy link
Member Author

qryxip commented Mar 16, 2024 •
edited
Loading

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

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

@qryxip qryxip mentioned this issue Apr 4, 2024
Open
@Hiroshiba
Copy link
Member

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

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

This was referenced Sep 7, 2024
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
OS：linux OS：mac OS：win 機能向上
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Hiroshiba @qryxip