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.

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

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

Closed
3 tasks
romot-co opened this issue Jan 31, 2024 · 76 comments · Fixed by #2218 · May be fixed by #2164
Closed
3 tasks

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

romot-co opened this issue Jan 31, 2024 · 76 comments · Fixed by #2218 · May be fixed by #2164
Assignees

Comments

@romot-co
Copy link
Contributor

romot-co commented Jan 31, 2024

内容

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

Pros 良くなる点

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

Cons 悪くなる点

なし

実現方法

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

VOICEVOXのバージョン

0.1.6

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

  • Windows
  • macOS
  • Linux

その他

@romot-co romot-co changed the title ソング:シング側の色を揃える ソング:シング側の色を揃える・正式な定義 Jan 31, 2024
@romot-co romot-co self-assigned this Jan 31, 2024
@Hiroshiba
Copy link
Member

Hiroshiba commented Feb 5, 2024

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

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

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

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

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

@romot-co
Copy link
Contributor Author

romot-co commented Feb 5, 2024

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

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

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

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

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

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

@sevenc-nanashi
Copy link
Member

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

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

@romot-co
Copy link
Contributor Author

romot-co commented Feb 5, 2024

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

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

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

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

@romot-co
Copy link
Contributor Author

romot-co commented Feb 7, 2024

考慮事項:

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

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

@romot-co
Copy link
Contributor Author

romot-co commented Feb 17, 2024

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

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

ライト

ライト2-2

ダーク

ダーク1

ライトバリエーション

ライト1

ダークバリエーション

ダーク2

@romot-co
Copy link
Contributor Author

romot-co commented Feb 17, 2024

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

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

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

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

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

@romot-co
Copy link
Contributor Author

romot-co commented Mar 3, 2024

こちらを先(実装中)

@romot-co
Copy link
Contributor Author

romot-co commented Mar 8, 2024

下部ツールバーの場合の構成案1
ライト-ボトムツールバー

@romot-co
Copy link
Contributor Author

romot-co commented Mar 8, 2024

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

@romot-co
Copy link
Contributor Author

romot-co commented Mar 8, 2024

現状のダークにおいた場合(もうちょい調整いりそう)
スクリーンショット 2024-03-09 7 40 05

@Hiroshiba
Copy link
Member

Hiroshiba commented Mar 18, 2024

(ただのコメントです)

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

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

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

@romot-co
Copy link
Contributor Author

一部導入済み

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

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

@romot-co
Copy link
Contributor Author

romot-co commented Jul 1, 2024

調整中…

スクリーンショット 2024-07-02 3 50 46

ためしにM3っぽく動的色変更(ソースカラーを選べばできそう)
スクリーンショット 2024-07-02 3 55 59
スクリーンショット 2024-07-02 3 59 14

@Hiroshiba
Copy link
Member

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

@sevenc-nanashi
Copy link
Member

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

@romot-co
Copy link
Contributor Author

romot-co commented Jul 4, 2024

(仕掛かり / いろいろ崩れている)
スクリーンショット 2024-07-05 1 37 48

スクリーンショット 2024-07-05 1 43 47

@Hiroshiba
Copy link
Member

Hiroshiba commented Jul 4, 2024

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

@romot-co
Copy link
Contributor Author

romot-co commented Jul 4, 2024

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

@sevenc-nanashi
Copy link
Member

sevenc-nanashi commented Jul 6, 2024

image
image

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

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

@romot-co
Copy link
Contributor Author

romot-co commented Jul 6, 2024

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

@romot-co
Copy link
Contributor Author

romot-co commented Jul 6, 2024

進捗進捗(ツールバーのパーツを一応そろえる)
スクリーンショット 2024-07-07 3 52 42

@romot-co
Copy link
Contributor Author

romot-co commented Aug 7, 2024

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

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

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


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

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

スクリーンショット 2024-08-07 9 15 29

Contrast-Test

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

@Hiroshiba
Copy link
Member

おーーー良さそう!!!!

色々ありそう

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

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

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

@romot-co
Copy link
Contributor Author

romot-co commented Aug 9, 2024

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

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

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

@romot-co
Copy link
Contributor Author

romot-co commented Aug 9, 2024

進捗:
わずかに進める
スクリーンショット 2024-08-09 19 28 13
スクリーンショット 2024-08-09 19 28 34

@romot-co
Copy link
Contributor Author

romot-co commented Aug 9, 2024

赤色覚異常
スクリーンショット 2024-08-09 19 49 26
スクリーンショット 2024-08-09 19 48 19

