堕天使の煉獄

ちょっとまたプログラムのほうやるかなーって
気がついたら２週間ぐらい経ってるしｗ

最初の一週は、ＱＴでのＭＩＤＩシーケンサ作り。

んんーやっぱ相変わらず、ずっと前から悩んでいるところで詰まる。


上のはトラックの中身のＭＩＤＩデータの生データを
グリッドコントロールに流し込んだだけの物。

んで、こっちは多少データに加工した形での表示。


うむう。
結局のところ、どういう形でＭＩＤＩデータを持つのが良いのか
未だに決まりかねているぽ。

でも悩んでばかりいても仕様がないので
とりあえずどんな形でもいいから進めてみて
そこから見えてくる問題点を洗い出してみようってことで
行く先も定まらぬまま進めてみたのだけども。

ふむう。
ますます悩む結果に。

んー
ＭＩＤＩイベントのコントロールチェンジを例に取ると
生データではステータスバイトがコントロールチェンジであることを示し
中身はコントロールチェンジ番号とパラメータが入っているのですが。

そして基本、普通のノートイベント（音符）とかも
基本おんなじ形態のデータなのですよね。
ステータスバイトの違いで見分けるかんじで。
（面倒なのがイベントによってデータ量が固定ではない可変バイトのイベントもある・・・）

しかし、イベント一個取り出す度に、このステータスバイトは・・・
と調べるのもめんどくさい。

オブジェクト指向的には

ＭＩＤＩイベントクラスという、単体のイベントを表す基底クラスを作って
派生でノートイベントとか各種コントロールイベントとか
やったりする方法が浮ぶのだけども。

しかしＭＩＤＩデータってこのイベントがウン百とかあるのですよね。
１トラックに。

それが通常の使い方だと１６トラックあるわけで。

そんだけの数のオブジェクトをｎｅｗとｄｅｌｅｔｅするのは
かなりのコストがかかるぽ。

速度と扱いやすさ。
それから編集のしやすさと、いろんな要因が絡んで
最終的にどういうデータ構造にするのが良いのか。

ますます頭がこんがらがってくるぅ～

なんていうか、
そもそも、もともとのＭＩＤＩの形態にこだわるからいけないような気がしてたり。

ＭＩＤＩフォーマットっていうのが
むかしの低速な秒間数バイトしか通信できなかった時代のフォーマットなので
ものすごく効率重視で、生データのままではとても扱いにくい形なのですよね。

しかし、一般的な音楽ソフトではスタンダードな形式なので
入出力出来るのが望ましい。
なのでついつい、それに倣ったデータ構造にしてしまいがちなのですが
いっそ、かなりがらっとかえて、もっと独自のデータ構造につくり変えるべきかなとか。

基本的には、とある基準による時間軸毎に
イベントをＭＩＤＩデバイスに決まったフォーマットに整形して送信する。

その要件さえ満たせば良いわけですから。

その辺で発想の飛躍が必要だな……ということで
また塩漬けにすることにｗ


んで次の一週はゲームプログラミング。

また1から組み直し中（何度目だろう…

今度はゲームのエンジンというかフレーム部分を
LIB形式で書き出せる形の物をつくってみようかなと。

なので、後から弄る必要のある部分と
弄る必要のないもの（こっちはlib形式で固める）
一部だけ弄る必要があるものはそこだけオーバーライド出来る様にする。

とか、根本的に設計からやり直してる感じです。

今のトコ
DirectXの初期化
シーン管理
フォント
システム効果音
キー入力（コンフィグ付き

といった基本的なところはほとんど出来て
汎用的なボタンとかのＧＵＩ部品てきなものを作ってたりしたところで
ちょっとプログラムも食傷気味になってきたなー。

と思ったのが今日。

んで、ふり返ったらもうプログラミング週間が
２週間もつづいてたのかとびっくり。

ということで、設計メインだったこともあり
偏頭痛とか出だしたのでちょっと別のことやろうかなと。