[箇条書き] AWSを見直して、円安に備えよう。

円安の影響を直に受けているのが、AWSですね。

複数プロジェクトが同時に走っていると結構な費用がかさんでしまう。

しかし、本番環境はともかく開発サーバであれば、削れるところは削りたいもの。

特にAWSはとにかく設定項目が細かいので、間違った設定に気が付かずにうっかり無駄な料金を払っていたなんてことがしょっちゅうあります。

チェックすべき大きなポイントを列挙してみました。

細かい設定方法等は他のブログ等を参考にしてくださいませ。

ALB(Application Load Balancer)は兼用が可能

プロジェクトやドメインごとにLoad Balancerを立てる必要などありません。

ALBのリスナーはドメインで判別して、別のポートに送ることができるので、

• dev.example1.com -> localhost:8080
• dev.example2.com -> localhost:8081

などの設定を行えば、複数のプロジェクトで一つのALBを使うことができます。

しかしそもそも特に大きなアクセスがあるわけでないので、ロードバランサーなどいらないのでは？と思ったりするのですが、AWSはこれがないとドメインが固定できないので、一応最低一個のALBは必須になってしまいます。

ECSなど従量課金製のものは使用しないときは停止する。

ECS等の従量課金制のサービスは使用しないときは停止すればそれだけ安くなります。

しかしながら、ECS等自体にはスケジュールによる停止機能などはついていません。

ECSのタスク数を0/1に切り替えるLambdaを作成して、Event Bridgeで起動させるようにしましょう。

NAT Gatewayは最小限に

