ついに出たyo　噂の次世代ソフトがw　名前をBeatからJamにかえたyo　Beatはドラムトラックを背骨にした、見たまんま打ち込めば伴奏ループができるというソフトだけど、Jamはコード進行を背骨にした、頭を使って指定していけば楽々ジャムセッションができるというソフトだyo　単純に有名曲のスコアを打ち込んでいくだけならBeatのほうが見たまんまでわかりやすいと思うかもしれないne　でも、Beatはコピーとかが出来るとはいえ、ドラムトラックを全小節打ち込まないといけないw　あと、３拍子や、３連符×４拍、１拍や２拍の小節の挿入などには対応できないし、曲のテンポも途中で自動的に変えたりはできない。

Jamはそういう不可能を可能にするための次世代ソフトというわけさw　ドラムトラックをスコアシートから分離し、小節のドラムパターンを選んで指定するという方式にしたyo　これで何十小節も打ち込む手間から解放されたyo　使用する何パターンかをこれまで通りのドラムエディター画面に打ち込むだけで、あとは「A」とか「B」とか選ぶだけで各小節のドラムが鳴るというわけだyo

そして、各小節ごとに独立して指定可能になった多くのパラメータ。曲全体のパラメータとして選ばれているものにそのまま追従することもできるし、「この小節だけアルペジオで鳴らす」とか「この小節だけピアノのかわりにオルガンで」とか、「この小節だけ３拍子でテンポ２倍に」とか、「この小節だけエンディングなので最後だけだんだんゆっくりに」とか、実にさまざまな指定ができるようになってるyo（呆れ笑）

まだまだ開発途上なので、コードメニューとか、ドラムメニューとかは更なる進化をさせる予定だyo　それにしても「簡単な指定だけであとは半自動でジャムできるようなソフト」にかなり近づいてきたと言えるんじゃないかなw（ドヤ顔笑）　とりあえず動作確認用の便宜をはかるために適当なコード進行を４小節分ポンと入れるコードメニューをつくってるけど、これをカスタマイズすることで、あらゆる進行をあらゆるキーで簡単に試せるような仕組みをつくることも可能だyo　理論書を読んだりしても、実際に複雑な進行を鳴らして確認しながら理解するのはたいへんだったりしたことはないかな？　そんなコード勉強にも最適なツールとして使えると思うんだよne　はっきり言ってボクも音楽理論とかは全然詳しくないんだけど、Beatをいじってるうちに色々体感してきた部分もあるyo　それは、DAWソフトとか何年触っててもあまりピンとくることのなかった感じなので、音楽教育用ソフトとしてBeatとJamはかなり可能性があったりするんじゃないだろうかと思ったりするyo　業務で使いたいという人がいたら連絡してyo　さすがにお金を払ってもらうことになるからne（分け前は当然笑）

[0回]

まだ開発途中の次世代ソフトですが、３拍子、２拍子、１拍子の指定がスムーズに動き始めたyo　これとループタグをからめて、３拍を２回ループさせてから先頭へ戻るとか、最後に４拍子＋１拍子で５拍にして終わるとか、自在にコントロールできるようになったyo　なかなか秀逸でほとんどバグにも悩まされないne　設計思想が非常に優れているからだろうne　あとはテンポ関係の細かな調整を加えたら、とりあえずリリースできるところまでいきそうだyo　まあ、もっと追加したい機能を思いついてはいるんだけど、とりあえず安定して動くものを出してから追加していこうと思うyo　

今日になって、アルペジオのパターン指定がなんかおかしいぞと気付いたyo　調べてみると新しく共用で使うことにした小さな配列を必要もないのに拍ごとに再度、また再度並べ直していたことを発見したyo　どうりで妙にパターンが予期せぬ変化をしていくと思ったyo（苦笑）　内部構造をつくり直すときはこういうなんとも言えない勘違いが発生するので疲れるよne　主にコード演奏でバグとり確認をしていたので、アルペジオでも確認しといてよかったyo（賢明笑）

