Workshy Get It On コード分析(メインのみ)

Spotify でかかってきてかなり気に入ったのでコードをとってみました。
すると、この柔らかくスムースな響きからは想像していなかったんですが、b9 b13 とかオルタードテンションが使われているコード進行のようです。

key=B で # が５個付くやつです。
1行目: 通常のコード
2行目: 度数表記
3行目: 度数でオンコードをテンションに直したコード

F#dim7 on G#  |  G#7 on C  |  C#m9  |  EM7 on F#  |  F#7 on C#  |  BM9
Vdim7 on VI  |  VI7 on I#  |  IIm9  |  IVM7 on V  |  V7 on II  |  IM9
VI7(b9 b13)  |  VI7 on I#  |  IIm9  |  V7sus4(9 13)  |  V7 on II  |  IM9

基本は VI II V I の循環で、VI -> II、V -> I のときにアプローチのパッシングコードがある感じです。後半の

IVM7 on V  |  V7 on II  |  IM9

はよく使うものだと思いますが、前半の

VI7(b9 b13)  |  VI7 on I#  |  IIm9

はこの曲の特徴の根幹のような感じです。VI7 の b9 は I に b13 は V に解決しつつベースは VI7 の３度に移動して柔らかさを維持しているようです。

コードもさることながら、メロディもちょっとコード分析を惑わすような内容でした。
なので、動画の方では１コーラスのメロディを入れています。

３小節目の VI7 on I# のところでコードトーンは III(E#) なのに、メロディは E# から E に上がって半音でぶつかっています。スケールトーンではあるんですが、長くいるのでコード的に変わってしまっている気もします。

５小節目の Vdim7 on VI のところでコードトーンは I#(B#=C) ですが、思いっきり C# を踏んでます。C# C B と半音で下がるメロディですが、こちらもスケールトーンではあるんですが、長くいるのでコード的に変わってしまっている気がします。

もしかしたらぶつかるときだけバッキングで調整をしているかもしれませんが、ぶつかっていてもそのまま気にしていない気もします。

こういうときどう考えればいいんですかね…聴感上気にならないレベルであれば OK というのは作る上ではいいとして、突き詰めた場合、プロの仕事などでは一般的には避けられているのか、それともなんらかの説明の付け方があって OK なのか…

この辺悩み続けている気がします。

7b5(13) コードのボイシング

思いついた曲のモチーフのコード進行が想定したイメージにたどり着けないまま数日経っていたんですが、なんとかたどり着けたので、今回考えたことのメモをしておきます。

Im11 IV7b5 II7(b9) V7(b9 b13)

でかなり近い所まで来ていたんですが、メロディは Im11 の 11th から IV7b5 の 13th で終わっているので、IV7b5 に 13th を入れようとしたのが苦労の始まり…
そのまま混ぜると 13th と 7th が半音でぶつかって聴感上もたぶん NG でした。なので 7th を抜いて IV6b5 としてみるとイメージから遠のいてしまう…これだと聴いた感じ #VIIb5 on IV で流れ的にも合っていません…

ルート自体変えて他のコードにしてみたり、メロディ自体を変えてみたり色々やってはみたものの、どうも元の状態の方が良かったのでもとに戻って調べなおしたり、いろいろ悩んだ結果、やっと見つけました。

何ということはない、単純に 13th を追加して IV7b5(13) で、ボイシングで 7th を 13th の１オクターブ下にするというものでした。要はボイシングの問題だったようです。

キー Dm での IV7b5, IV6b5, IV7b5(13) の聴き比べ動画です。メロディとコード進行のしっくり感では圧倒的に IV6b5 より IV7b5(13) ではないかと思います。7th はやはり必用で、13th と m7th は M7 の音程にした方がいい、と言うかしないとダメなコードに聴こえる、ということのようです。勉強になりました。ボイシング大事です。


最近このようなオルタードテンションを使ったコード進行に挑戦中で、その中で出てきたメロディ自体がこういうコードを示唆しているという事は、こういうコード進行が血肉になってきている気がして嬉しいです。

マイナーキーのダイアトニックコードのややこしさ

‪おととい思いついた曲がマイナーキーのダイアトニックコードのややこしさを教えてくれる感じでマイナーキーの経験不足を痛感しました…

ググったらこんなサイトが有りました。
マイナーのダイアトニック・コードとは？／初心者集まれ！指板図くんのギター・コード講座 第31回