AWSのサブネットにはPublic, Private with NAT, Privateがありますが、Private with NATの場合のみ課金が必要になります(NAT Gatewayに対して課金されます）。

これは本番サーバでも言えることですが、本当にそのサービスがPrivate with NATである必要があるのか、Private/Publicで良いのか、より吟味して設定しましょう。

もし外にアクセスしないRDSをPrivate with NATにしてしまっていたりしたら勿体無いです！

ECRのバックアップは必要数だけにとどめよう

ECRレジストリのバックアップは５０やそこらにしているのが標準という感じですが、大抵の場合別にgitにも保存されているわけですから、大量に置いておく必要はありません。これも適切な数にしてしまいましょう。

使われてないSecret Managerはないか

細かい話ですが、secret managerは1エントリにつき1ヶ月1$かかります。これも必要のないものは削除してしまいましょう。特に、cloud formationなどで作成後そのままになってしまっているなんてケースも多そうです。

その他

それ以外にも別リージョンで設定したままになっていて気が付かなかったなんてことも結構あります。RDSもプロジェクト終了時に手動で停止したつもりが７日後には自動で起動してしまっていたなんてこともよくあります。Cost Exploerer で時々チェックするようにしてみましょう。

音楽をつまらなくするコード進行をディープラーニングしてみたらやっぱりつまらなかった

音楽におけるコードはあんまり好きじゃない。

かっちりしたコード進行なんてものが音楽をつまらなくするのだ、あんなものを覚えてしまうと型にはまった音楽しか作れなくなってしまう。もっと自由な方がいいのだ。

と常々勝手に思っていたが、まあしかしなんだかんだ実作業の面では便利だったりするので、結局学ばざるをえなかったりもする。

自動音楽生成でもコードは使わないぞ、と頑張ってきたのだけど、やっぱりなんらかの進行のヒントになるかもしれないので、一応こちらも自動生成を試してみることにしました。

音楽のコード進行

コード進行にはある程度の法則がある。

一番教科書的なルールとしては、

C -> F -> Gのような

立ち上がり（トニック）、ちょっと盛り上がり（サブドミナント）、盛り上がり（ドミナント）、みたいな形が基本。

例外はあるにせよ、C F# Dm Abみたいな脈絡のない妙なコード進行がくることはあんまりない。

これはちょうど文章と同じような形で、主語があって文末がある、みたいなもの。

ということで、コード進行データは「文章と同じ時系列のデータ」と捉えてしまって問題ないでしょう。

となれば話は簡単、文章をディープラーニングさせる時と同じ手法が使えます。

コードのデジタル表現

では、コード進行のデータをプログラム上でどうあらわすか。
これはドレミファソラシドを12bitのまとまりに置き換えて、

Cメジャーならば

[1,0,0,0,1,0,0,1,0,0,0,0]

Cmならば

[1,0,0,1,0,0,0,1,0,0,0,0]

C7ならば

[1,0,0,0,1,0,0,1,0,0,1,0]

とすることにする。

この方式だとCー＞Fー＞Gのコード進行は以下の通りになる。

[1,0,0,0,1,0,0,1,0,0,0,0]　[1,0,0,0,0,1,0,0,0,1,0,0]　[0,0,1,0,0,0,0,1,0,0,0,1]

学習データ

学習データは邦楽洋楽とりまぜてコード譜10000曲ほどを用意した。

そのうちkeyがCと明記されているもの2000曲あまりを学習データとした。

ちょっと数が心許ないけど仕方ない。

というわけでモデルを組んで学習させてみる

Epoch 1/50
33/33 [==============================] - 1s 21ms/step - loss: 0.6694 - val_loss: 0.5621
Epoch 2/50
33/33 [==============================] - 0s 2ms/step - loss: 0.5366 - val_loss: 0.4543
Epoch 3/50
33/33 [==============================] - 0s 2ms/step - loss: 0.4366 - val_loss: 0.3682
Epoch 4/50
33/33 [==============================] - 0s 2ms/step - loss: 0.3468 - val_loss: 0.2882

.
.
Epoch 46/50
33/33 [==============================] - 0s 2ms/step - loss: 8.5190e-04 - val_loss: 8.1676e-04
Epoch 47/50
33/33 [==============================] - 0s 2ms/step - loss: 8.0641e-04 - val_loss: 7.7746e-04
Epoch 48/50
33/33 [==============================] - 0s 1ms/step - loss: 7.6571e-04 - val_loss: 7.4075e-04
Epoch 49/50
33/33 [==============================] - 0s 1ms/step - loss: 7.3260e-04 - val_loss: 7.0640e-04
Epoch 50/50
33/33 [==============================] - 0s 2ms/step - loss: 6.9866e-04 - val_loss: 6.7435e-04

コード進行生成

生成させるのは８小節。

最初の２小節をこちらから与えることにする。

まずは、C->F を与えたものと、C->Amを与えたもの

とすると出てきた進行（例）はこんな感じ。

C, F , G , C, F, G, C, F

C, Am,  F , G ,C ,F ,G ,C ,F

ありゃ、どちらも、C->F->Gに収束してしまった。 まあ基本だからしょうがないな。

というわけで、Cキーでありながら、Gから入るという進行G->Amを与えてみる。

 

G ,Am ,G ,C ,F ,G ,C

おお、こちらもGに戻ってまた、C->F->Gに収束してしまう。それだけ、C->F->Gの進行が強いんだな。

では次は２小節目から転調してやれ、ということで、C->Eを与えてみる。

C ,E ,G ,C ,F ,G ,C ,F

あららららら、こちらも、Gに戻りまたC->F->Gに収束してしまった。。。。。

結論

冒頭の方でコード進行の教科書的な進行ということでC->F->Gを例にあげたけど、これだけ、C->F->Gにばかり収束するということは、実際の曲中でも、C->F->Gは結局それだけ例があるということか。

本当は、RNNの予測に使う過去のデータ数を２（最初に与える小節）ではなくもっと増やせば少し変わってくるとは思うのだけど、文章と比較すると小節は生成する量が少ない（通常文章が数十単語の羅列を生成するのに対して、音楽は８小説とか、１６小節とかのみ）ため、そのアプローチにも限界がありそう。

それに、４・８小節でのまとまりがあるべきなのに、それを意識してないのも問題。

しかし、結論としてはやっぱりコード進行はC->F->Gの基本がめちゃ強くて、それ以外のバリエーションが大量にある（使用されている）というわけではないということですね。

こんな結論ですみませぬ。

AI作曲をコードと数式を使わず説明してみる、その3

再帰型ニューラルネットワーク(RNN)とその発展系(LSTM) 

前回出たのは、過去の時系列の並びから未来のことを予測するという再帰型ニューラルネットワーク。 

今回はその中でもLong Short-Term Memory(以後LSTM)を使うことにします。

LSTMは再帰型ニューラルネットワーク（以後RNN)の拡張、とでも言うべきもので、RNNもLSTMも過去の時系列の並びを手掛かりに未来の展開を予想すると言う意味では同じです。

RNNは直前のいくつかの音の並びしか手掛かりにできないのに対して、LSTMの方がずっと昔の音の並びを手掛かりにすることができます。

リフレインが音楽を作る

メロディは基本的に過去のフレーズを繰り返したり、展開したりすることで、構築されます。

まったく関連性のない音の並びがずっと続くということはありえません。

 たとえば、「世界に一つだけの花」であれば 「世界にひとつだけの花〜ひとりひとり同じ種を持つ、その花をさかせることだけに〜」と展開しますが、 冒頭の「世界に〜」と途中の「その花〜」は全く同じフレーズですよね。 

「世界に〜」を聞かせておいて「ひとりひとり〜」と違うフレーズを挟んでわすれたころにまた元に戻る。 

これが「メロディ」を強く人間に意識させるのです。

このような繰り返し、リフレインは至る所で使われます。

このように音楽製作者は意図的に繰り返しを多用します。

たとえば、音程を変えて、リズムだけリフレインしたり、コードをリフレインしたり、そもそもドラムパターンは基本リフレインですよね。

こういったリフレインこそが単なる音の並びを「音楽」にしているものと言えるでしょう。

リフレインを基本としたアプローチ

そこで「リフレイン」に強いアプローチとなると、前述LSTMのAIモデルを使用して、過去の音を学習して未来の音を予測させるという手法が意味をもってきます。

この時にどれくらい昔まで参考にするのか、1秒前なのか、5秒前なのか、どれくらいの重みでそれらを重要視するか、などを考えて設計していきます。