SMF書き出しはまだ着手してないのでその部分と、コード進行をかなり本格的にインポートする機能と、ドラムに関する付加機能等々を後からバージョンアップしていく予定だyo　そこらへんまでやったら10月末でタイムリミットじゃないかなw（含み笑）

[0回]

さらに廃止したオプションがあるyo　MIDIチャンネルを各パートごとに指定変更できるようにしていたけどあれはやめたyo　ことあるごとに0xB0+mch8などとチャンネル指定変更を反映させるための足し算式を記述しないといけないので、それらを和音×パート数分×消音分発音分毎クロック繰り返すことによる全体の処理速度ロスもバカにならないと思ったのと、記述も冗長になってかったるいことから、チャンネル6〜10にひっつけて並べる固定方式をとることにしたyo　MIDIキーボードが6ch、PCキーボードが7ch、ピアノが8ch、ベースが9ch、ドラムが10chで固定だからよろしくne　ところで、なんでベースを9chにしてるかというと、パンドラPX5D用にMIDIファイルを書き出すときはドラム10ch、ベース9chで書き出すことと仕様が決まってるからそれに合わせているというわけだyo　深いだろ？（納得笑）

そうすることで、各種設定を連続的に行う時に6〜10の連続処理で記述できちゃうので非常に簡潔になるyo　さらには、ミキサー表からMIDIチャンネル指定のセレクタの列を除去できたので、上段の横幅をさらにコンパクトにすることができたyo　そのほか左端のスライダーの幅を少し縮めたので、トラック部分の横幅も少々減らしたyo　全体横幅が1400以上あるから、少しでもコンパクトにする努力もしてるというわけだyo（苦笑）

さて、結構合体作業も進んできて、今は各小節ごとに個別に指定したドラムパターン、ベースモード、ピアノモードを認識して、小節ごとに違う演奏方式をとって動くようにできてるyo　たとえば、第１〜４小節はピアノがアルペジオ、ベースはオート、ドラムはOFFで、第５小節以降はピアノがコード、ベースはオリジナル、ドラムがパターンAとかいうようにw　なかなか細かな指定ができるようになってるだろ？（ドヤ顔笑）　もちろんそんな細かな指定はいっさいなしで、曲全体のデフォルトでいいyoというおまかせ設定でも動くので、細かい人でも大ざっぱな人でも使えるようになっているのさw（頭いい笑）

あと新しい工夫があるyo　これまでクッキーは4KBまでしか保存できないので、曲ファイルを保存するには容量不足で、使い道がちょっと宙に浮いてたんだよne(苦笑)　次世代ソフトではドラムパターン16種類を別途定義するようになっているので、こいつの保存・読み込み専用に活用することにしたyo　つまり、クッキーメニューを開いてリストから選ぶだけで、自分で登録しておいたドラムパターンセット（16種類内包）をどれでも瞬時にロードして使えるようになるというわけ。よく使うパターンを詰め合わせたセットをいくつか登録しておけば、もう曲をかえてもその都度グリッドでいちいち打ち込む必要はなくなるというわけだyo　ボクの漢字変換技術により、どんなに複雑な手数のドラムパターンが16種類であっても、クッキーサイズにおさまることが実証済みなので出来る優れ技というわけだyo

あとは、ABCのループを動かす部分と、悲願の３拍子動作の部分がまだ未調整なので、もうしばらくかかりそうだけど、なかなか凄いものが出来上がりつつあるyo（技術的笑）

３拍子については「Beats」というセレクタをつくり、こいつを４から３に替えて「MAKE」ボタンを押すと、スコアシートから各小節の４拍目のチェックボックス４つが消えて、３×４＝12個のチェックボックスになるところまでは既に完成してるyo　無くしたのではなく、非表示にしてるだけなんだけどne（苦笑）　あわせて、これまで16クロック単位で次小節へ移動していた部分を12クロック単位に書き換えていけばいいだけなので、まあ原理的にそう難しいことではないはずなんだよne　４拍子、３拍子、２拍子の混在も可能な仕様にする予定なので、管理の仕組みは複雑になりそうだけどw（大苦笑）

