だから、往復したい場合は２本必要なのです。
バカ！バカ！バカ！（パンクブーブーのローソン担当風）

Amazon でもう一本注文しました。親切にも「この商品は注文しました」と表示が出ております。ありがとう、切ないけどもう１本必要なんだそうな。

先月と今月は立て続けに時間がかかる仕事が入ってきておりまして、土日もない状態となっております。仕方ないので食事中に本とかマニュアルを読んだりしているのですが、音作りの解説書とかにフーリエの冒険で読んだ内容とか出てきて感動モノです。当時はワケも分からず読んでましたけど、９年くらい経って再開できるとは思いませんでした。

当時、ゲーム開発にフーリエ変換が必要という謎の先入観がありました。どっちかっつーと音だったのだろうか…

時間がなくて調べきれてないのですが、 DirectMusic で使えた模様。しかしながら、 DirectMusic が非推奨コンポーネントになってしまって、今は使えるのかわかりません。 COM なのでコンポーネント自体がなくなるということはないハズなのですが、 SDK が継続的に提供されるかはわかりません（というかたぶん継続されないと思います）。こういう無理はしない方が良さそうかも。

時間使って調べたい。

ちょっと前に、ドラびでおさんというアーティストの方が、ドラムとコンピュータを MIDI ケーブルで繋ぎ、ドラムを叩いてリアルタイムに MAD 映像を操作するというパフォーマンスをされているのをテレビで目にしました。そこで MIDI ケーブルに流れるのは波形ではなく何かの信号なのだと気がつきます。

そこでわかったのが MIDI 機器、特に音源は信号を受信した段階ですぐに音を鳴らすという点です。つまり、曲を演奏しようと思ったら、音を鳴らすタイミングは信号を送る側が調整しなければならないのです。昔の Cakewalk のようなソフトウェアを MIDI シーケンサーと呼んだのはそういった理由からだそうです。ピアノロールで設定したタイミングに合わせて MIDI 信号を送るのが役割だったようです。

…となると当然の疑問が湧いてきます。 MIDI 機器は一度にどれだけの信号を処理できるのでしょうか。処理性能はハードウェアによって異なるでしょうが、ケーブルに流せる量は決まっているはずです（仕様が変わってないとどこかで聞いたような）。

で、調べてみました。規格を見ればわかるだろうとインターネットの世界に繰り出します。

MIDI Glossary

ここによると…

BAUD : A measurement of speed at which serial data is transmitted. MIDI operates at 31.25 kBaud, i.e. data can be transferred at a speed of 31250 bits per second.

…だ、そうで、あんまし転送量は多くないことが分かります。

ノート（音符の情報）の量を送るには十分かもしれませんが、その他の情報をあわせて送る際に問題に遭遇した場合はこのあたりに着目しようと思います。

ちなみに、未確認なのですが USB 接続するととんでもない転送量を実現できるようです。こちらもかなり興味あるのですが、前述の通り、受け側の性能以上のことはできませんのであんまり期待してないです。

同人ゲームの音楽制作機材について調べているのですが、わからないことを聞く相手もいるし、製品のことならお店に聞いても良いはずです。ただ、マニュアルをダウンロードして読むのが一番早い気がしました。

シリーズ物なせいか過去の製品ほどマニュアルがしっかりしていたりして気分が萎えそうですが、頑張ります。

プログラミング

　・コンピュータプログラムを作成すること。→プログラミング (コンピュータ)を参照
　・シーケンサーにシーケンスを設定すること。→ミュージックシーケンサーを参照。

普段 Cubase でやってることを指してプログラミングということでしょうか（今は MIDI しかやっておりません）。確かに手続きを記述するという意味では仕事でやっているプログラミングと同じかもしれません。エクスクルーシブ・メッセージなんかはちょっとした関数呼び出しみたいですし。

同人作品の曲に使う音源を選んでいるのですが、ソフト音源（という表現が古いかも）は音質は良いのですが容量が大きいみたいです。作曲マシンがネットブックに近い XP なので重たい処理はハードに逃がしたい…

• 聴かせどころは最初に持ってくる（戦闘は１分以上続くことが少なく、冒頭部分だけ 1,000 回以上聴くため）
• 60秒を目安に場面転換する（前述の理由から「この敵は何かが違う？」「苦戦してるなぁ…」感を演出する）
• メロディーはローディング＋敵トループ確認終了の直前からスタートする（どこからキャラクターを動かせるのかを曲で伝える）

３つしか挙がらんかったです。思いついたら追加します。

…と、ここで例のごとく、この体験をゲームプログラミングの情報発信に応用しようと考えたときに思うところありなのです。

どんな内容かというと、全く未知の分野を勉強する際など特になのですが、内容によっては聞いてしまった方が早いという領域が多分にあるというのを強く感じるようになったということです。ゲームプログラミングにおけるこれは初学者の方にスマートに突破して欲しいと思うのです。しかしながら、言うは易く行なうは難しというやつで、それが簡単にできたら苦労しないんだと思います。

なんか、ロードマップ的なものがあればいいのだろうか、とか考えました。「今、自分はどこにいるんだろう？」というのがわかるものみたいなイメージで…

うーん、考えないと。

最初はわからんかったです。７ヶ月間はわからんかったですよ。

ゲームプログラミングの学習曲線も異様な感じがしていて、これから始める方にはしんどいだろうなぁ、と常々思うのですが、あらためて８ヶ月という数値を見せつけられると「大変なことをしている」とか「俺にはできないかもしれない」とかいう印象も無理はないのかもしれません。

作曲は他に覚えることがあり、結果がすぐに出るものもありますので、それなりに続けていれば何らかのの成長を感じる（実際に感じた）ものですが、初めて進歩らしい進歩を感じられたのが今。これをゲームプログラミングの情報発信にうまく生かすためには相当なアイデアが必要な気がします…

先は長いです。でも、ひとつだけ再確認したことがあります。ゲームプログラミングを覚えるためのゲーム断ちという願掛けはあんまり意味ない。やはり、最終成果物に触れてないと理解できない基礎が多くありました。

昔、客先の営業さんが、「スランプは誰にでもこないよ、やることをやった人に来るもんだ。そうでないのに上手くいかないのはただ単に調子が悪いだけだろ」と言っていたのを思い出します。なるほど。

もし、今ゲームプログラミングを勉強されていて同じような状態にある場合はどうするのでしょうか。その答えは自分が今をどう乗り切るかですね。んん、がんばろう。