これらのパラメーターの設置次第で、様々な音を作ることができるわけです。

これが最もシンプルなAI音楽の姿と言えるでしょう。 

未来のAI音楽

ただ実際にはこれだけで、複雑な音楽を作れるわけではありません。  

音楽にはもっともっと様々なレイヤーが存在しています。  

調和した音程を作る「和音・コード」のレイヤー、AメロからBメロへ移り変わる「展開」のレイヤー、音色のレイヤー。 

今回は波形の話をしましたが、これをMIDIで行うアプローチもあります。  

今現在これらのレイヤーをすべて実用化のレベルで持っているというAIはほぼないでしょう。 

それはそれだけそれぞれの組み合わせが難しいと言うことでもあります。  

そうしてこういうアプローチを見ていくと、結局は人間の感覚、どうやって作品を生み出しているのか、聞く側はなぜこれを心地よいと感じるのか、を理解する必要があると言うところにぶつかります。 

 それだけ人間はいかに複雑なマシーンと言うことでもあるのですね。

AI音楽備忘録 どこまでが音楽か

 AI音楽備忘録

現状AIモデルにての11作品。
https://www.youtube.com/channel/UCX514JhcB-HsCYC4dBLMC1Q

実際には同じモデルでなく、ずっと改良を加えているので、まあ途中経過がそのまま備忘録的にアップロードされているという感じです。

当初は生成されたトラックサンプルをシーケンサ上で人力で選択し組み合わせていたのが、自動でミックス・フェードアウトまで作れるようになって、シーケンサを通さずに、コマンド一つで音楽が作成できるようにはなりました。

>


この例をみると、ドラムパターンはいい感じで繰り返されていますが、上物はどうも変化に乏しい。

現在のモデルは波形を直接学習しその続きを作っていくというもので、そしてその仮定でBPMや小節といったある程度の「音楽のルール」は正規化されています。

しかし、コードや、音楽の大枠での構造（４、８小節のまとまりなど）をいうものを理解しているわけじゃないので、はじめと終わりなどの展開、コードに沿った音の重ね合わせ、などができるようになるのが次の課題になるでしょう。

本当はリズムパターンだって１小節を繰り返してるだけじゃなく、４、８小節ごとにリフがあったり展開があるのが普通ですしね。

何をもって音楽と呼ぶのだろう？

しかし、作っていくうちに音楽の定義という物を考えないと何がゴールかさっぱりわからない、ということに気がついたのです。

「何を音楽とするか」のいわゆるAIでいうところのフレーム問題（使い方が違う気はするけど）的な物にぶつかってしまったわけである。

なにが音楽なんて曖昧な物で、とどのつまり、いってしまえばただ雑音を録音しただけでも、音楽と言えてしまうわけですしね。

たとえばこれはリズムパターンを延々と生成するタイプの曲。

個人的にこれは音楽だと思うが、そうじゃないという人もいるかもしれない。

シュレーディンガーの作曲家

このプログラムの目標は音楽が永遠とアップロードされていて、それが人の手によるかどうなのかわからなくなることです。

これは昔からずっと考えていたことで、クリエイターの究極の姿ってそういうことなんじゃないかと思っているのです。

自分が死んでもずっとアップロードされているので、周りからみたら生きてるか死んでるかわからない、みたいな形。

いわば、シュレーディンガーの作曲家？

おそらくそういうことはこれからたくさん出てくるでしょう。

ずっと新作ドラマに登場してくる俳優、永遠にニュースを読み続けるアナウンサー、ずっと新作を発表し続ける絵描き、、、ずっと作曲をし続ける作曲家。。。

しかし、まあそれは先の話なので、とりあえずここでは音楽を

「リズム」と「上物」とに分かれた繰り返しの拍子を持つ物

に定義して進めてみることにしましょう。

AI作曲をコードと数式を使わず説明してみる、その2

特徴量の抽出

代表的なものには以下のようなものがあり、それぞれ一長一短ありますが、

• 短時間フーリエ変換 (STFT)
• メル周波数ケプストラムMFCC
• ウェーブレット解析

とりあえずここでは一番基本の短時間フーリエ変換（以下STFT)を使用することにします。

といっても普段からおなじみの、音質を調整するイコライザのようなものだと思ってくれれば良いです。

この状態のデータのグラフは、横軸に時間、縦軸に音量をとっていますね。

このデータにSTFTをかけると。。。。

以下のようなグラフになります。

横軸時間、縦軸に周波数、さらに色の濃淡で、音の音量も表現することができます。

（イコライザ なんかはこのデータを元に各音域を調整するのですね）

このようにすると生のwaveデータの状態よりも音の構造がよりわかるようになります。

そして、この状態のデータをAIに「学習」させることにします。

時系列データを学習する

AIで学習するデータはざっくり大きく乱暴に分けると２種類あります。

• 時系列のデータ
• 時間によってデータ変わるもの、毎日の気温、文章（前から後ろへ書いていきますね）、映像、などなど。
• 時系列ではないデータ
• 文字認識、絵、などなど。

