正直なところ今のBambooTrackerの機能面や操作に関する不満点があって，今年の初めくらいにはまだ改良案や今後の予定を考えていた． また，個人的にプロジェクトが進みすぎてあまり大きな変更ができなくなっていたので，設計を大幅に見直した新しいYM2608のトラッカーを考えたりしていた．
けれどもここ半年で普段の生活が忙しくコーディングから離れる時期が多かったり，自分の音楽的・プログラミング的興味がトラッカーからピアノロールに移ったりした結果，今後の開発に対するやる気を失ってしまった．
今後は積極的に機能の追加や修正を行わず，バグ報告が来たらその都度修正するくらいのリアクションしかしないつもりなので，考えていたアイディアは今後実現しないと思う．
ただせっかく考えてたものだし，もしBambooTrackerに不満を持つどこかの誰かが新しいトラッカーを作るときに，何かしらの参考になればと思ったので，計画していたトラッカーのアイディア（裏を返せば「ここがダメだよBambooTracker」）をいろいろ書いてみることにした．
もう既にやる気が無くなって時間が経っているのでアイディアも忘却の彼方に飛んでいきそうだけど，とりあえず思い出せたものだけ書き連ねておく．
エミュレータ上で動く専用ドライバによって曲の再生を制御
やっぱりPC-98実機で作った曲を鳴らしたいという声が結構みんなから出てきていた．
BambooTrackerでは作った曲を実機で鳴らすのならVGMやS98で書き出せばいいというスタンスだったけど，それらのフォーマットでサポートされていない外部PCMを使う機能や割り込みタイマーを使ったSSGの音色づくりができなくて，結果的に自分が最初に欲しかったSID voice機能も実装できずじまいだった．またログ形式のフォーマットでは曲データのサイズが大きくなってしまうので，できるだけモジュールのデータ構造とその再生ルーチンをそのまま実機に持っていけるようにすべきだった．
自分は別にPC-98上でトラッカーを使った作曲をしたいわけではなく，再生さえできればいいと思っているので，トラッカーの再生ルーチンをエミュレータ上で実行する形で考えていた．
グラフィックの部分と内部処理の部分を分けた構造
MVCモデルとか全く知らずに開発を進めてきたので，グラフィック部分と内部処理部分でやってることが重複してたり，コードが密になりすぎてるところがあって編集しづらい．
最初からガワはガワ，ウチはウチで処理をしっかりと分けた構造にすべきだった．
特に再生ルーチンなどはlibbambooみたいな感じでライブラリ・モジュール化したほうが後々色々使いやすかった．
内蔵タイマーを用いたテンポ指定
BambooTrackerでは1カウントはModule propertiesのTick frequencyで設定した値に固定される．
またSong SetttingsのSpeedは1ステップ中の基本カウント数になっており，実際の1ステップ中のカウント数はTempoの速度に近くなるように動的に変化する．
このため，ノートディレイエフェクトなどディレイ系のエフェクトで設定したディレイカウントがTempoの値によっては1ステップのカウント数よりも大きくなってしまい，実行されなくなることがある．
これに対し，PMDなどではTimer-Bを用いたテンポの設定を行っているようだ．
また全音符に対するカウント数を指定して音符の長さを決定する．
このようにTick FrequencyとTempoを統合して，Timer-Bを用いたカウント速度の変化をするパラメータと，1ステップのカウント数を指定するパラメータで演奏速度を制御する．
この場合ではステップ中のカウント数は固定されるので，前述のディレイエフェクトの実行漏れが起こることはない．
ゲートタイム指定
ステップ中のカウント数が固定されれば，事前に次のノートオフまでのカウント数を計算しやすくなる．
MMLでよくあるパターンで設定したノートオフの位置の何カウント前のタイミングでノートオフを実行するゲートタイム指定（なぜか"クオンタイズ"という名前になっていることが多い）をトラッカーに実装することが可能になるのでは．
速度変化やソングポジション変更エフェクトをそれぞれ専用のパターン列で管理
BambooTrackerでは速度変化やソングポジション変更エフェクトは，曲の再生動作に影響を与えるので他の音符を装飾するエフェクトの実行前に読み取る必要があった．
ここでいちいちすべてのエフェクト列からテンポチェンジやポジションジャンプエフェクトを検索して読みだすのは時間がかかる．
またこれらのエフェクトは同じステップに存在する場合は最後に宣言したもののみ有効であり，複数宣言する意味がない．
また同じ種類のエフェクト宣言が同じステップに複数存在し，もしそのエフェクトを削除したい場合，正しく同ステップ中の全てのエフェクトを削除しなければ意図した動作を示さず，ユーザー側としても作業に手間がかかる．
よって通常のトラックとは別にポジションコントロール列とプレイバックコントロール列を用意し，その中で1ステップに1つのみ宣言できるようにする．
シーケンスプロパティの終端実行後にデフォルト値に戻す
アルペジオなどでFixedシーケンスの最後のデータを実行した後，BambooTrackerではそのままの値を保持する．
これだと，SIDの曲でよくある最初の数カウントのみ音高を固定にしてドラムの音色を作り，その後入力した音程でベース部分を鳴らすようなインストゥルメントが作れない．
FamiTrackerはシーケンスの最後のデータを実行後に入力した音高にピッチを戻しており，SIDで曲を作る際に散々使っていたこの挙動をなぜ採用しなかったのか過去の自分の決定に後悔している．
シーケンスエディタでのラインツール
特にSSGやADPCMのエンベロープを指定するとき，マウスではフリーハンドでしかシーケンスを編集できないので，直線的な変化をきれいに書けない． 一応等差数列を生成するMML書式を追加したけど，そのためだけにテキストで数値を入力しないといけないのは面倒くさいので，ラインツールを用意した方が良い．
SSGのWaveformとEnvelope設定の単純化
SSG部分でBuzzer effectなどのハードウェアエンベロープを用いた音色を作る際に，WaveformとEnvelopeの各設定でミキサーや音量に関するレジスタの値の管理が重複し，管理が難しくなった結果バグが多発した．
Buzzer effectなどのAtari STのPSGで使われる技術をOPNA界隈のユーザーはあまり使っていない（自分もあまり使わない）ので，分かっている人や挑戦してみたい人が触れるようにするくらいの補助的な機能にした方が多分コードも楽になる．
エディタとしてはArkos Tracker 2みたいなのを持ってきたらいい．
ピッチの値をレジスタに直接反映
YM2608のFMやSSGのピッチは線形的ではなく対数カーブのように変化する．
厄介なのはこれがセント単位に線化するわけではないということ．
つまりビブラートなどで低音域と高音域でピッチを設定するレジスタに同じ値を加算しても，実際に変化する量は異なってしまう．
BambooTrackerではこの挙動を嫌って，半音をセント基準で32分割したもの1つの変化量と定義し，あらかじめ用意したピッチテーブルを参照することで，音域に関わらず同じ分だけ変動するようにしている．
ただPMDなどのほかのドライバではどうもこんな操作は行っていないようで，逆にMMLで作った音色をBambooTrackerに持ってきたときに思った音が鳴らないということが起きたりした．
もともと新規勢が少ないYM2608のチップチューン界隈では，過去の先人たちが作ってきた資産を活かせることが非常に重要だと後々になって感じたので，あまり独自機能に拘らず以前からあるものの挙動に従った方が良かったと思う．
Coarse VolumeとFine Volume
FMの音量はオペレータ（キャリア）のTLパラメータを操作して調節する．
パラメータは0から127までの値を取り得るが，それは対数的な変化をするため実際には85-127のあたりしか使わない．
ここでPMDのようにさらにこの区間から音量変化が線形的になるような値を抜き出しそれをCoarse volumeとして管理する．
また，従来のパラメータ単位の音量値をFine volumeとして管理する．
基本的にはCoarse volumeを基にしてトレモロやボリュームスライドを実行したほうが直感的だと思う．
いい感じのボリュームスライドエフェクト
BambooTrackerのボリュームスライドエフェクトは1カウントごとに変化値を音量レジスタの値に加算しているので効き強すぎてどうも使いづらい．
しかもエフェクト宣言後の次のノートオンではスライド前の音量から再び変化しだすので，やっぱり使いづらい．
これはCoarse volume基準の音量変化と変化の更新するカウント間隔を指定できるようなボリュームスライドにすべきだった．
またノートオンに反応しないようにすることで曲をフェードアウトさせるという場合に使うこともできる．
任意のオペレータに対するエンベロープの設定
FMの効果音モード（BambooTrackerではFM3ch拡張モード）を使うときに，4オペレータのうち2オペレータずつを使って2つの音色を鳴らすということが良くある． この時一方の音色を別のものに変更したいということが多々あるが，BambooTrackerのインストゥルメントの設定は4オペレータ単位で値を書き換えるので，あるオペレータのみエンベロープパラメータを変更するということができない．これをFM3chではそのトラックに対応するオペレータのパラメータのみ設定されるようにする．
特定のドライバに依存しない曲のエクスポート
これはかなり難しいし，どちらかというと自分の要望に近いのであまりトラッカーづくりには参考にならないアイディアだと思う．
先に演奏用のドライバが必要とか言いながらだけど，個人的には特定のドライバで再生するための新しいファイルフォーマットが出てくるのはあまり好きじゃなくて，統一規格みたいなのがあった方が良いと思っている．
つまり，トラッカーだけでなくPMDやFMPの曲もおなじフォーマットで，一つのプログラムで再生できるようになるのが理想．
あまり詳しくは見れてないけど，ファミコンのnsfやC64のsid，Atari STのsndhみたいなものが参考になりそう．
他にもGitHubのIssuesでenhancementラベルがついてるリクエストされた機能が実現できたら理想的． また実機で鳴らせるかというところに重きを置くと，今のトラッカーのモジュールのフォーマットやつくりにも冗長なところがあったりいろいろ怪しいところあるし，多分いろんな制約の中で切り落とさないといけない機能が出てくると思う．
というか，適当につらつらとアイディアを書いてみたら思った以上に文章の分量が多くなってしまった． ここまで書いたのならお前が作れよってツッコみたくなる内容だ． まああれこれ考えるのは自由だし面白いけど，それを実際の形にするのが大変で難しい． あと多分自分が次にシーケンサを作るとすればトラッカーではなくピアノロール形式になると思うので，ここで書いたものとはまた違った設計になりそうだ． というわけで他力本願ですが，誰かこういうの作ってください，お願いします．