[0回]

新しい配列同士、関数同士をつなぎ合わせて、とりあえずドラム、ベース、ピアノの各パートが動き始めたyo　トンネルが細い穴で貫通したようなものだne　これまでに積み上げてきた細かな調整部分の多くが作り直しになるので、完全に機能を網羅するには少々時間がかかりそうだけど、動きは軽いし、スクリプトは簡潔だし、これは間違いないと感じてるyo

あわせて、「COPY」メニューの役割が中途半端になるので廃止することにするyo　えっ？あんなにコピーメニューを充実させていたのに？と思うかもしれないne（含み笑）　それは、ここまでのスコアシートがドラムトラック中心で、それをまとめて変更するにはコピーメニューが不可欠だったという事情があるyo　ところが次世代ソフトでは、セレクタの１つで「A」か「A2」か「B」かなどを選ぶだけで、ドラムトラックの内容をころっと入れ替えることができちゃうyo　そうなってくると、小節全体のコピーという操作はベースパートやコード指定などもあわせて変わっちゃうことになるので、かえって面倒な感じになってきちゃうということだyo

今後は、ベースパートのみを操作できる「BASS EDITOR」、ドラムパートの一括アサインができる「DRUM MENU」、コード指定を補助する「CHORD MENU」の３つを利用して各小節のデータを一括操作するという感じになるyo（合理的笑）

なんだかんだで結構完成度を上げていくのに時間がかかりそうなので、あと１週間くらいかかりそうかなw　10月いっぱいでプログラムはいったん手を置きたいので頑張って完成させるかw（人生色々笑）

[0回]

画面仕様はほぼ固まり、今は具体的に配列とリンクさせる作業にかかっている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回]

ボクもこれまでnumberは使ってこなかったけど、これは小さいスペースに押し込むことができるし、マウスだけで値を変えることができるので便利だne　ボクの持ってる本によるとこのnumberに対応してるのはChrome, Safari, Operaだけみたいだne（含み笑）

まあ、対応してないブラウザの場合は普通にテキストボックスが表示されてデフォルトの数値が入って表示されるみたいだから使えないことはないみたいだne　ただし、そこへの変更はすべてキー入力で数値の手打ちになるみたいだけどw（苦笑）

まあ思うんだけど、無料なんだからChrome, Safari, OperaのどれかをDLすれば済む話だしne　そもそもSafari以外での動作は保証してないしw（微笑）

というわけで、次世代ソフトではnumber inputをバシバシ使っていくことにするyo（大胆笑）

ところで、ぶっちゃけどのブラウザが機能的に一番先を行ってるんだろう？　Chromeかな？　ボクがSafariを使ってるわけは、Macのデフォルトブラウザだからマカーなら誰でも使えるというのもあるし、昔からいろいろ作ってきたものがすべてSafariで見たときを基準にしてきたから、今さらブラウザを替えると微妙に余白とか文字とかが変わってしまって、見てて気持ち悪いんだよne　だから無理にブラウザを替える理由がボクには何もないというわけだyo（妥当笑）　逆にChromeにしたら何かいいことあるの？　グーグルの回し者以外の人教えてw（失笑）

[0回]

基本的に上段のメニューはそのまま流用w　ただし、ベース音に基づいてピアノコードを生成は廃止にしようと思うyo　これはまだコード打ち込み機能がないときに無理矢理ピアノを鳴らすために考案した奇策なので、パワーコード以外実用性もないし、ベースラインしだいでは調子っぱずれのコードになってしまうので、これは役目を終えたということでw（惜別笑）

下段のスコアシート部分が大きく変わるyo　１小節１<form>にするので、関数表記がめちゃくちゃ楽になるyo　コード欄、クロック部、ベース表示部分はだいたい同じレイアウト。ベースの表示枠を左右いっぱいまで広げて見やすくする程度w　そこから下がこれまではドラムの各インストトラックだったけど、かわりに様々なセレクタをつけて、小節ごとに指定できるようにするyo　これらをまた例によって何段階かの折りたたみ表示ができるようにして、重要なものほど上に、枝葉の設定ほど下に配置するyo

