ソング：シング側の色を揃える・正式な定義

[romot-co]

内容

初期リリース版より各所の色をきっちり・より見やすく調整・定義する
また、新テーマに沿った形にする

Pros 良くなる点

• さらに見やすく
• ボイス側と揃う

Cons 悪くなる点

なし

実現方法

• 全般: プライマリコンテナ(必要？)
• 全般: オンプライマリコンテナ(必要？)
• 全般: ニュートラル(必要？)
• 全般: インバースロール(必要？)
• 全般: ニュートラルバリアント(必要？)
• 全般: 薄めテキストカラーを定義(Medium Emphasis) → やるかどうかすり合わせる
• 全般: disabledカラーの定義(あるか確認)
• 全般: 選択カラー
• ライト: ピアノロールの背景カラーおよびグリッドライン
• ダーク: ピアノロールの背景カラーおよびグリッドライン
• 歌詞: コントラストを弱める

VOICEVOXのバージョン

0.1.6

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

• Windows
• macOS
• Linux

その他

[Hiroshiba]

issue作成ありがとうございます！

「必要？」となっているところの決め方が難しいですね！！
実際に作ってみての判断がやりやすいのかなと思いました。

今はthemesのjsonファイルにどんな色を足そうか検討されている状況でしょうか？

色の調整の優先順位としては、設計はどうあれ実装してリリースするのが優先度高いかもです。
jsonに書き足すか書き足さないかを考え始めるとかなり時間がかかっちゃいそうなので、とりあえず適当にprimaryとかdarkとかlightの色定義だけして、あとはcolor.scssの:rootのとこで色Aと色Bをmixしてとにかく見た目を作ってみる、とかが進みやすいかもとか思いました！
（もちろん最小構成要素を最初から考えてtheme.jsonに足すとか考えるのもありだとは思います）

（これは完全に余談ですが、最終的にカラーテーマを自分で決められるようなものを考える場合、 A と B を混ぜればできるような色は自動的に決まった方が楽な気もちょっとします。オプショナルとかにしてもいいかも。）

[romot-co]

@Hiroshiba
ありがとうございます、承知しました！

検討したのですが、まず追加としては

• ピアノロール黒鍵
• ピアノロール白鍵

※ 特に黒鍵は、白鍵に対し色が違うのに黒鍵であるという意味しかなく、他UI要素と異なるので別定義

だけ決められればと思います。
他の要素はすでにあるカラーから計算で出せればと！

UI色の計算には以下使ってしまっても
https://m3.material.io/theme-builder

[sevenc-nanashi]

全般: disabledカラーの定義(あるか確認)

Quasarのdisabledクラスを使ってたはずです。
基本的にはいらなさそう？

[romot-co]

@sevenc-nanashi
ありがとうございます！disabledはいらなそうです！

いちおうざっくり確認した限りでは、

• 基本、MaterialDesign2準拠(primary,surface,display...など)
• ほかQuasarのCSSクラスを使用している

という感じ？かなと思うので、鍵盤など必要なもののみ追加しようかなと…！

[romot-co]

考慮事項:

ライトにおいてツールバーはブランドカラー(薄い)もしくはトークに揃えるにしてもいいかも
ライトにおいてピアノロールを白基調に(上というか編集可能なメインエリア)

ダークにおいてはピアノロールは色調整中

[romot-co]

色やらをだいたいつくった
MaterialDesign3ベースにあわせる・計算で出力・ピアノロール周辺だけ定義する

→ もうちょいトーン落としたほうがVOICEVOX感出ると思うものの、ピアノロールだけ定義をまとめる

ライト

ダーク

ライトバリエーション

ダークバリエーション

[romot-co]

定義したほうがよさそうな要素:

• ピアノ鍵盤(黒鍵・白鍵)
• ピアノロール背景(黒鍵・白鍵)

↓以下、以前のものから追加

• ピアノロールグリッドライン(オクターブおよび小節)
• ピアノロールグリッドライン(拍)
• ピアノロールグリッドライン(スナップ)
• ルーラー背景
• ルーラーグリッドライン(オクターブおよび小節)
• ルーラーグリッドライン(拍)
• 再生位置ポジション
• ノート
• ノートのドラッグプレビュー
• 音素
• ノート単位の音域補正