それぞれによって使用するアプローチが変わってきます。

音楽は当然時系列のデータです。

たとえば、ピアノに座って「ミ」の音を出しただけではただの音です

前に「ド」をつけて、「ド・ミ」と引くとその音はそれぞれ意味を持ってきます。

意味を持たないただの音だった「ミ」はドと並べることで「音程が上がったよ」「三度上がった調和する音程だよ」という意味をもつ音となり、それはメロディとなり、調性をも生み出します。ド・ミとつながったのだから多分ソがきてドミソの和音かな？、とその先の展開も想像できるわけです。

AIでも同じ考え方をします。

前のデータを学習すれば、その先の音はわかるのではないかな？という仮定に立ちます。

その考え方に立ったものがAI学習方法の一つ「再帰型ニューラルネットワーク」です。

これはそれより「過去に起きた情報」を保持し、次のステップに利用することができるというアルゴリズムです。

時間の共に変化する分野、特に、「言語解析」や「音声認識」の世界では主流となっています。

音楽も同じように「時間と共に変化する」性質をもつので、この考え方を利用することとします。

というわけで次は、実際の楽曲生成です。

AI作曲をコードと数式を使わず説明してみる、その1

Waveファイルで音楽をディープラーニングさせたい！！

今現在、AIによる作曲の手段としてはgoogleのmagentaというライブラリが有名です。

これを利用した作曲手順についてはこちらに記事を書いています。

作曲家兼プログラマー 早川大地がAIによる作曲について語る：「人工知能で作曲、ここまで来てた！！」

googleが作ってくれたんだからそりゃあ有能に違いない、とmagenta を使って色々遊んではみたのですが、なにぶん残念なことに作曲については基本Midiがベースとなっているのです。

（ボーカル合成とかあるにはあるんだけど）

Midiファイルの例：「どの位置で何の音が鳴るか」が記録されたファイル

こうなってくると、作曲家の補助的な用法としては使えるかもしれないけど、リスニングの分野の実現性としてはどうなんだろうかと思うところなのです。

ということで、やっぱりなんといっても普段聴き慣れているWavデータを使って、自動作曲したいと思うのですよね。

Wav ファイルの例：普段PC上で耳にする音楽はほぼこれですね。

そこで、magentaに頼らずに１からモデルを作ってみることにしました、その過程で考えたことを通して、AI作曲についてなるべくわかりやすくまとめてみたいと思います。

AI作曲についてはなにが正解ということもないので、こんな考え方があるのだなあと思って思えれば。

もちろんこのアプローチですぐにまともな「作曲」ができるとは思えないけれど、リズムを変異させたりあらたな環境音を作りだしたり、と新たな作曲のヒント程度は作ることができるかもしれない。

というわけで数回にわけて、Waveファイルを対象としてディープラーニング作曲・AI作曲にチャレンジしてみたいと思います。

できるだけ、技術畑の人だけでなく音楽畑の人にプロセスを理解してもらいやすいようにかければなと思っております。

音楽を分析する際のポイント

同じようにWaveファイルを分析するものとして、代表的なものに音声認識があります。

音声認識は母音や子音の特徴量を認識して、これが「Ah あ」だとかこれが「kah か」だとか、分類していく作業です。

ところが音楽の場合は単なる音声認識と違ってさらに考慮すべき構造がもっときっちりとあるのです。

• テンポの正規化
• 小節の構造
• 楽器の構造

構造があるということは手がかりがあるということです。

これらの構造を利用してコンピュータが学習することができれば！！

と期待できますよね。

まずは音の「特徴」について考えよう。

例えば誰かの歌声を覚えるとき、人は、無意識のうちにその特徴を覚えていると思います。

声色の雰囲気だったり、のどの使い方だったり、高さだったり、しゃくりあげや、語尾の発生の仕方だったり。

ちなみにものまねがうまいひとなんかはこれが上手なのですよね。

「特徴」となる部分を上手に掴み取ることができる、天性の学習能力がある、とも言えるでしょう。

それに類することをコンピュータ上でも行い、データを整理し学習しやすくする、というのがデープラーニングのプロセスの第一歩です。

これを「特徴量の検出」という言い方をします。

ただしそれを人間がやるのと違う点は、音楽を物凄い短い時間の単位に区切り（0.001 秒ごと、などなど）そしてそれを、物凄い数やるということでしょうか。

音とは何か

さて、いったん基本に立ち返って、音とは何か、という話。

まずは以下二つの波形を見てみましょう。

4cos10πの波形

3cos6πの波形

横軸に1（秒）をとり縦軸に大さ（振れ幅）をとったグラフです。

ずいぶん単純なグラフ（波形）ですね。

さて、この周波数と、振幅（振り幅）はいくつでしょうか。