緑色覚異常
スクリーンショット 2024-08-09 19 49 39
スクリーンショット 2024-08-09 19 48 19

青色覚異常
スクリーンショット 2024-08-09 19 49 49
スクリーンショット 2024-08-09 19 48 34

全色覚異常
スクリーンショット 2024-08-09 19 49 59
スクリーンショット 2024-08-09 19 48 47

コントラスト
スクリーンショット 2024-08-09 19 49 16
スクリーンショット 2024-08-09 19 47 40

@Hiroshiba
Copy link
Member

(ただのコメントですが)良い感じに思います!!!

@romot-co
Copy link
Contributor Author

romot-co commented Aug 10, 2024

進捗:
SCSSに出力(結果は同じはず)
スクリーンショット 2024-08-10 22 35 12

たぶん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
Copy link
Contributor Author

進捗:

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

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

pitch1
ピッチ2
ピッチ3


実際に試してみた様子:
スクリーンショット 2024-08-21 7 25 10

@romot-co
Copy link
Contributor Author

進捗:
カラーを考える

ライトテーマが悩ましい

ライト

編集後ライン: オレンジ
スクリーンショット 2024-08-22 20 43 53

編集後ライン: プライマリグリーン派生
スクリーンショット 2024-08-22 20 46 58

ダーク

編集後ライン: オレンジ
スクリーンショット 2024-08-22 20 44 18

編集後ライン: プライマリグリーン派生
スクリーンショット 2024-08-22 20 47 19

@romot-co
Copy link
Contributor Author

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

編集後ラインローコントラスト:
スクリーンショット 2024-08-22 21 30 23

編集後ラインハイコントラスト:
スクリーンショット 2024-08-22 21 37 24

@Hiroshiba
Copy link
Member

Hiroshiba commented Aug 22, 2024

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

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

@romot-co
Copy link
Contributor Author

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

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

@romot-co
Copy link
Contributor Author

試行
スクリーンショット 2024-08-22 22 22 45

@romot-co
Copy link
Contributor Author

修正+アップ
スクリーンショット 2024-08-22 22 42 31

@Hiroshiba
Copy link
Member

Hiroshiba commented Aug 22, 2024

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

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

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

@romot-co
Copy link
Contributor Author

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

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

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

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

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

@Hiroshiba
Copy link
Member

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

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

@romot-co
Copy link
Contributor Author

進捗:

色をプライマリ派生に:
スクリーンショット 2024-08-26 23 47 26
スクリーンショット 2024-08-26 23 42 49


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

@romot-co
Copy link
Contributor Author

romot-co commented Aug 27, 2024

ほかの

Melodyne:

  • 編集後ピッチのみ(元ピッチ表示なし)
  • ピッチラインそのものを描くことはできないのもあってか、あまり視認性はよくない
スクリーンショット 2024-08-27 0 15 37

AutoTune:
ATPro-11_Dark-Mode_Graph-Mode_Female-Singer_Key-C_plugin_boutique

RePitch:
original_RePitch_Product_Image_pluginboutique


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

@Hiroshiba
Copy link
Member

なーーーるほどです!!

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

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

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

@romot-co
Copy link
Contributor Author

@Hiroshiba

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

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

解決策はパッと思いつかないけど・・・!

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

@romot-co
Copy link
Contributor Author

romot-co commented Aug 31, 2024

今後の考慮事項:

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

romot-co commented Sep 1, 2024

とりあえず常時下部:

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

スクリーンショット 2024-09-01 23 12 50

@Hiroshiba
Copy link
Member

Hiroshiba commented Sep 2, 2024

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

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

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


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

@romot-co
Copy link
Contributor Author

romot-co commented Sep 11, 2024

ピッチ表示試行:

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

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

  • 編集時のみピッチ基準からcent単位差分?単に絶対周波数?で表示
スクリーンショット 2024-09-11 18 56 03

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

スクリーンショット 2024-09-11 19 03 40

特に元ラインがない場合

スクリーンショット 2024-09-11 19 09 21

@Hiroshiba
Copy link
Member

お~~~~~なるほどです!!! 点線やっぱいいですね!!!

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

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

@romot-co
Copy link
Contributor Author

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

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

スクリーンショット 2024-09-12 21 10 01

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

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

@romot-co
Copy link
Contributor Author

romot-co commented Sep 12, 2024

あとは

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
@Hiroshiba @romot-co @sevenc-nanashi and others