入力アクティブやエラーなどは一般にあわせる
ピッチは表示・選択時・編集時・編集前のライン(波線部)などがありそうだが、UI決まっていないためいったんなし

[romot-co]

こちらを先(実装中)

[romot-co]

下部ツールバーの場合の構成案1

[romot-co]

下ペインおいたらつらいな

[romot-co]

現状のダークにおいた場合(もうちょい調整いりそう)

[Hiroshiba]

（ただのコメントです）

下ペインおいたらつらいな

下ペイン、意外と万能UIって感じじゃないかもですね･･･！！
かといって利便性が下がってるはずはなさそうなので･･･違和感はデザイン面かなぁ、思ってた以上に窮屈に感じるかも･･･？

色合い良さそうですね！
VOICEVOXのprimary colorは結構扱いづらいと思うので、どうしても難しかったら避けるのも仕方ないかもとちょっと思いました。

[romot-co]

一部導入済み

カラーについてはMaterialDesign3のもの互換(ロールを作成し割り当てる)とし
material-color-utilsで計算して出力できるようにする

ノートやシーケンサー、ルーラーなどMaterialDesign3には含まれていないデザイントークンを定義する

[romot-co]

調整中…

ためしにM3っぽく動的色変更(ソースカラーを選べばできそう)

[Hiroshiba]

キャラクターごとに色が変わるの面白いですね！！
マルチトラック考えるとグローバルな部分の色が変わるのはチカチカするかもですが、ノートの色が変わるのは可愛くて良いかも･･･？

[sevenc-nanashi]

マルチトラックの他トラックのノートの表示にも良さそう>キャラクターごとにノート色

[romot-co]

(仕掛かり / いろいろ崩れている)

[Hiroshiba]

おーシンプル！！　左上のキャラと調整値を１つにくっつけるのなるほどです！！
調整中かもですが、ライトモードのスナップのとことかのボタン？がdisableっぽく見えちゃうかも？
（せっかくコメントいただいたのでコメントしてみた次第です！　気にし過ぎかもです 🙇 ）

[romot-co]

