怒濤のPD会第５回、今回はグラフィックな話が多め
http://d.hatena.ne.jp/nagachika/20091128/pdkai_05

で、その後の忘年会
いろんな話が飛び出していたけど、
１つピックアップするとしたら
ファミリーベーシックの話かな？

ふと、改めて思うと、
あの、数行でマリオが十時キーコントロールできて、
マリオのアニメとかがライブラリ化（クラス化、カプセル化）されている状況って面白かったと思った。

これとPD会で発表したQuartzComposerとXCodeからの呼び出しの関係が似ている気がした。

マリオがアニメーションして座標を移動して十時キーのコントロールに対応するプログラムを書こうとしたら、マリオのキャラクターアニメーション処理や、ビットマップパターンの定義またはリソースの読み込み、アニメパターンの読み込み、描画処理、スプライト制御などとても複雑。

たしか、ファミリーベーシックでは、BGエディターがあったりして、絵をデザインする部分はプログラムとは別にしていたような。
ゲームのあたり判定とか処理の部分のみに集中して、デザイン側は別なもので作る（か既にあるマリオのクラス？サブルーチン？を使う）
という作り方って、
実はゲームとかでもスクリプトエンジンとゲームシステム、デザインツールと分かれているのに似ている気がした。

QuartzComposerでも様々な入力を用意して、絵作りができるけど、プログラムを書こうとするとjavaスクリプトやXCode上で処理する方が楽だったりする。（それでも苦労する部分もあるけど）

・他のプログラミングでも・・・

iPhoneやMacOSの開発も、InterfaceBuilderとXCodeで組み合わせてやることで、デザインとコード処理とを組み合わせている。既にある扱いやすい部品がAppleらしさをもっているので、手軽にAppleっぽいインターフェースに仕上がる。
プログラム面ではCocoaというライブラリが大活躍することに。

Windowsだと.netフレームワーク上にいるはずのVisualStudio上でコントロールのデザイナーを開くとエディットできる。（けどWindowsはXP,Vista、7とデザインが微妙に違うのを共有するのであまり凝ったシビアなデザインをすると後ではまる。色決めとかもユーザー任意で変えられるのをかなり意識しないといけないので、デザインの幅は狭まるが、Appleのようにインターフェースガイドラインが無いので自由に作れる面もある。（一長一短ですが）プログラム面では.netフレームワークというライブラリが大活躍なのですばらしいですが。

レゴマインドストームとかでも、レゴのブロックを組むところはデザイン（？）だけど、モータとかの制御は別のパッチで作る事になる。

DAWとかでも、音の配置はアレンジ上で行うけど、エフェクトとかのルーティングなどパッチベイ的なものやシンセの設定は別な部分（プラグイン等タイムライン以外のエディタ）で行う。

あ、そう考えると、PDやMaxMSPでは・・・
絵を定義するのもオブジェクトなのでちょっと大変ですね。
MaxMSPであればjavaとかでも内部で書けるけど、ちょっと面倒か。あるいは自作オブジェクトを作ってしまえばいいのかもしれない。

・まとめ

ということで、話がそれましたが、ビジュアルとプログラミングの切り分けをしているのってありだと思うのでした。

ちなみに、CRI AudioのコンセプトもAISACと言われるデザイナが自由に拡張可能なコントローラをパブリッシュ？することで、プログラムから音をいじれるようになります。

これって、ある意味楽器の鍵盤とか、ミキサーのフェーダーとか、ギターのフレットとかを用意するのに似ている。
（ライブラリ化、カプセル化する、あるいは楽器化）
実際にゲームでは、「足音を鳴らす」「爆発音を鳴らす」「エンジン音を鳴らす」「環境音を鳴らす」といったCue（トリガー）になる。

音の鳴り方はデザイナが作って、実際にトリガーしたり、値を決めるのはゲームから行われる。

複雑なものを隠す（カプセル化）するって昔からあるけれど、その隠し方が扱いやすいライブラリを決めているのかなぁ。

そして、ちゃーりー的な最初の経験としては
なるほど、元はファミリーベーシックだったのか。

ということで、これからも便利なミドルウェアを目指しますので、ゲームやその他、様々な用途に応じた
音や音楽をコントロールするアイデアなども随時受け付けています。
気軽にご相談下さい。
よろしくお願いします。