そして、周波数=1秒ごとに揺れ動く（グラフと山と谷の数）とですので、最初のグラフは周波数が「5」です。(数えてみましょう、いち、にー、さん〜、し〜、ご〜・・）

そして、下のグラフの方も数えてみると周波数が「3」となりますね。

加えて振幅の大さがそれぞれ、4、３となっているのは見て取れますよね。（グラフの山のてっぺんをが縦軸のどこに来ているか、を見れば良いでしょう。）

そして、どちらの式もXcosYπという形で表されます。

上のグラフは、4cos10πで下のグラフは3cos6πですので、XとYに入る数字が変わっているだけですね。

ちなみにこの場合Xが振幅となり、Y の二分の一が周波数となりますので、グラフを見ずとも、式をみるだけで、振幅と周波数がわかります。

これは「コサイン波」と呼ばれる波形、これも立派な「音」になります。（シンセサイザにも入ってますので、ご存知の方も多いかと。）

この音は非常にシンプルな「プー」とか「ポー」とかいう素朴な音。

コサイン波同士を足し算して音を作る

そして、これら波形は足算・引き算、四則演算をすることができます。

たとえば、最初の二つの波形を足し合わせると、以下のような波形になります。

4cos10π＋3cos3π

足し方は簡単です。

上のグラフでは横軸（時間）が0.0の時に縦軸（振幅）は４となっていて、下のグラフでは横軸が0.0の時に縦軸は3となっています。

ですので、足算したグラフでは0.0のところに4+3=7が入ります。

この要領で順次足していけば良いのです。

とまあ二つの単純な波形を足算しただけですが、ずいぶんと複雑な形になりましたね。

実際にはこれ以上に無数の波形が足し合わせられることで、様々な複雑な音が生成されます。

鳥の声も人の声も、楽器の音も、もちろんシンセサイザも、すべて単純な波形の重ね合わせです。

となると、それぞれ重なり合った波形を分析していけば、必要な音の「特徴量」が掴めるのでは・・・・なんて気がしてくるのではないでしょうか。

この技術の延長に「イコライザ」のようなみなさんお馴染みのものがあり、まずは特徴量の学習はそこからのスタートということになります。

次回以降は特徴量の抽出方法について試行錯誤していく話となります。

絶対音感がある人は3%、音大生では30%、アプリによれば5%？

 

新潟大学の宮崎謙一教授らチームによる研究によれば、日本人で絶対音感がある人は全体の3%ほどなんだそうです。

それが音大生だとぐんと跳ね上がって30%ほどになるそう。

ちなみに宮崎教授らのチームのテスト方法はピアノの音を聞かせて90%以上当てられることを基準としているそうです。

というわけでその結果を踏まえて、「絶対音感トレーニング」

アプリの結果からそのデータを独自に計算してみました。                                               

このアプリはビギナーモードだと単音だけでのテストとなりますので、だいたい、850~900点以上、図の中の青い線より下のスコアが出た場合絶対音感がある、と考えて良いでしょう。

ビギナー意外のノーマル、ハード、スーパーハード、モードでは複数音当てなども含んでいるので、ちょっと比較しづらいので除外します。

こちらがその点数のグラフです。

縦軸が得点（1000点満点）、横軸がその人数です。

そして、実際に850点以上記録している人の割合を計算してみると、5.67% = 5%強となりました。

日本人全体の3%よりは多いですが、テストしてみようという時点で既に音楽への興味はある程度強いと考えられますから、5%というのは妥当な数字とも思えますね。

その他のデータはこちら

ハード

ノーマル

スーパーハード

かなり複雑な複数の音を当てるハード、スーパーハードとなると、逆に900点超えがたくさんいるのも面白いところです。

９００点を超えるには、４つの音が同時になっているのを即座に判別して、正確に答えられないといけませんが、スーパーハードに限っては半数近くが達成している模様。

できる人はとことんできるということなのでしょうか。

FlutterによるiOS/Androidアプリ開発が良い理由

最近使用頻度の高いAndroid/iOS 両対応フレームワーク Flutter

数本アプリ開発を通じて少し知見も貯まったと思うので、思うところを記載します。

結論から言うと

そのアプリに必要なライブラリがあることが予め確認（重要）できるのなら、導入ゴーで良いと思う。

フレームワーク自体の開発速度も早いし、バージョン管理ツールも出た。いまアツい。

個人的には今年ARライブラリのWikitudeが対応したことで、さらに幅が広がりそう。

箇条書きで理由を述べます

    

    Google開発・オープンソースなのでなんとなく安心感がある。

フレームワーク自体の開発ペースが早い。そのため複数バージョンを使用したりする機会も多い。以前は複数インストールして手動でパスを変えるという方法しかなかったが、バージョン管理ツールfvmが出てからだいぶ楽になった。

    ネイティブコードで動作する。

アプリの動作・UIの部分だけ両対応することに集中した設計。細かい設定はXcodeやAndroidManifestを直接いじることになるが、正直その方が楽。両OSのバージョンアップや仕様変更にも対応しやすい。したがってバグも少ない。（Titaniumなどはbuild時にXcodeのプロジェクト自体を作り直していたので、いろいろ大変だった。。。）

    ホットリロード機能がすごい。

動作中に少しコードを変更し、Rキーを押すだけで、リロードされる。再コンパイルが必要なしで、HTMLのような感覚でデザインを作れる。開発速度がとてもあがる。

    アプリをDartで開発できる。

Javascriptのゆるさとオブジェクト志向言語のかっちり感を程よく組み込んだ良い言語だと思う。個人的には　” ) ” が多くなりすぎるので視認性はどうかな、とは思う。一部わかりづらい書き方があるがそれは慣れ。