じゃあ、ドラムのグリッド入力はどうなるのかというと、そうやってシンプルに構成された楽曲の小節が何段か並んで終了したあとに、さらに下方にドラムエディター画面としてとりあえず４×３段＝12小節分を用意するyo　そこではこれまでどおりにイエローセレクタとかを使ってグリッド入力ができるyo　特徴は、それぞれの小節が「A」とか「A2」とかのドラムパターンとして定義されるので、その記号をスコアシートのほうでセレクトすれば、それだけで曲中の小節にアサインされるという方式だyo　デフォルトで「A-A-A-A2」みたいなパターンのくり返しを定義しておけば、エディター画面でわずか２小節分打ち込むだけで曲全体の簡易ドラムトラックが出来上がっちゃうというわけだyo　なかなかの省力化だと思わないか？（微笑）

とりあえず中身の動作は無視して、「MAKE」ボタンで最初にバシッとシートを描き上げる部分だけ作ってみてるところだyo　デザインさえこれだというのに決まれば、あとは自動的に出来上がっていくところがあるからne　左右の寸法もピタリ合わせたし、小さかった文字を少し大きくして見やすくしたりと、なかなか改善効果が現れていて楽しいyo　あとはどのような新配列を定義するのがベストなのか、仕様を詰めていくのがキモだne　それぞれのモードにおいて作らなくちゃいけない配列とかが既にいったん出そろっているので、それらの問題点や無駄な部分などを考えつつ、どうやったらできるだけSMFにコンバートしやすく、かつそれでいてリアルタイム操作性も残した配列と再生エンジンにするかだne　これはなかなか面白い開発になりそうだyo（期待笑）

[0回]

今ポッカリと欠落してる部分について考えたyo　それは16ビート系完成後に移植する予定としていた３拍子６拍子系。それから、現行のドラムグリッド方式では実現が困難な途中で３連符や６連符を使用する変化。あとは曲入力してて思ったのが、途中で２拍や３拍の短い小節を挿入する曲進行。そして、曲途中でのテンポ変更。曲の終わりでのスロー化も含めてw

次世代ソフトの仕様を決めるにあたって、これらをどこまで対応させて、どれを切り捨てるかは悩ましいところだne　ボクがめざしているのは、あくまで自宅練習の友としての「自動ジャムマシーン」なので、せいぜい伴奏としてのベースラインとピアノコードorアルペジオまでが鳴ればいいんだyo　イングヴェイのように６連符で延々とソロ演奏が鳴る必要はないし、プログレのような超変拍子をあらゆる状況でも再現する必要はないyo（妥当笑）

１拍、２拍、３拍の小節をつくる機能はつくろう。パターンは４拍分のものをそれぞれの拍でぶった切るだけの対応にするw（乱暴笑）　そうすることで新たなエディターとかを作る必要もなくなるので合理的だよne　６拍は、３拍を２つ並べることで６拍とみなしてね、ということでw　これは確定。

曲途中のテンポ変更は、各小節にテンポ情報の数値を持たせるだけで実現可能なのでこれは採用。小節内でもしだいにゆっくりとかできないかと言われれば、できないことはないけど、指定がかなり煩雑になりそう。ただし、エンディングの最終小節限定で、いくつかの終わらせ方パターンから選ばせるだけという方式なら余計なインターフェイスを作らなくてもすむのでそういう方式にしよう。多少動作がもたっても、どうせゆっくり終わらせるだけなので大丈夫だろうw（失笑）　これも確定。