要はナチュラルかハーモニックかメロディックかと言うアレですが、行ったり来たりするので聴いた感じ普通なのにややこしい…‬特に 9th の音が…
わかりやすいように Am キーに直すと、曲のメインのコード進行はこんな感じです。

| FM9 | FM9 | Em9 | Dsus4(9) D(9) |
| FM9 | FM9 | Em9 | Am9sus4 F#m7-5 |



そもそもこの進行が Am キーなのかどうかが自明ではないと思いますが、VI V I の逆進行で Am7 に解決しようとしているので、Am キーで多分間違いないと思います。動画の方では終止をわかりやすくするように２巡目の最後を Am7 にしてあります。

この循環ですが何がややこしいのかと言うと、F の音が Fm9 ではナチュラル、Em9, D ではシャープしているという点です。

上のサイトの話を勘案すると、

ナチュラルマイナースケール: FM9(9th の G がナチュラルなのでハーモニックではない)
メロディックマイナースケール: D(9)

Em9 はナチュラルマイナースケールになるんですが、問題は 9th の F# です。ナチュラルマイナースケールでは  F はシャープしないので、なんなのコレという状況です。

あまり今回のテーマとは関係ないですが F#m7-5 は FM9 に対する裏コード的なものかと思います。スケールとしては Em9 と同じでなんなのコレですが、A/F# という形でよく使われるコードで装飾的なコードなので色々あり得るしスルーします。

もしかして D メジャーキーに転調しちゃっているとか？と思ったら D(9) の時にスケール的に 7th が m7 の C なので D メジャーキーになっているわけでもなさそうです。
どう考えればいいんでしょうか…

と、ここで気が付いたのがドリアンモード。Aドリアンモードですねコレ。あまりに自然なので転調感なさすぎですが、微妙にドリアンモードの雰囲気を持ち込んでいると考えるとしっくり来そうです。

ご意見募集中です。

macOS Siera にアップデート後、ローカル Web サーバの UserDir にアクセスできない問題

おそらく macOS Siera にアップデートしてからだと思うけど、http://localhost/~user/ にアクセスできなくなっていることに気がついた。
/etc/apache2/httpd.conf で userdir_module が無効になっていたのでコメントアウトを解除。userdir で検索するといいです。

LoadModule userdir_module libexec/apache2/mod_userdir.so

Include /private/etc/apache2/extra/httpd-userdir.conf

後もう一つ、/etc/apache2/users/ 以下の設定ファイルを読み込まない状態になっていたようなので /etc/apache2/httpd.conf の最後に以下の行を追加してアクセスできるようになった。

