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 · 29 comments
Open
45 of 69 tasks

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

qryxip opened this issue Jul 22, 2023 · 29 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
@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
Closed
@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
@Hiroshiba
Copy link
Member

Hiroshiba commented Dec 8, 2024 •
edited
Loading

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

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

  • ソング系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用ブランチではコメントアウトする

その他メモ

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

@Hiroshiba Hiroshiba mentioned this issue Dec 18, 2024
Merged
@qryxip
Copy link
Member Author

qryxip commented Dec 18, 2024 •
edited
Loading

とりあえず私としてできればやっておきたいことリストです。

  1. VOICEVOXコアのプロプライエタリ部分をonnxruntimeに逃がして別々にビルド可能にする voicevox_project#24
    • やることが残っているとすれば、VVMをどこに置くかと、ライセンス文の封入をどうするかの議論 (ビルド周りもあるけど)
  2. keep a changelog形式のchangelogを手書きする #704
    • プラス、マイグレーションガイド
    • 多分議論はほぼ要らないので、私が書けば終了のはず
    • ここは丁寧にやるだけの価値はあるはず
  3. 細かい破壊的変更は今入れておきたい
    • Rust APIのオプション引数部分をビルダースタイルにしたい
    • Rust APIのFullContextExtractorだけ、名前だけでもTextAnalyzerとかにしたい
    • Java APIのJSON周りをGSONにしたけど、Jacksonの方がよかったのでは？という気が最近している
    • UserDictが引数に取るファイルパスがstr固定だったりするのでAsRef<Path>とかにしたい (PythonとJavaも同様)
    • 同じくUserDictについてPython APIとJava APIでのgetterが、getterとして怪しいところがあるので再考したい
  4. C APIのドキュメントを書き直したい
  5. LinuxでのAMD Rocmサポート #617
  6. feat!: RunAsyncを使う #889 の影響が若干心配なので、Criterionによるベンチを書きたい
    • 将来的にはCodSpeedも使ってみたい
    • やるかどうかはともかく、issueは作ってAPIドキュメントからリンク貼りたい

@Hiroshiba
Copy link
Member

Hiroshiba commented Dec 18, 2024 •
edited
Loading

@qryxip なるほどです！

これ以上の機能追加はやめましょう後回しにしましょう･･･！！！
逆に機能が追加されない範囲で、かつこのタイミングでやるべきことはやっていくほうが良さそうに感じました。

まずqryxipさん側で優先度の高いものを進めていただいて、そのあとVVMを実際に置くとかの僕の作業で待ちが発生すると思うので、そのときに機能を足せるだけ足しちゃうのはどうでしょうか？

こんな感じかなーと

@qryxip qryxip mentioned this issue Dec 19, 2024
Open
3 tasks
@qryxip
Copy link
Member Author

qryxip commented Dec 19, 2024

個人的には VOICEVOX/voicevox_project#24 と #388 は結び付けたいと思っています。あとGitのタグをもってリリースとする以上「0.16.0時点のRust API」というのはどうしても誕生するので、隠す努力を今からするよりは公開する方で動いた方がよいのではないかと思ってます。exampleが無いのは別に許容してよいかなと（docstringにはちょくちょく書いているわけだし）。

Javaについても0.15.0-preview.16時点で既にあったと思うので、これもスキップするのは厳しそうに思えます。

@Hiroshiba
Copy link
Member

Hiroshiba commented Dec 20, 2024 •
edited
Loading

なるほどです。気持ちはわかります。

僕の考え方ですが、とにかく早く出したほうが喜ぶ人は多いだろうなーとは思います。
あとアプデで継続的にものが追加されると頑張ってることが伝わるので、あえて最初に全部搭載しない戦略を取る考え方もあるかもです。
（あと隠すのは面倒なので、まだ保証しないという体を取るのが良いと思ってます。開発中だということがわかるようになってたほうが良さそうなので、どこかで工事中の案内はあると良いかも。）

本当に大事なのは「なるべく揃えてから出す」ではなく「メイン機能をなるべく早く出す」だと思います。
リリースに時間をかけてしまって、例えば新興のTTSソフトが同じような機能を出して覇権を取ってしまったりしたら、かなりショックだと思います。
あとユーザー数は日ごとに増えるはずなので、早くリリースしてたほうが得というのもあります。
おそらくリリースしてすぐにものすごい脚光を浴びる感じじゃなく、徐々に注目される感じだと思うので、最初に全部揃ってる必要性はだいぶ低めかなと。
むしろ残ってたほうがリリースしました生放送を見てくれた人が貢献しやすいポイントが多くて良いかも。

↑を先にやっていって、他のことはそれが終わってから実装していき、リリースのタイミングはVVM周りの用意ができたらとしたいです 🙏
エディタやエンジンも「この機能が追加されたらアプデする」というより「このタイミングで実装されてる機能でアプデする」という感じなので、うまく機能すると思います。

（あとぶっちゃけ全キャラのVVM準備で相当な時間がかかる気がするので、全然余裕で時間あると思います 😇 ）

@qryxip qryxip mentioned this issue Dec 23, 2024
Merged
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