嫌なコードの例

            Container(
              padding: EdgeInsets.only(left:100,right:100),
              child:rows,
              alignment: Alignment(0,0), 
            )
          ]), //この辺の括弧が多い。。。
        ),
      ] 
    );

    ライブラリ充実度がかなり上がってきた

2019年初頭くらいには、videoのプレイヤーやXMLのパースなどライブラリによってはまだまだ足りないところがあった印象だけど、ここにきて通常の使用には困らなくなった印象。このあたりは今後dartがどれくらい伸びるかにかかっている。。。

人工知能演奏のダイナミクス（強弱）、タイミング

演奏のダイナミクス（強弱）・タイミングを人工知能（ディープラーニング）で作成
する実験が magentaで発表されていました。

Mp3ファイル - クリックで再生されます。

今度のモデルは音のピッチだけじゃなく、強弱やタイミングも考慮してくれます。

仕組みはシンプルでMIDI鍵盤128通りのノートオフとノートオンに加えて、どれくらい前後にずれているか(100パターン)、どれくらいのボリュームの強弱があるか(32パターン)を、学習させています。

デモサウンドを聞く限りではかなりピアノ演奏としてのリアル感さが感じられるのではないでしょうか。

（しかし同じモデルを使っても筆者はこんないい感じに作曲できない！！！、細かいパラメーターの設定か、、学習モデルか、、個人的にもまだ研究が必要のようです。。。。）

Magentaは「MIDI」をベースに作曲するので、どうしてもそのままだとダイナミクスや、揺らぎについても考慮してやらないと、「観賞用」としてはベタベタの”人工的なサウンド”になってしまう傾向にあります。（反面、作曲補助という意味では、問題ないのですが、、、）

今回の発表はその解決に一石を投じたと言えます。


参考資料:

Ian Simon and Sageev Oore. "Performance RNN: Generating Music with Expressive
Timing and Dynamics." Magenta Blog, 2017.
https://magenta.tensorflow.org/performance-rnn

作曲家の視点から人工知能の生徒たちに授業をしてみたよ

以前の記事→ 人工知能(Tensorflow Magenta)で作曲してみた

さて、今日は音楽講師になって、かわいい三人の人工知能の生徒たちに、音楽指導をしてみようと思います。

どんな作品が上がって来るでしょうか。。。。。。

[授業をはじめる！！]

「さあ、今日の授業は、メロディを続けて作ってみよう！！です。

まずメロディの一部を挙げるので、そこから曲の続きを作ってみよう。

課題曲は、どらえもんのテーマ曲！

『あんなこといいな〜できたらいいな〜、あんな夢こんな夢いっぱいあるけど〜』

のお馴染みの曲です。

その最初の部分「あんなこといいな」（ソードドーミラーミソー）を参考に、そこから曲の続きを作ってみましょう。」

---------------0.01秒後----------------

「おお、もうできたのね、さすが人工知能たちは、作曲が早い。
こんだけ早いと、コーヒーを飲む暇もない。」

まずは生徒Aの作品から聞いてみよう。



「うーん、なんだこりゃ、まるでまとまりがないじゃないか。
『あんなこといいな』から先はまるで酔っ払いの千鳥足だ。」


生徒Bの作品



「ふむ。まあだいぶ良くはなっているな、『あんなこといいな』の繰り返しが増えて、メロディが覚えやすい。
ただ、少しシンプルすぎる感じがありますねえ。」


生徒Cの作品



「おお、かなりよくなっているね、エンディングの感じも出ているし!!!これを0.01秒で作ってしまうとは！さすが君は優秀な生徒だ！！」

[メロディのコツは繰り返し]

さて、というわけで、後の方の生徒になると、それぞれ、曲の「それっぽさ」がしっかりしてきたのがわかるでしょうか。

ですが、果たして、その違いはなんでしょう。。。？？

音楽が得意な人ならもう気づいたかもしれません。この違いはざっくりといえば、「繰り返し」の扱いの違いになります

課題曲として与えられたドラえもんのテーマ曲の「あんなこといいな」の部分。

この部分はのリズムは付点８分音符でスキップする様にはねており、それが、「あんーな」、「こーと」、「いーな」と３つ繰り返すことで、「フレーズらしさ」、を作り出しています。

このリズムや、音形をいかに上手に繰り返し使うかが、メロディ作りのコツなのです。


その観点でいうと、生徒Aはフレーズにどうも統一性がなく、全く印象に残りません。

生徒Bは繰り返しが多く使われることで、かなり統一性が出てきましたね。
ただ、短い組み合わせすぎるので、ちょっと単純に感じるかもしれませんね。
（テクノミュージックなどにはむいているかも？）

