テキストでコードを書く場合には注意が必要ですよ、という話。などなど。
海外でも長年問題になっていて、結局統一された記述が普及していません。
そもそも音楽の勉強をコンピュータ上の、それもテキストでやっている時点で「それはどうなのよ？」なわけですが。
（2018年2月3日更新）
■テキストでのコード記述
コードの表記で、特にネット上でプレーンテキストで記述する際にマイナス符号は使わない方がベターです。
マイナス符号はminorを手書きした時に省略形で使われるので、
A- B- C- だと
A min、B min 、C min
の意味になりかねません。
A - B - C - D - E - F - G
「マイナーにハイフン」＋「区切りにハイフン」を使うと下のようになってしまいます。
C - D- - E- - F - G7 - A- - B∮
これはやばい。読めない！
もし区切りにハイフンを使いたいなら、マイナーをハイフンで書くのをやめれば良いです。
C - Dm - Em - F - G7 - Am - B∮
これはかなりみやすいです。タイプする数がかなり増えてしまうのが難点です。
区切りを空白で記述すると、
A B C D E F G
C D- E- F G7 A- B∮
非常に見やすいですし、誤読は生じません。
もしくは、コードは必ず大文字が必ず先頭なので何も考えずに続けて書く方法もあります。
ABCDEFG
CD-E-FG7A-B∮
コンパクトでなかなか良いですが、ちょっと読みにくくありませんか？
やはり丁寧に空白をつけるのがベストだということになるわけです。
C D- E- F G7 A- B∮
圧倒的に読みやすく、誤解の起きる余地はありません。完璧です！
・スラッシュ区切りもNG
近似するコード区切り問題で、スラッシュ（/）を使ってしまっている人もいます。
A/B/C/D/E/F/G
C/D-/E-/F/G7/A-/B∮
スラッシュ区切りだとオンコードのAonBとして誤読されかねません！
オンコードは特殊なコードワークではありません。
普通の曲でもクリシェや順進行で使うので、絶対にスラッシュ区切りはやめるべきでしょう。
・小節区切りや、1小節に複数コードの場合は | や,で区切る
「じゃあ小節の途中でコードが変わる時とか、どうすんの？」という疑問が出て来きます。
区切りは | を使います。バックスペースの左にあるキーです。Shift＋「￥マークのあるキー」です。
小節の区切り線として使うこともあります。
| A B |C | D | E F | G ||
この書き方だと、リピートも記述できるのでちょっと便利。
|C D- ||: E- F | G7 A- | B∮ C | D- :|| G7 | C ||
プレーンテキストだけなのに非常に見やすいですね。
海外でも区切りについては統一感が無いようですが、とにかく丁寧に書き、誤読が起きないスタイルで書くことを心がければ大丈夫です。
興味がある人は海外のコード進行サイトを見て回ると良いでしょう。
丁寧に、誤読が起きないように書いている人と、めちゃくちゃ読みにくい内容になってしまっている人。実にいろいろです。
でも、プレーンテキストだけで拍などを明確に記述することに意味はないし、そもそもちゃんと音楽の勉強をするならコンピュータのテキストなんか使ってるだけじゃダメだよ、という証明の根拠でもあるわけですが。（Wikipediaの海外版でもコード記述はもうめちゃくちゃですよ。）
■なぜハイフン区切りが行われるのか？
たしかに書籍ではハイフン区切りが行われ、出版・流通しています。
正確には「空白」「ハイフン」「空白」の3文字での区切りです。
ただし、出版で使用されるフォントの特性によって問題のない視認性となっています。
これを一般的に普及しているフォントで行うと、コードネームの視認性が著しく低下します。
下はいろいろなフォントでの書き出し例です。意図的にフォント名は伏せます。
フォントによって文字の密度とハイフンの長さが大きく異なることに注目してみてください。
どれも一長一短な感じがありますし、フォントによっては「空白つき」が間延びして見えてしまうのも事実です。
グラフィカルな視点で、トータルでバランスが良く見えるのは全角です。
しかし、全角はすべて「空白なし」です。
つまり、コードネームを記述しようとしてハイフンをつけても「全角ではコードネームのように見えない」という致命的な欠点があります。（例を挙げるまでもなく、全角で空白をあけるとひどく間延びしてしまいます。）
--------------------
■ディグリー表記のミス
ついでなのでもうひとつ。
ディグリー表記（度数表記）の記述ミスについて。
ダイアトニックの順に1度メジャー、2度マイナー、5度セブンス、というアレです。
これは変化記号を手前につけるのが正しいです。
後ろにつけるのは誤りです。
◯ ＃IV （こっちが正しい！）
X IV# （誤）
この誤りは近年ネットでよく見かけます。
原因は中途半端な人がネットでコード理論の記事を書き、それを見て独学する人が多いからだと思います。
が、恐ろしいことに出版されている本でも後ろにつけているものがあり、世も末だなと感じました。
・度数表記のエンハーモニックミス
せっかくなので良くある表記ミスをもうひとつ。
これは記述ミスというか、アナライズの姿勢の誤りです。
度数表記で頻発しているミスに「5度フラット」という誤記があります。
bV∮ではなく、＃IV∮が正しいです。
＃IV∮とはトニックの代理コードで、構成音はF#、A、C、Eです。
C（構成音CEG）の
代理Am（構成音ACE）
の下にF#がついたものと解釈します。（構成音F#ACE）
（F、A、C、EのFが半音ずれた、という考え方もあるようですが、それだとサブドミナントIVの変化という解釈になってしまい、パッシング的になり、トニック代理だという根拠が希薄になります。ディミニッシュ的な構成音だったらなんでもパッシングだと解釈するのはおかしいでしょ？）
先日届いた某DTMスクールのアナライズ資料の中にもbV∮という表記があり「おいおい大丈夫か？」と心配になりました。苦言を呈する連絡はしたのですが、その資料は訂正されないままかなりの時間が経過しています。アイ◯ーなんとか、という人たちです。
bV∮だと3度がダブルフラットになってしまいます。
もしこれがbV∮だったら、コードは三度堆積なので「Gb、Bbb、Dbb、Fb」ということになってしまいます。これではCメジャーキーとしての体裁を完全に失っていて、#IV∮の出自がまったく意味不明になります。どうしてGbBbbDbbFbなんて構成音で「トニック代理」を名乗れるのでしょうか。
エンハーモニックは便利なのですが、アナライズではキーを重視するので、安易にエンハーモニックして「#IV＝bV」と考えてはいけません。アナライズにおいては完全な誤りです。
「細かいこと言うなよ」では済まされない、致命的な誤りです。
--------------------
■sustain
「サスティン（sustain）」は特にDAWが一般化した以降、「サステイン」（イが大きい）で書かれることが多いようです。
昔からDTMをやっている人だと、古い教科書で「サスティン」「サスティーン」という表記が実際にあったので、刷り込みが抜けずに未だに「ィ」の人がいます。
クラシック方面でも初期の日本の教科書では「トラムペット」と書かれてたことがあり、サスティーン問題とちょっと似ています。
近年話題になったものだと「ユーフォニアム」なのか「ユーフォニウム」なのか、という問題がありました。これも古い教科書だと「ユーホニューム」と書かれていたものがあります。これはここ数十年を見ている限り、完全に駆逐されたと言えるでしょう。
DAWが一般化した頃からDTM用語の統一が進み、その時に「サステイン」になった感じがあるのですが、古くからやっている人は「スレッショルド」ではなく「スレッシュホールド」と言う人もいますし、超大手のプラグインデベロッパのページの中でも「スレッシュホールド」という記述で統一されています。
「サスティーン」などの現在では一般的ではないカナ表記を見つけると、ここぞとばかりにツッコミを入れる人がいますが、英語圏の人の発音を聞いても、明らかに「サスティーン」と言っている人も多いので、あまり気にしなくても良いと思います。
（辞書サイトなどの発音が上手な人は「サステイン」のように発音しているのも確かに事実ですが、シンセのTIPS動画などでは「サスティーン」としか聞こえない、いわば滑舌が悪い人も多いよ、ということです。）
同様の問題は「シュミレーター」などの音楽以外でも一般的に使われる外来語でも頻発しています。昔から学問をやっている教育者や、ノーベル賞級の学者さんでも「シュミレーター」と言っていることがよくあります。
些細な点で他人の常識を非難し、人格や実績まで否定する姿勢は改めるべきでしょう。それは揚げ足取りでしかありません。
--------------------
