>デルタタイム
なるほど、わかりました

ハッシュにするメリットは、編集時の負荷が少ないと思うからです。
要素をdeleteする場合双方向リストは全くもって問題は無いのですが、
insertの場合、前または後ろから順にたどっていく必要があります。
もちろん、確率的に以前アクセスしたイベントの近くにあるだろうという事で、
そこからたどっていく高速化なんてのもありでしょう。
ただ、イベントが少ないうちはいいのですが、多くなってくると
問題が表面化してくると思いました。
もう一つは、再生しつつ編集するケースで、
その編集結果を、可能な限りリアルタイムで
活かしたい場合、ストリームよりはいくつかのユニットに分けた方が
いいと思いました。
（編集フラグを立て、その間はキャッシュを渡す・・・)
私は実際にやってみた事が無いので，
ハッシュが実際に効果的なのかよくわかりません。

具体的なハッシュの実装方ですが
例えば、３段でそれぞれが１０個の要素を持っているとして
最下段の配列のカバーする範囲が100ticksだとします
すると、100*10*10*10ticks分だけ表示できます
もっと具体化しますと、
上段からクラスA,B,Cとしますと
150tick目のイベントは
A[0].B[0].C[1]->event(50)
となります
また13170tickであれば
A[1].B[3].C[1]->event(70)
となります。（一桁目がAのインデックス、二桁目がBの・・・)
もちろん使われていない部分のクラスはインスタンスかしないので
それ程メモリも消費しません。
でクラスAに
*A next
なメンバをつけると無限長になるのですが
必要なさそうです。
32bitのtickの範囲しか扱わない事にしました。