人のコードを読むと勉強になる，とは昔から言われる話だけど，やっぱり実践してみるとその意味が解る．
Furnace Trackerはいろんな音源に対応しているから，どのようにして再生管理しているのか気になっていたので，ちょうどSCCI対応化しながら確認している．
パターンからのデータの読出しはオーディオバッファの生成時に必要な分をまとめて行っていたのでBambooTrackerと同じような動作だけど，パターンからのデータ読み出しのタイミングで直接レジスタに書き込むのではなくいったんキューにため込んでから合成時にキューの内容を取り出して処理している形だった．
FamiTrackerもこんな感じの構成だった気がするけど，これはデータ読み出し中にジャミングなど非同期処理で割り込みが入ってもキューに入れるところで吸収してオーディオサンプル合成自体はスレッドでデータ書き換え競合が起きないようにしているのだろうか．
再生時のUI描画更新とオーディオ生成処理はどのようなタイミングで行っているか気になる．
BambooTrackerではオーディオサンプル生成時に読み出し位置のソングポジションが変更されたときにUIを更新しているので，オーディオバッファが大きくて一回のオーディオサンプル生成時に複数ステップ移動した場合にいきなりソングポジションがジャンプして描画更新されるので微妙にカクついてスクロールされる．
実装の参考にしたGoatTrackerが同じ動作をしていたけどほかのトラッカーでは滑らかに動いていたのでどうしているのか気になる．
あとは昔から付けられずじまいになっているトラック別ボリュームインジケーターについても見ておいたほうが良さそう．