問題は３連符だよne　ただ、あくまで伴奏パートの話なので、四分音符１個をボーンと鳴らして、心の中で３連符を刻み、自分はギターで３連符を弾けばいいといえばいいw（脳内笑）　ただ、ずーっとハットが３連符刻むパターンの曲なんかだとそうもいかないw（苦笑）　では、３拍の小節が4クロックx3拍子＝12クロックだから、それを3クロックx4拍子=12クロックに読み替えて、脳内３連符にしたらどうかw　ドラムだけならそれで対応可能だよne　スネアとかもそれに合わせて小節内パターンを打たせるよう入力しとけばいいからw　問題はベースとピアノだよne　現行ではあくまでも４クロック＝１拍で扱わせているから、ドラムとビート感がずれてしまうw（苦笑）　ただし、オートベースとアルペジオではずれてしまうけど、オリジナルベースならそもそも曲に合わせて打ち込めばいいんだから問題ない。ピアノもコード弾きで小節を１つの和音で伸ばすならば、内部をどう認識しようと関係無い。つまり、疑似３連符をやりたければ、モード限定ではあるけど、できることはできるということになるne　これは使う側の工夫でなんとかできるわけだから、無理矢理複雑な機構を入れ込む必要はないということで確定にしようと思うyo

さらにややこしいのがあるよne　１拍目が８分音符で、２拍目が３連符、これを交互に繰り返しというような場合w（複雑な笑）　これはかなりきついne　１拍目は１拍だけの小節を選んで打ち込む。テンポを仮に96とする。２拍目は３連符をつめこまないといけないので３拍の小節をテンポ３倍の288にしてアサインする。これを交互に繰り返せば、やってできないことはないw（呆れ笑）　実際にテンポ３倍なんかにしてスムーズに動くのかどうかも疑問w　ただ、もしファイル書き出しして再生させるならば、実際のsmfデータはたいしたことないのでラクラク再生できるはず。web再生では苦しくてもsmfを介するなら楽勝になるというケースだろう。

それは上記のような複雑なパターンに限らず、単純に曲が長い、和音数が多い、ドラムの手数が多い、などの理由で動作が重くなってテンポが崩れることが考えられるので、曲レベルまでのデータ量を扱うようになった今となっては、再生方法をsmf書き出ししてプレーヤーで再生するというのをメインにすることを考えてもいい段階かもne

さらに言えば、「Zkun MIDI Player v1.0」というのもちょろっとだけ出してたけど、これはJazz-Pluginの機能でplayer()というインスタンス（？）を使って、smfファイルの再生をコントロールしてるサンプルをちょっといじくったものなんだyo　つまり、今までは専用配列を作ってそこからギクシャク再生させていたけど、player()用の配列のフォーマットに合わせて書き込むようにすれば、プロが作った再生エンジンに再生をおまかせできちゃうことになるから、ちょっとやそっとのデータ量程度で再生がよれたりということはなくなると思うんだよne　というわけで次世代ソフトはそのあたりを見越して、内部構造のさらなる見直しを行い、できることを増やして、再生能力も上げるという良いことづくめの進化を狙っていくというわけだyo（新たな野望笑）

[0回]

v3.0までに出そろった技術を、すべてのパラメータにおいて保存・読み込み対応にさせたので、画面上で作業していた環境をまったく同じ状態でロードできるようにしたyo　この曲はピアノは何番目のアルペジオパターンで、オートベースはこれこれのグルーブパターンで鳴らしたのを聴いてほしい、という注文が完全に反映されるのでバッチリな完成度に仕上がったyo

さらにメニュー体系がごちゃごちゃしていたので、上段のメニュー画面をかなり大胆に改革したyo　これによって今必要でないメニューは表示されない、あるいは使用不能状態になるので、今使えるコントロールがどれなのかということがわかりやすくなったyo　常にピアノモード、ベースモードにアクセスできるようになったので操作性がかなりよくなったと思うyo

曲進行タグのAs, Ae, Bs, Be,Cs, Ce, Re, Endもテキストファイルに保存されるし、ループコントロールを有効にするかどうかのチェック状態や各ループの回数も保存されるので、デモソングを読み込んだ状態で指定どおりに進行させることができるようになってるyo　これでもう完全に１曲をテキストファイルで記述することができるようになったyo