生徒Cは一回「あんなこといいな」が入った後、そのリズムを受けて「EDECAG」と旋律が入り、その後また「あんなこといいな」の旋律に戻っています。

これは実際の人間の作曲でも非常によくみられるパターンです。

[3つのニューラルネットワークのモデルの違い]

今回の実験はgoogle magenta/tensorflowの提唱する Basic RNN, Loopback RNN, Attention RNNという３つのニューラルネットワークのモデルを使いました。

エンジニア方面からより詳しく知りたい方はこちらにソースコードがあります。（オープンソース）

それぞれのモデルは生徒A・B・Cに対応しています。

この３つは「繰り返し」の扱いが違うところが、キモになっています。

Basic RNN -- 生徒A

一番最初の生徒AはLSTM(Long short-term memory)を使った最もシンプルなモデルで基本となるものです。LSTMは主に自然言語解析の分野なんかでよく使われる、再帰型ニューラルネットワークの一部になります。

（たとえば、自然言語の世界では、「私は音楽が好きです」の文の様に「私」の後には「は」が来る可能性が高いですよね。同様に、「私が」と来る可能性も高いですね。でも、「私にゃ」、「私ば」なんていう文はほとんどないですよね。そういったことを予測するのに使用されます。）

繰り返しなどは考慮していない、あくまでもシンプルなモデル。

Lookback RNN  -- (生徒B)

小節の単位の中でのメロディパターンとある音の小節の中での「相対的な位置」を理解しながら、それを繰り返すかどうかを学習していく。通常のニューラルネットワークの場合は、それぞれのセルの中に学習した情報を格納していくのですが、それとは別に、１、ないし、２小節前の情報をインプットしていきます。

Attention RNN  -- 生徒C

Lookback RNNと同じく繰り返しを重要視しますが、1,2小節ではなく、より大きなまとまりで繰り返しを捉え、メロディを生成していく方法。


とこのようにそれぞれのモデルには特徴があります。
後の方に行くに従って、「繰り返し」の要素が、変わっていきそれらしさが変わって行くのです。
（LoopbackとAttentionのどっちが効果的かはケースバイケースでしょう）

[より音楽らしくなるためには]

繰り返しが入ったことで、随分と音楽らしくなりました。

あとは、コード進行やコード進行とは別の起承転結も考慮に入れたいところ。

音楽に精通した方なら、うなずけるところと思いますが、コードなどは、昔のAI（ルールベース）のAIなどで描くとシンプルに表すことができます。

そのため、ディープラーニングに適した分野かどうかは実は疑問が付くと思っています。

アートの分野では、ある程度、ディープラーニングとルールベースの組み合わせが必要になって来るのでしょうか、なんて思ってます。

（そもそもコード進行が音楽に必要か？なんて話もありますが）

Mac os X上のtensorflow GPU でImage not foundエラーが出る時

PCの計算量の多い時には必須のGPU