@Hiroshiba
ありがとうございます！
スナップやノートなど調整できればと思います！(Quasarの修正に苦戦中…

[sevenc-nanashi]

実験として、マルチトラックでキャラクター毎にノート色を変えてみました。（雑実装ですが）
かなりかわいくて個人的には好きです、なおキャラクター毎の色を取得する処理を考えると...って感じです

（色は https://github.com/sevenc-nanashi/theme-color-extractor で決めました、立ち絵のピクセルに彩度・明度・透明度で重みを付けて軽く補正した平均です。権利者が決めてないときのフォールバックとしてよさそうではある）

[romot-co]

@sevenc-nanashi
おお！すごい…！
どっちにしてもトラックごとに色変えたいというの出てくる気がするので、あったほうがよさそうかも

[romot-co]

進捗進捗(ツールバーのパーツを一応そろえる)

[Hiroshiba]

あんまり大面積だとビッカビカになるので、文字+枠と考えて、文字と枠が目立てばよさそう

なるほどです！！
そうなんですよね、ノート全体がどぎつい色だとそれはそれで大変だよなぁとは感じます。。。 😇

テキストはできればLc60以上・UIの主要要素やアイコンについてはLc30狙うあたりがよさそうかなーと…！
(問題あればお知らせください

WCAGの1.4.11によるとボタン等（というより非テキストのコントラスト）はコントラスト比3:1が良い的なことが書いていて、
読んだブログにLc60がWCAGの3:1互換だと書いてたので、
んじゃボタンもノートもLc60相当が良いのかな～～～と思った次第でした！！

ただ正直なところ3:1はボタンには相当ビビットだと思うのと、あとノートは数がやたらめった多いので話が違う気がするのとで、そこまでコントラスト大きくなくても良い気はしてます！！

---

そういえばVoisona（CeVIO）は背景色もカラフルだったを思い出したので、試しにコントラスト比調べてみました。
非選択色はLc-38くらい、選択色はLc-72くらいでした！

直感、塗りつぶしならLc30くらいあれば良さそう感！！（枠の場合は不明）
でもまあコントラスト比は目安だと思うので、結構チャレンジングなデザインにしちゃってもいいかも･････？

[romot-co]

@Hiroshiba
ありがとうございます！

WCAGの1.4.11によるとボタン等（というより非テキストのコントラスト）はコントラスト比3:1が良い的なことが書いていて、
読んだブログにLc60がWCAGの3:1互換だと書いてたので、
んじゃボタンもノートもLc60相当が良いのかな～～～と思った次第でした！！

確かに！WCAG2の3:1互換でLc60というの基準になりそうです！
Lc60でなるべく揃えていければ…！

---

たぶんすべてでコントラスト確保しようとすると
重要度の階層がよくわからなくなる気がする＆追加していくと破綻しそうなので
いちおう以下のような考え方でいます！

UIとしてはボタンたくさんというよりスプレッドシートとかの方が近いかなあ、などと

あとは小さいラベルとかはコントラストとサイズの両方でアウトなので…どうしよう

[Hiroshiba]

おーーー良さそう！！！！

色々ありそう

範囲選択とか、あとRomotさんがどこかで仰ってた「他のトラックのノートを選択可能な状態で描く」とかも考えられるかもですねぇ･･･ 😇

小さいラベルとかはコントラストとサイズの両方でアウト

小節数とかC4とかですよね。　いやーーーむずいですね。。。。
太字にして必要なLcを下げれば意外とデザイン的な印象は崩れなかったりしないかな･･･。
いったんこのままでも必要な人には情報が伝わる気もする･･･。

[romot-co]

@Hiroshiba
色々出てきそうではあります…

小節数とかC4とかですよね。　いやーーーむずいですね。。。。
太字にして必要なLcを下げれば意外とデザイン的な印象は崩れなかったりしないかな･･･。
いったんこのままでも必要な人には情報が伝わる気もする･･･。

こちらよさそうです！やってみます

[romot-co]

進捗:
わずかに進める

[romot-co]

赤色覚異常

緑色覚異常

青色覚異常

全色覚異常

コントラスト

[Hiroshiba]

（ただのコメントですが）良い感じに思います！！！

[romot-co]

進捗:
SCSSに出力(結果は同じはず)

たぶんCSSでもいけそうではあるが構文がややこしい

## 利用

background-color: var(--scheme-color-primary);
color: var(--scheme-color-on-primary);

## カスタマイズサンプル

50%明度プライマリ:
  color: oklch(var(--lr-50) var(--primary-c) var(--primary-h));

50%明度プライマリ(相対)
  color: oklch(from var(--primary-key) l calc(var(--lr-50)));

ロールカラー定義(on-primaryを相対)
  --on-primary-dark: oklch(var(--lr-10) var(--primary-c) var(--primary-h));

エイリアス
  --sing-piano-key-white-dark: oklch(var(--lr-70) var(--neutral-c) var(--neutral-h));

プライマリと色調を揃えた新カラー(色相が150度異なる紫)
  color: oklch(from var(--primary-key) l calc(var(--lr-70)) c h calc(var(--primary-c) + 150 % 360)));

[romot-co]

進捗:

ピッチ表示について考える:

いろいろ重なるのでみづらい
https://xd.adobe.com/view/fe4492d6-fd43-4419-ad6b-234a1b2a6a74-ab17/

---

実際に試してみた様子:

[romot-co]

進捗:
カラーを考える

ライトテーマが悩ましい

ライト

編集後ライン: オレンジ

編集後ライン: プライマリグリーン派生

ダーク

編集後ライン: オレンジ

編集後ライン: プライマリグリーン派生

[romot-co]

背景をカットすれば見やすくなるか:

編集後ラインローコントラスト:

編集後ラインハイコントラスト:

[Hiroshiba]

完全にジャストアイデアなのですが、緑の線のが上であるということを示すために、白辺りで縁（フチ）を取るのとかどうでしょう？
まあ、白の縁は物理的に不自然なのですが･･･。（本当は黒の影ができそう）

なんちゃってですが、線を少し大きいピクセル幅でフチ側を描画したあとプライマリーカラーで描画したらフチっぽくなるはずなので検証できるかも！

[romot-co]

@Hiroshiba
ありがとうございます！予想ですが縁取りできればだいぶマシになる気するのでやってみます！

若干そことは違うのですが、編集前ライン薄くすればいいかなと思ったものの
編集前ラインも有効なピッチ線なので薄くしてしまうと違和感につながるのかなーなどと…

[romot-co]

試行

[romot-co]

修正+アップ

[Hiroshiba]

おー縁取り･･･これはどうなんだろう！！！！！！！判断むずいですね！！！！！！

若干そことは違うのですが、編集前ライン薄くすればいいかなと思ったものの
編集前ラインも有効なピッチ線なので薄くしてしまうと違和感につながるのかなーなどと…

編集前ラインを点線にするって手はあるのかもな～～～～と感じました！
いろいろだいぶ悩ましいところですが、とりあえずアイデアだけでも共用をと思い･････。

[romot-co]

@Hiroshiba
ありがとうございます！
印象でしかないですが無いよりはマシかも…？といった感じでしょうか

編集前ラインを点線にするって手はあるのかもな～～～～と感じました！

ふわっとした感じですが、手前としてこんな問題があるのかなーと
https://xd.adobe.com/view/efd3b21b-dd54-4204-b03b-5e453faab689-ba80/

編集前と編集後ってのを考え直す必要がある…？

ただ、現状はできる範囲＋実装維持がいいかなと…！
(白地に緑ってのが視認しづらいのもありそう

[Hiroshiba]

@romot-co
確かに編集前のを薄くしてしまうと、その薄いのを見なくちゃいけなくなって認知負荷が高くなっちゃいますね！！！

とりあえず今できる範囲でというのは賛成です。
たぶん今のmainブランチではプライマリ側の線がもうちょっと太かったかもです。
色の感じをあまり変えないであれば不足した方がいいのかどうか、迷いそうです。。。 😇

[romot-co]

進捗:

色をプライマリ派生に:

---

あとはCSS指定のめんどくささがある...
が、いったんプルリク

[romot-co]

ほかの

Melodyne:

• 編集後ピッチのみ(元ピッチ表示なし)
• ピッチラインそのものを描くことはできないのもあってか、あまり視認性はよくない

AutoTune:

RePitch:

---

一つ思うのはピッチ補正と音量補正は同時に行いたいような気はする

[Hiroshiba]

なーーーるほどです！！

編集前のピッチを残すっていうのは意外とマイノリティなのかもですねぇ･･･。
まあ慣れてくるといらない気もするけど･･･。

一つ思うのはピッチ補正と音量補正は同時に行いたいような気はする

こちらもなるほどです！　解決策はパッと思いつかないけど･･･！

[romot-co]

@Hiroshiba

編集前のピッチを残すっていうのは意外とマイノリティなのかもですねぇ･･･。

VoiSonaとかRePitchは残してる感じですね、考え方の差ぐらいな気はします…！
(個人的には現状でもボイボが一番わかりやすいし直感的...Sigさんのおかげ

解決策はパッと思いつかないけど･･･！

音階無視して下部に波形表示して音量ラインいじれる感じでもいいやも
いくつか案を出せれば…！

[romot-co]

今後の考慮事項:

SCSSの変更において: まずは実装はしたものの、たぶん使い勝手があまりよくない
使いやすいようにする必要あるがどうするか...

たとえば

## 定義
$lr-map: (
  primary: (
    base: (light: 40, dark: 80),
    on: (light: 100, dark: 20),
    container: (light: 90, dark: 30),
    on-container: (light: 10, dark: 90),
    fixed: (light: 90, dark: 90),
    fixed-dim: (light: 80, dark: 80),
    on-fixed: (light: 10, dark: 10),
    on-fixed-variant: (light: 30, dark: 30),
  ),
  secondary: (
    base: (light: 40, dark: 80),
    on: (light: 100, dark: 20),
    container: (light: 90, dark: 30),
    on-container: (light: 10, dark: 90),
    fixed: (light: 90, dark: 90),
    fixed-dim: (light: 80, dark: 80),
    on-fixed: (light: 10, dark: 10),
    on-fixed-variant: (light: 30, dark: 30),
  ),
 ...
 surface: (
    base: (light: 99, dark: 6),
    on: (light: 10, dark: 100),
    dim: (light: 87, dark: 6),
    bright: (light: 98, dark: 24),
    container-lowest: (light: 100, dark: 4),
    container-low: (light: 96, dark: 10),
    container: (light: 94, dark: 12),
    container-high: (light: 92, dark: 17),
    container-highest: (light: 90, dark: 22),
 ),
 outline: (
    base: (light: 50, dark: 60),
    variant: (light: 80, dark: 30),
  ),
...

// 状態デフォルト
$state-relative-shades: (
  hover: (light: 5, dark: -5),
  active: (light: 10, dark: -10),
  focus: (light: 3, dark: -3),
  disabled: (light: -15, dark: 15),
);

## 使用
.note .note-bar {
   background: @include color-variable('secondary', (light: 90, dark: 70));
  // ホバーデフォルト
   &:hover {
      border-color: @include color-state('hover'); // 明度(Lr) light-5 / dark-5
   }
}

.sequencer-measure-line: {
   // 背景などから相対
   fill: @color-relative-from('--background', (light: -20, dark: 30)) // 背景から明度で-20 / +30
}

普通に書くとたぶんこう(わかりづらい…)

@media (prefers-color-scheme: dark) {
  .note .note-bar {
     background: oklch(var(--lr-70) var(--secondary-c) var(--secondary-h) / 1);
     &:hover {
        border-color: oklch(var(--lr-75) var(--secondary-c) var(--secondary-h) / 1);
   }

 .sequencer-measure-line: {
     fill: oklch(from var(--background) calc(l + 0.24)); // 相対明度がつらい
  }
}

@media (prefers-color-scheme: light) {
   ...
}

[romot-co]

とりあえず常時下部:

ノートに応じた位置合わせ・操作のしやすさがたいへんそう
AudioBufferからの表示はできそう

[Hiroshiba]

たしかに、レビューしててoklab等での色指定は難しいな～と感じました！

sassの@function内でどうにかしてlrを計算し、darkとlightを別々に指定できるようにする感じですよね。
良さそうに感じました！！
（@functionは@include要らないかもです。）

hover色を指定する@include color-state('hover')ですが、たぶん親でsecondaryが指定されたということを取得する手がない気がします。
なのでまたsecondaryを指定するか、１回適当なsass変数に値secondaryを代入する感じになりそう？

---

音声波形ずっと表示はありな気がしますね！
音量調整用のUIをそこにずっと表示するのはたしかに課題感がありそう。
（いろいろアイデア考えようとしてみたのですが、良いのは思いつきませんでした 😇 ）

[romot-co]

ピッチ表示試行:

※ ラインの引き方から考える必要あるかもなため

変更したラインを差分表示

• 編集時のみピッチ基準からcent単位差分？単に絶対周波数？で表示

---

元ラインを点線で残す場合

---

特に元ラインがない場合

[Hiroshiba]

お～～～～～なるほどです！！！　点線やっぱいいですね！！！

元ラインを点線で残す場合

個人的には、現段階これは目標としている条件（？）をギリギリ満たしてる気がしました。
ノートの縦方向の中央がそのノートのピッチである、という前提を持っていれば表示していなくてもわかるためです。
ただ多分ノートの中央の線も本当は表示したい気持ちもあります。思いつかないだけ。。。。

[romot-co]

@Hiroshiba
ありがとうございます！

もしかすると複雑な線の場合は厳しいかも？と思ったものの、試した感じ案外どうにかなる？かもです。
いずれにせよ、別Issueにできればありがたいです

ノートの縦方向の中央がそのノートのピッチである、という前提を持っていれば表示していなくてもわかるためです。
ただ多分ノートの中央の線も本当は表示したい気持ちもあります。思いつかないだけ。。。。

確かに！
やるとすればノート上のピッチを動かしている(ドラッグしている)場合のみ中央線表示？などと思いますが
ノート外の部分どうするなども出てきそうなのでこれも別にできれば…！

[romot-co]

あとは

• ノートに薄くbox-shadowや入力欄にinsetでbox-shadowかけて編集可能なのを明示する
• グレーやブラックに微妙に彩度を持たせる

などもありえるがいったん現状で...