Conversation
|
提出してから気づきましたが 休符のフレーム長が 45ではないので 楽譜とちがっていました。（明日以降修正します） |
There was a problem hiding this comment.
プルリクエストありがとうございます！！！
丁寧に書かれていてすごいいい感じだと感じました！！！
一旦大枠で読ませていただき、こうしたらより良いかも？と思ったことをコメントさせていただきます･･･！！
流れの整理
ちょっとこれは相談したいのですが、最初に考え方の流れがあるとわかりやすそうかもと思いました！
楽譜→楽譜データ→歌い方データ→歌声という流れで進む、というのが最初にあれば良いかもと。
（もしかしたらこの説明は不要なのかもなので、意見をお伺いしたいです！）
アクセスポイントの取得はエディタの話なので、ここでは軽く説明する方がよいかもと思いました！
GUIのあるVOICEVOXソフトウェアで起動しているエンジンを叩く場合はアクセスポイントが変わる、というのを最後の方に案内するだけでも良いかも･･･？
あとはエディターのドキュメントへのリンクがあると良いかも？
（ファイル名が変わったりしていつのまにかリンク切れになっちゃいそうですが。。。）
あと楽譜はもしかしたら読めない人もまぁまぁいるのではとか思いました！
なので、情報を箇条書きで書いてあげると後の話がわかりやすいかも。「BPMが125」とか、４分休符→４分音符×３→４分休符とか！
それと歌詞は「ドレミ」だと音階なのか歌詞なのかわからないので「テスト」とかもありかも。
文章構造は↓の感じとかどうでしょう。
データを作るところでそのデータを作るための情報の取得方法を説明する、という流れにしてみました。
あまり文章は得意ではないのでちょっと自信ないですが･･･
- （はじめの概要）
- このドキュメントで何を説明するかの紹介
- APIの送信例
- データの流れ
- 楽譜→楽譜データ→歌い方データ→歌声音声
- 楽譜データを作る
- サンプル楽譜紹介
- 計算に必要な数値の取得
- 楽譜用JSONデータの作成
- 歌い方データを作る
/singersのtypeがsingなものが対応してること- クエリの生成
- 歌声音声を作る
/singersのtypeがsingとframe_decodeなものが対応してること- 歌声の生成
記法の整理
APIエンドポイント(/frame_synthesisなど)とjsonキー(typeなど)と値(nullなど)はコードブロックで囲うと見やすそう。
（それを意図されてそうだけど、バッククォート がふたつあってレンダリングが変になってる･･･？）
例示は「」で囲うようにして見分けられるようにすると見やすそう（60秒あたり 125 回叩かれるリズムなど）
用語の整理
提案されている用語がとても良い感じだと思いました！！
（クエリデータ）となってるとこだけ、（APIドキュメントでは「歌唱音声合成用のクエリ」）と１回だけ説明で良さそうかもです。
あ、歌声は「歌声音声」とするとこれが目的なことがわかりやすいかも！
あとIDとしてる部分は全部スタイルIDに統一するとわかりやすいかも･･･？
（speaker UUIDもあるので･･･）
|
査読ありがとうございます（配信も先程みました） |
内容
#1142 で会話したドキュメントを書き起こしてみました。
過不足含めて会話できれば幸いです。
関連 Issue
ref #1142
スクリーンショット・動画など
その他