Mac os X(el captain 以降）で、tensorflowのGPU版を動かそうとすると、

image not found エラーになることがあります。

ImportError: dlopen(/Users/daichi/.pyenv/versions/3.5.2/lib/python3.5/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so, 10): Library not loaded: @rpath/libcublas.8.0.dylib
  Referenced from: /Users/daichi/.pyenv/versions/3.5.2/lib/python3.5/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
  Reason: image not found


Failed to load the native TensorFlow runtime.

See https://www.tensorflow.org/install/install_sources#common_installation_problems

for some common reasons and solutions.  Include the entire stack trace
above this error message when asking for help.

これは環境変数　LD_LIBRARY_PATHかCUDA_HOMEが通ってない時に起こりがちですが、まずそれを確認します。通っていなければパスを通す。

(tensorflow) koala:tensorWorkspace daichi$ echo $LD_LIBRARY_PATH
/usr/local/cuda/lib:
(tensorflow) koala:tensorWorkspace daichi$ echo $CUDA_HOME
/usr/local/cuda

両方とも通っているのにエラーが出る時はSIPというセキュリティ関係のサービスが原因のことがあります。
こちらの記事を参考に停止しましょう。

GPUをオンにすると
筆者の場合は シンプルな画像分析で、615秒->383秒と90%高速化されました。
最新モデルだともっともっと早くなるでしょう。

name: GeForce GT 650M

major: 3 minor: 0 memoryClockRate (GHz) 0.9

# GPUなし場合

'start train with eval'

Epoch 1: ./data/data_batch_1.bin

Epoch 1: ./data/data_batch_2.bin

Epoch 1: ./data/data_batch_3.bin

Epoch 1: ./data/data_batch_4.bin

Epoch 1: ./data/data_batch_5.bin

epoch 1 duration = 615 sec, prediction = 0.359

#GPU ありの場合

Epoch 1: ./data/data_batch_1.bin

Epoch 1: ./data/data_batch_2.bin

Epoch 1: ./data/data_batch_3.bin

Epoch 1: ./data/data_batch_4.bin

Epoch 1: ./data/data_batch_5.bin

epoch 1 duration = 383 sec, prediction =  0.359

しかし新型Mac book proはなぜ、NvidiaじゃなくてAMDのGPUを積んだんだろうか。。。。

NSynth - Googleが生み出した人工知能シンセ！！

以前の記事でも触れた

人工知能(Tensorflow Magenta)で作曲してみた

にも関わりますが、Googleのプロジェクト magentaに新しいプロジェクト

NSynthが発表されてました。

普通のシンセサイザーといえば、発振器とサンプリングされたwave波形を使って音を合成していくものでした。

こちらは、ニューラルネットワークを使って、大量のデータから特徴量を抽出して、サウンドを作っていくのが特徴。

そして「特徴量を抽出」する方法が、ディープラーニングの肝なのですが、今回のシンセは同じく昨年googleが昨年開発した音声入出力技術のWaveNetがベースになっています。

サンプリング型のシンセサイザーだと、音がある程度以上（３秒以上）伸びると、波形が不自然になっり、単調になったりしやすかったですが、今回はそのあたりの「間」や「息遣い」なども、ある程度表現してくれるようです。

しかし、これをどう使ったらいいかというのは、まだまだ？？の世界。
magentaの自動作曲と組み合わせるともっと面白い効果を生み出せるかもしれません。

本来人の脳を模倣するために生まれたニューラルネットワーク、いつしか人の脳を飛び越して、人類が聞いたことのないような音を生み出していってほしいですね。

携帯用洗濯袋Scrubbaが超便利だった話。

旅先で、出張で困るのが洗濯。

ホテルで洗濯に出したとき、kg単位で洗濯してくれるなら良いですが、クリーニング扱いになって、H&Mの千円くらいのTシャツ一枚をご丁寧に、うやうやしく畳んだ上で数百円取られたりすることもあります。

それもなんだか馬鹿馬鹿しいので、こんなの買ってみました。

Scrubba Washbag スクラバ ウォッシュバッグ 携帯用洗濯袋 2017年モデル

要は防水の袋＋洗濯板というアイディア商品のようですが、かなりおすすめです。

洗濯物と、洗剤を入れ蓋をして、上から揉む（自分は足でふんでます）

その後、また、水を入れて、ゆすぐ。

この突起の部分が、洗濯板の役割をするんですね。

ビーチなんかでたまに見かける防水かばんと同じ、仕組みを取り入れているので、防水性は極めて高いです。都合３０回ほどつかっていますが、全く水漏れしていません。

ここは余分な空気を抜く穴。

気に入ったポイントは。

• 袋状なので、水をあまり使わない。
• 手が濡れない
• デザイン
• 小さく、軽い。

ただ、大きくはないので1日程度の洗濯物しかできません。

長期の外出に洗濯って結構厄介なものですよね。

洗濯って、もっともっとイノベーションができそうな分野です。



ちなみにこの手のUSB型小型充電器もあって、悩んだのですが、、、、

Konomise 超音波 多機能ミニ洗浄器 洗濯機 USB充電式 携帯型 節水 子供衣類/タオル/下着/野菜/果物などのもの洗浄 出張/旅行/ホームにピッタリ

「超音波」というのに、いまいち期待がモテないのと、
一度にあらえる洗濯量が少なそうなので、やめにしました。

洗濯袋タイプとこのUSBタイプが組み合わせたものが出ると、よりいいかもだけど。。。

人間と人工知能同じテーマで作曲勝負！してみた

今回使ったのは、人工知能音楽作成サービスAmper

テーマは、サントラ風楽曲で、「2012」的なパニック映画、世界が滅亡するような、ダークで重い、でも、ビートの激しい感じ。。。。

さあ、人間のミュージシャン（僕）が作ったものと比べて見てください！！！

ほら、人間の方がいいでしょ！！！と
といいかったのですが、これ、もうわかんないよね。。。。

というか、人工知能版の方が、楽器が多かったり、リッチな印象すらあります。

人間版はタイトに削ぎ落としたとも言えるのですが。

反面、すこしマンネリしがちな人工知能版に対して、ブレイク的な空白があったりと、人間版の方が、メリハリがある構成になっています。

まあ、どっちがいいかはもう好みとしか言いようがありません。（これがすでにすごいのですが）

とはいえ、人間が１曲作る間に、AIは100曲でも1000曲でも生み出せますから、生産性においては、全く叶いそうにありません。

Amperはアルゴリズムが公開されていませんが、おそらく、ある程度のプリセット楽器のパターンに沿って、MIDIを生成し、音に変えているのでしょう。

以前の、人工知能で作曲してみた　のときはgoogle tensorflowとmagentaを使って、メロディMIDIだけ生成したのですが、それと同じようなことを各楽器ごとに行い、またコード進行などもチューニングしているような感じがします。


ちなみに人工知能作成の方は、人工知能マスタリングのLANDRで音圧調整もしています。一切人の手が入っていません。


（＊人間版の方は、以前とある雑誌の企画で作ったもので、今回新たに作ったものではありませんが、同じコンセプトでの作曲という意味ではよかったかと。）