次のステップに進むにあたって、ドラムセクションの扱いに大きな変更を加えようかなと思ってるyo　基本となるリズムパターンAとサビ用のリズムパターンB、それらの派生形であるA2, A3, B2, B3のほか、ランダム要素で加工したAx, Bxも生成する。それだけでたいがいの曲は足りるんじゃないかな。それ以外にどうしてもスポット的に使いたいパターンもあるだろうから、C, D, E, F, G, Hくらいは用意して。そう、これはオートベースと同じようにドラムセクションも最低限のパターン定義だけであとは勝手に生成してくれるような方式をとれると思うんだよne　そうなると、もはやすべてのパートで逐一入力する手間から解放されるよne　ただ、これをやるには画面構造からすべてに大ナタを振るうことになるので、上位バージョンというよりは、別ソフトという感じになると思うんだよne　当然ファイルフォーマットもそこで大きく変更することになるだろう。たいへんだけど、半自動化の流れの中では必然的に移行すべきだとは思うよne　オートベースの開発成功は大きなヒントになったというわけだyo

Zkun Beatとしては、もう少し改良進化するかもしれないけど、大きな進化は次世代ソフトのほうで実現させることになると思うので、今回のv3.1でBeatはいったん完成ということになると思うyo　header部も51項目も情報が並んでて、建て増し建築もいいところだけどne（苦笑）

[0回]

最近新しい機能が増えてるから、バグの種類も新しくなってきてるyo（大苦笑）

先日直したバグ。圧縮したファイルを自動解凍するときに、コピー元の小節が１ケタ番号なら正しく動いてたけど、#18小節とか２ケタになるとおかしくなってた件。これは８小節までの２列シートでばかりチェックしてたからなかなか気付けなかったyo　ただ、文字数のカウントの仕方がセオリーどおりに記述してるはずなのにおかしくて、なぜか１増やすと正しく動く不思議w（苦笑）これもJavaScriptの謎の一つかな。まあ、正しく動く方を採用するのみだne

最近多いバグ。理屈どおりにMIDI NOTE OFFを実行してるはずなのに、なぜかジャンプさせた時に消えずに鳴り続ける音がw（大苦笑）　これには実に複雑な様々な要因が絡んでいるyo　主として、値が「NaN」や「Undefined」になってるときに、条件をすり抜けて悪さしてることが多いne　そこらあたりもJavaScriptの多次元配列の扱いにまだ馴れていないことが原因だろうne　でも、かなり整理をしたので、v3.1では謎の鳴り続けはほぼ撲滅できた感じがしそうだyo　配列は便利だけど細かい仕様で謎が多いyo

あとは速度的な問題だne　オフラインで動かしてても時によっては動作がよれることがある。この方式での処理速度の限界に確実に近づいてると思うyo　ピアノをOFFにしても、そもそもスクリプト自体が長大になってきてるので、必ずしも解決にならないケースも出てくるだろうne　機能をしぼった「高速動作モード」をつくるというのも一つの案かな。あと、リアルタイム実行させるのではなく、MIDIファイルを書き出すという方式も考えられるだろうne　ただ、それだとあまり面白みがなくなるよne　スカスカの状態からループ再生したまま音符を追加していき、じわじわと完成させていく手軽さと面白さが魅力なのにw　まあ、最終的に書き出し可能にするというのは研究する価値がありそうだne　ただ、それにはまだあまり手をつけていないMIDIファイル読み書きの膨大な解析処理をやらないといけないので、またまったく別の大作を１個つくるくらいの手順が必要になると思うので、それだけで約１カ月は要するだろうne　まあ、Zkun Beatはもうすぐ骨組み的には完成するので、そっちの基礎研究をやりながら残りの肉付けをゆっくりやればいいかも。とにかく、骨組みを完成させるまでは一気にやらないと時間がたつと色んなことを忘れちゃうからne　v3.1はもうすぐ完成するyo　ループ機構やピアノやベースの設定も保存対応させてるので、再現性がぐっと高まってるyo　さらにメニューもバラバラに作ったものが集合してるという感じだったけど、レギュラーメニューにもっと集約させることで、１つのソフトウェアとして見渡しやすい感じにしてるyo　もうちょっと調整してからリリースするyo（技術者笑）

[0回]