画面仕様はほぼ固まり、今は具体的に配列とリンクさせる作業にかかっているyo

考えた結果、zj, pj, dj という３つの配列を骨組みにして次世代ソフトを設計することにしたyo　zjは編集段階で利用するもので、すべてのパラメータや音符情報が手っ取り早く読み書きしやすい構造で格納されるyo　それとは別にドラムエディター部分で作っているドラムパターンの情報はdj配列に格納するyo　そもそもがドラムグリッドは整然とデータが並んでいるので、こちらはSMF化しやすい順番に並べているyo　ドラム音の場合、鳴らしっぱなしでも勝手に消音してくれるのでラクなんだよne

pjは、zjとdjのデータを元に全体の再生用ファイルとして最適化した配列だyo　再生時、書き出し時などにその都度一括で生成するyo　pjを生成しておくと、再生時にループするルーチンでの演算量を劇的に減らせて、ただ読んだ音符を鳴らしていくだけでよくなるので、マシン負荷がかなり減るはずだyo　さらには、ほとんどSMFフォーマット0に近いデータ並び順になっているので、最終的にSMF書き出しをするところまで持っていくのが非常にラクというメリットもあるyo　

まあ、これによってリアルタイム操作性がどこまで損なわれるかは未知数だけど、かなり大きな変更を演奏中に行ったときにちょっと待たされるくらいは普通だよne　軽微な変更くらいなら自然に流れてほしいところだけどw　そこらは今後調整してみるyo　なんならリアルタイム変更は廃止にしても別にいいくらいだけどne　だって基本「自動ジャムマシン」だから、再生中はボク自身の手はふさがっているのが前提だからne（微笑）　リアルタイム操作はおまけなんだyo（詭弁笑）

実際、なんでもかんでも即座に反映して演奏されるという構造でつくると、必ずどこかで思いっきり負担をかぶる箇所がでてくるyo　「すぐやる課」に全部押し付けて、他の課は鼻くそほじくって遊んでる役所みたいにne　ここまでのBeatでは、「PLAY」後にグルグルとクロック周期で反復実行しているtick()というファンクションにすべてを丸投げしていたので、そこでの処理の重さはハンパない状況になりつつあったyo　そのかわり、いかなる変更もtick()が読み取って次の周期で反映してくれるので、リアルタイム操作をするには都合がよかったんだけどne　でも、更にドラムパターンの管理・加工の仕事まで押し付けたらさすがに動作が苦しくなるのは目に見えているので、ここで次世代ソフトに移行するというわけだyo（理想の上司笑）

[0回]