OpenMIDIProject

>今回の場合、「1バイトのLENで収まらない場合」を例外処理として、例えば「LEN=0として新たな様式を用意する」に持ち込>めばよい気がします。例えば、
>　unsigned char m_lLen;　　　// イベントのデータ長さ[バイト]
>　unsigned char* m_pData;　　// m_lLen==0の場合はm_pData[0-3]を長さにしてm_pData[4]以降にデータを保存
>とでもすれば可能な気がします。

LEN=0のメタイベントもありますので、0以外(例:-1)でマークする必要があるのと、
LENがunsigned char型だと1変数ごとに整列するのでたぶん構造体に穴が開きます……。

という細かな問題はさておき、実装方法についてはいろいろな案があると思いますが、

(a)4バイトを境界に固定エリア使用と別途mallocを切り替えるか、
(b)256バイトを境界に固定エリア使用と別途mallocを切り替えるか、
(c)MIDIEvent構造体自体を可変長とするか、

は、

(a)多数発生する構造体のコンパクトさを優先にして、別途mallocの回数を若干あきらめるか、
(b)多数発生する構造体のコンパクトさを犠牲にして、別途mallocの回数を極限まで抑えるか、
(c)内容変更であっても上層のプログラマにMIDIEvent構造体へのポインタを正しく指し直すことを要求するか、

という作者の設計スタンスや感性の違いになってきますし、
メモリをどのぐらい搭載・消費できるのかという時代背景によっても違ってきますし、
ライブラリを誰が何の目的で使う予定なのかによっても異なってきます。
場合によってはmallocは危ないので使用禁止というのもあります(すべて完全固定長)。

MIDIDataLibの場合は(a)を採用しています。
イベントの種類で切り替えているので厳密には4バイト切り替えではありませんが、
大部分を占めるチャンネルイベントが別途malloc不使用となれば良いと思った次第です。
あと、メタイベントとSYSEXイベントは、SMFに長さ領域が確保されているので、
本質的に可変長(例外扱いできない)で、将来性を考えるとこれを軽視するわけにはいきませんでした。

(b)でなく(a)なのは、
開発当初のパソコン(Windows95)は、メモリが16MBのパソコンが普通でしたので、
メモリの有効活用のため、MIDIEvent構造体をなるべくコンパクトにしたかったためです。
現在においても消費メモリ量が少なくて済みます。

(c)を辞めているのは、
MIDIEvent構造体のサイズがイベントの内容によらず固定長で、
内容変更では上層プログラマにポインタの指し直しを要求しないことも重視したためです。
ポインタいじりはバグの温床となりますので、同じものを指している限り変わらないのが理想です。
FILE* pFileの値がfopenからfcloseまでの間に変わってしまうと困るのと同じ意味です。

なお、上層プログラマから見て、常にm_lLenが正しいデータ長を表し、
常にm_pDataはデータのアドレスを指すようにすることで、
固定領域・malloc領域のどちらが使われているかは気にする必要がない(隠蔽されている)
ようにしてあります(バグがなければ)。

時に、MIDIの特徴を考え、わたしのスタンス・感性でこのような方法を採用しましたが、
人によって別の手法を採用すると思いますし、
良いものが出来上がればそれぞれが正解だと思います。
今回ソースを読んでいただくことで、データ構造とアルゴリズムの話ができ、
わたしも開発当初の気持ちを思い出すことができて、良かったと思います。