Include /etc/apache2/users/*.conf

設定後の再起動はこのコマンドです。

sudo apachectl restart

以前の設定ファイルはここに残っているようなので、前の設定を見たいときはこちらで。

/etc/apache2/httpd.conf~previous

TypeScript で外部ディレクトリの ts ファイルを参照すると参照先もコンパイルされて出力ディレクトリ構造が変わってしまう問題

Yeoman の angular --typescript 環境では初期状態で以下のようなディレクトリ構造になっている。

この状態で grunt serve すると .tmp 以下に ts ファイルがコンパイルされて以下のように展開される。

そして、自前のライブラリを利用しようとする場合、プロジェクトルートに lib を追加して利用すると仮定する。

＃そもそもここが間違いかも？app/scripts 以下に lib を置けば特に問題はないかもしれない。だが、アプリ限定のライブラリでもないので納得行かない…ルートに置く場合の対応ということで。

app.ts に以下のように参照を記述する。

/// <reference path="../../lib/jimae/testlib.ts" />

すると、grunt serve で .tmp 以下がこのようにディレクトリ構造が変わってしまい、動作しなくなる。

scripts/app/scripts となってしまっている。要は参照先の testlib.ts もコンパイルし、出力するために参照している最上位のディレクトリ(../../)を出力の baseDir にしていると考えられる。
コンパイルオプションの noResolve なども試してみたが、これは参照自体が行われなくなり、コンパイルエラーになる。仕方がないので、testlib.ts の型定義ファイルを以下のコマンドで生成し、typings 以下に配置し、そちらを参照するようにして解決した。（ライブラリにメソッド追加などが行われた場合は型定義ファイルを更新する必要がある。自動化した方がいいかも？）

tsc --declaration --declarationDir typings/jimae lib/jimae/testlib.ts

ts ファイルと同じ場所に testlib.js も生成されてしまうが削除する。
app.ts の参照は以下のように生成された d.ts ファイルに変更する。

/// <reference path="../../typings/jimae/testlib.d.ts"/>

これで .tmp 以下のディレクトリ構造は元通りに戻る。

しかし、この状態では testlib.ts がコンパイルされず、実行時に参照できないので Grunt タスクに以下のように追加する。

typescript: {
  jimaelib: {
    src: ['lib/{,*/}*.ts'],
    dest: '.tmp/lib',
    options: {
      module: 'amd', //or commonjs
      target: 'es5', //or es3
      rootDir: 'lib',
      sourceMap: true,
      declaration: true
    }
  },
  base: {

これで grunt serve 時に以下のように出力されるようになる。 index.html からは ../lib/jimae/testlib.js で参照できるので追加する。

<!-- build:js scripts/lib.min.js -->
<script src="../lib/jimae/testlib.js"></script>
<!-- endbuild -->

＃ちなみに grunt タスクの typescript:base で sourcemap となっている箇所は sourceMap にしないとソースマップが生成されない。雛形のミスと思われる。また、rootDir 指定をしないと lib/jimae が rootDir になり lib/testlib.js のように出力される。lib/jimae2 などに ts ファイルが有ると lib が rootDir になり lib/jimae/testlib.js のように出力される。tsc コマンドの仕様らしいが、出力されるディレクトリ構造が変わってしまうのでいただけない。rootDir 指定を必ずするようにした方が良いと思われる。そもそもの話、grunt-typescript は TypeScript 1.6.2 に依存しており、古い実装になっているので新しいもの(AngularJS1.5等)を扱う場合は grunt-ts に乗り換えた方が良いと思われる。

そもそもの話、ts ファイルの reference 先までコンパイル出力しようとするのが問題なので、以下のリンクのように、reference 指定で ts ファイルを型定義として読み込む設定ができればいいのだが、TypeScript2.0.3 でもまだこの機能はないらしい。

https://github.com/Microsoft/TypeScript/issues/1753 TypeScript も何かと面倒ですな… Yeoman の雛形ではなく IntelliJ に依存した方がいいかもしれない…

Windows 10 で Kohan Ahriman's Gift のプレイ動画を録るまで

こないだ Windows10 アップグレードの駆け込みで PC を組んで Windows10 をクリーンインストールしたんです。コンセプトは省電力で GeForce NVEnc で動画エンコードだったんですが、たまにやっていたレトロゲーム、Kohan Ahriman's Gift が動くかどうかも不安でした。Kohan Ahriman's Gift はとても面白いので、Steam で安く買えるし面白さを伝えるためにプレイ動画も録ってみたかったのもあり、PC プレイ動画キャプチャ・配信の決定版 NVIDIA ShadowPlay のテストをしてみました。

先に結果

問題なくプレイできるようになり、キャプチャも成功しました。

Steam と Kohan Ahriman's Gift のインストール

Steam はゲーム配信プラットフォームとして有名ですが、Kohan シリーズも扱っていて Kohan Ahriman's Gift 単品だと 980 円、Kohan シリーズ３作品セットの Kohan Warchest が 1980 円とお手頃かつ Windows7 まで動作保証をしているので、Steam 経由でプレイするのが鉄板かと思います。

問題はサポート対象になっていない Windows10 で動作するかどうかです。

まず、普通に Steam と Kohan Ahriman's Gift のインストールをします。プレイしてみると、一応動きますが、マウスクリックなどの操作を行うたびに 0.5 秒ほど固まり、使いものにならない状態でした。

Kohan Windows10 でググってみると、この掲示板のスレッドが見つかりました。この問題のことを lagging in game とか言っていますね。

なんだかファイルが配布されていてそれを設置すると解決するらしいのですが、すでにファイルのリンクが切れていました。それで困っている書き込みもあったのでよく読んでみると、最後の Homra さんの書き込みを見ると Steam と互換モードの設定だけでも対応できるっぽい。手順を書いてみます。

Kohan Ahriman's Gift の Windows10 上でのラグを取り除く設定

まず、Steam の設定で Kohan Ahriman's Gift の起動オプションに cooperative をセットします。Steam のゲームリストで Kohan Ahriman's Gift を右クリックしてプロパティを選択、「一般」タブにある「起動オプション設定」に「cooperative」と入れて OK を押します。

 この状態でプレイしようとすると、色が 16bit じゃないとダメだよと言われます。

GTX950 の環境では 32 bit Color しか設定できないようなので、Kohan Ahriman's Gift の実行ファイルの互換モードの設定をします。実行ファイルは先程のプロパティダイアログの「ローカルファイル」タブ「ローカルファイルを閲覧」ボタンで開けます。通常は
C:\Program Files (x86)\Steam\steamapps\common\Kohan Ahrimans Gift
にあるようです。

Kohan_AG.exe が対象の実行ファイルなので、右クリックでプロパティを開き、

互換タブで

• 「互換モードでこのプログラムを実行する」にチェックを入れる
• 「Windows XP (Service Pack 3)」を選択する
• 「カラーモードを制限する」にチェックを入れる
• 「16ビット(65536)カラー」を選択する

以上の設定をして OK を押します。

この状態で Steam でプレイを押すと、Windows10 の警告が出ます。これは今のところ回避できていません。

とりあえず毎回聞かれるので、「はい」を押しておきます。これで起動すると、マウスクリック時のラグは無くなります。やった！

GTX950 のビデオカードではフルスクリーン時に画面いっぱいに引き伸ばされてアスペクト比が狂ってしまい、うまく解決できなかったので、プレイ時には画面解像度を 1024x768 に変更してからプレイするようにしています。これも勝手に解像度変更して欲しいところですが…

NVIDIA ShadowPlay でプレイ動画キャプチャ

次は ShadowPlay で動画が録れるかテストです。

GeForce Experimence を起動して右上にある ShadowPlay ボタンを押して左側のスイッチを押して緑色に点灯させます。

ただ、GeForce Experimence には対応ゲームとして認識されないようなので、左の ShadowPlay タブで「デスクトップのキャプチャを許可」にチェックを入れ右下に録画状態のオーバーレイが表示されたら準備完了です。

Alt+F9 で録画開始、停止ができます。これで録ったのが冒頭の動画です。

プレイ動画の解説を少し…

ランダムマップ 1対4 のハードモード CPU 戦です。強い CPU を選んでだいたいこの設定で遊んでいますが、ほとんど負けます…この動画の時はそこそこうまく行っていますが、エリートアーチャーが間に合わず、怒涛の数の暴力を見ることができます。この状況を打破して相手を全滅させるのが面白いです。友人とネット経由で協力プレイして 2対4 でもよくやります。でも負けます…たまに勝てるのでバランスはいいんでしょう。

ぱっと見、分からないひとにはわからないと思うので簡単な解説を入れながらのプレイ動画などもいずれやってみたいと思っています。

YAMAHA MD-BT01 導入

最近は MIDI も Bluetooth の時代らしいです。そこで、気になっていた電子ピアノの稼働率の悪さを改善するため YAMAHA MD-BT01 を導入してみました。最近は PC と 鍵盤の接続は USB 接続が主流で MIDI 端子しかないとちょっと扱いづらいのです。USB MIDI アダプタもじゃまくさいですし…なので、MIDI 接続を Bluetooth でできるようにするアダプタ MD-BT01 です。電源は MIDI コネクタから供給されるらしく充電とかは必要ないです。

これで何に繋げるかというと、iOS デバイスと Mac OSX です。Windows はまだ Bluetooth MIDI(MIDI over Bluetooth LE)に正式対応しておらず、KORG が独自のドライバで microKEY Air を対応させているようです。Windows はもうちょっと待った方がいいかもです。

iOS に繋げる際は GarageBand や Korg Module などの設定で認識させます。普通に鳴らせますが、第３世代 iPad なのでそもそもソフトの発音遅れがひどい^^; ストリングスくらいならなんとか…

Mac OSX の場合はユーティリティに Audio MIDI 設定と言うアプリがあるので、そこで MIDI スタジオを開くと Bluetooth のブロックがあります。それをダブルクリックして設定に入ると認識させられます。めんどくさい…まだ出始めでこなれていない感じです。

Mac OSX で Logic に繋げてみると、ほとんど遅れを感じません。USB で接続している感覚と変わらず。これはいい！

reface DX にも繋げてみましたが直に MIDI 端子が無いのでブレイクアウトケーブル経由でそこはかとなく脱腸感…USB で繋げた方がいい場合もありそう…

iPhone, iPad の場合はコネクタが空くので充電しながら使えるので効果大きいです。スタジオ練習で USB ケーブル引き回すよりは Bluetooth もいいですね。Bluetooth MIDI のデバイスがたくさんあるとどうなっちゃうんだろう？

とりあえず電子ピアノを iOS, Mac の今の環境に参加させることができてよかった。これで利用率あげられる！

Quicco Sound の mi.1 という Bluetooth MIDI 黎明期から出始めた先発品があるんですが、こちらも性能は変わらない様子。小さいし安いしこちらも試してみたいです。