zkunがいろんなことを横書きするブログのようですw(含み笑)
さらに廃止したオプションがある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 たとえば、第1〜4小節はピアノがアルペジオ、ベースはオート、ドラムはOFFで、第5小節以降はピアノがコード、ベースはオリジナル、ドラムがパターンAとかいうようにw なかなか細かな指定ができるようになってるだろ?(ドヤ顔笑) もちろんそんな細かな指定はいっさいなしで、曲全体のデフォルトでいいyoというおまかせ設定でも動くので、細かい人でも大ざっぱな人でも使えるようになっているのさw(頭いい笑)
あと新しい工夫があるyo これまでクッキーは4KBまでしか保存できないので、曲ファイルを保存するには容量不足で、使い道がちょっと宙に浮いてたんだよne(苦笑) 次世代ソフトではドラムパターン16種類を別途定義するようになっているので、こいつの保存・読み込み専用に活用することにしたyo つまり、クッキーメニューを開いてリストから選ぶだけで、自分で登録しておいたドラムパターンセット(16種類内包)をどれでも瞬時にロードして使えるようになるというわけ。よく使うパターンを詰め合わせたセットをいくつか登録しておけば、もう曲をかえてもその都度グリッドでいちいち打ち込む必要はなくなるというわけだyo ボクの漢字変換技術により、どんなに複雑な手数のドラムパターンが16種類であっても、クッキーサイズにおさまることが実証済みなので出来る優れ技というわけだyo
あとは、ABCのループを動かす部分と、悲願の3拍子動作の部分がまだ未調整なので、もうしばらくかかりそうだけど、なかなか凄いものが出来上がりつつあるyo(技術的笑)
3拍子については「Beats」というセレクタをつくり、こいつを4から3に替えて「MAKE」ボタンを押すと、スコアシートから各小節の4拍目のチェックボックス4つが消えて、3×4=12個のチェックボックスになるところまでは既に完成してるyo 無くしたのではなく、非表示にしてるだけなんだけどne(苦笑) あわせて、これまで16クロック単位で次小節へ移動していた部分を12クロック単位に書き換えていけばいいだけなので、まあ原理的にそう難しいことではないはずなんだよne 4拍子、3拍子、2拍子の混在も可能な仕様にする予定なので、管理の仕組みは複雑になりそうだけどw(大苦笑)
そうすることで、各種設定を連続的に行う時に6〜10の連続処理で記述できちゃうので非常に簡潔になるyo さらには、ミキサー表からMIDIチャンネル指定のセレクタの列を除去できたので、上段の横幅をさらにコンパクトにすることができたyo そのほか左端のスライダーの幅を少し縮めたので、トラック部分の横幅も少々減らしたyo 全体横幅が1400以上あるから、少しでもコンパクトにする努力もしてるというわけだyo(苦笑)
さて、結構合体作業も進んできて、今は各小節ごとに個別に指定したドラムパターン、ベースモード、ピアノモードを認識して、小節ごとに違う演奏方式をとって動くようにできてるyo たとえば、第1〜4小節はピアノがアルペジオ、ベースはオート、ドラムはOFFで、第5小節以降はピアノがコード、ベースはオリジナル、ドラムがパターンAとかいうようにw なかなか細かな指定ができるようになってるだろ?(ドヤ顔笑) もちろんそんな細かな指定はいっさいなしで、曲全体のデフォルトでいいyoというおまかせ設定でも動くので、細かい人でも大ざっぱな人でも使えるようになっているのさw(頭いい笑)
あと新しい工夫があるyo これまでクッキーは4KBまでしか保存できないので、曲ファイルを保存するには容量不足で、使い道がちょっと宙に浮いてたんだよne(苦笑) 次世代ソフトではドラムパターン16種類を別途定義するようになっているので、こいつの保存・読み込み専用に活用することにしたyo つまり、クッキーメニューを開いてリストから選ぶだけで、自分で登録しておいたドラムパターンセット(16種類内包)をどれでも瞬時にロードして使えるようになるというわけ。よく使うパターンを詰め合わせたセットをいくつか登録しておけば、もう曲をかえてもその都度グリッドでいちいち打ち込む必要はなくなるというわけだyo ボクの漢字変換技術により、どんなに複雑な手数のドラムパターンが16種類であっても、クッキーサイズにおさまることが実証済みなので出来る優れ技というわけだyo
あとは、ABCのループを動かす部分と、悲願の3拍子動作の部分がまだ未調整なので、もうしばらくかかりそうだけど、なかなか凄いものが出来上がりつつあるyo(技術的笑)
3拍子については「Beats」というセレクタをつくり、こいつを4から3に替えて「MAKE」ボタンを押すと、スコアシートから各小節の4拍目のチェックボックス4つが消えて、3×4=12個のチェックボックスになるところまでは既に完成してるyo 無くしたのではなく、非表示にしてるだけなんだけどne(苦笑) あわせて、これまで16クロック単位で次小節へ移動していた部分を12クロック単位に書き換えていけばいいだけなので、まあ原理的にそう難しいことではないはずなんだよne 4拍子、3拍子、2拍子の混在も可能な仕様にする予定なので、管理の仕組みは複雑になりそうだけどw(大苦笑)
PR
新しい配列同士、関数同士をつなぎ合わせて、とりあえずドラム、ベース、ピアノの各パートが動き始めたyo トンネルが細い穴で貫通したようなものだne これまでに積み上げてきた細かな調整部分の多くが作り直しになるので、完全に機能を網羅するには少々時間がかかりそうだけど、動きは軽いし、スクリプトは簡潔だし、これは間違いないと感じてるyo
あわせて、「COPY」メニューの役割が中途半端になるので廃止することにするyo えっ?あんなにコピーメニューを充実させていたのに?と思うかもしれないne(含み笑) それは、ここまでのスコアシートがドラムトラック中心で、それをまとめて変更するにはコピーメニューが不可欠だったという事情があるyo ところが次世代ソフトでは、セレクタの1つで「A」か「A2」か「B」かなどを選ぶだけで、ドラムトラックの内容をころっと入れ替えることができちゃうyo そうなってくると、小節全体のコピーという操作はベースパートやコード指定などもあわせて変わっちゃうことになるので、かえって面倒な感じになってきちゃうということだyo
今後は、ベースパートのみを操作できる「BASS EDITOR」、ドラムパートの一括アサインができる「DRUM MENU」、コード指定を補助する「CHORD MENU」の3つを利用して各小節のデータを一括操作するという感じになるyo(合理的笑)
なんだかんだで結構完成度を上げていくのに時間がかかりそうなので、あと1週間くらいかかりそうかなw 10月いっぱいでプログラムはいったん手を置きたいので頑張って完成させるかw(人生色々笑)
あわせて、「COPY」メニューの役割が中途半端になるので廃止することにするyo えっ?あんなにコピーメニューを充実させていたのに?と思うかもしれないne(含み笑) それは、ここまでのスコアシートがドラムトラック中心で、それをまとめて変更するにはコピーメニューが不可欠だったという事情があるyo ところが次世代ソフトでは、セレクタの1つで「A」か「A2」か「B」かなどを選ぶだけで、ドラムトラックの内容をころっと入れ替えることができちゃうyo そうなってくると、小節全体のコピーという操作はベースパートやコード指定などもあわせて変わっちゃうことになるので、かえって面倒な感じになってきちゃうということだyo
今後は、ベースパートのみを操作できる「BASS EDITOR」、ドラムパートの一括アサインができる「DRUM MENU」、コード指定を補助する「CHORD MENU」の3つを利用して各小節のデータを一括操作するという感じになるyo(合理的笑)
なんだかんだで結構完成度を上げていくのに時間がかかりそうなので、あと1週間くらいかかりそうかなw 10月いっぱいでプログラムはいったん手を置きたいので頑張って完成させるかw(人生色々笑)
画面仕様はほぼ固まり、今は具体的に配列とリンクさせる作業にかかっているyo
考えた結果、zj, pj, dj という3つの配列を骨組みにして次世代ソフトを設計することにした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(理想の上司笑)
考えた結果、zj, pj, dj という3つの配列を骨組みにして次世代ソフトを設計することにした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(理想の上司笑)
ボクもこれまで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(失笑)
まあ、対応してないブラウザの場合は普通にテキストボックスが表示されてデフォルトの数値が入って表示されるみたいだから使えないことはないみたいだne ただし、そこへの変更はすべてキー入力で数値の手打ちになるみたいだけどw(苦笑)
まあ思うんだけど、無料なんだからChrome, Safari, OperaのどれかをDLすれば済む話だしne そもそもSafari以外での動作は保証してないしw(微笑)
というわけで、次世代ソフトではnumber inputをバシバシ使っていくことにするyo(大胆笑)
ところで、ぶっちゃけどのブラウザが機能的に一番先を行ってるんだろう? Chromeかな? ボクがSafariを使ってるわけは、Macのデフォルトブラウザだからマカーなら誰でも使えるというのもあるし、昔からいろいろ作ってきたものがすべてSafariで見たときを基準にしてきたから、今さらブラウザを替えると微妙に余白とか文字とかが変わってしまって、見てて気持ち悪いんだよne だから無理にブラウザを替える理由がボクには何もないというわけだyo(妥当笑) 逆にChromeにしたら何かいいことあるの? グーグルの回し者以外の人教えてw(失笑)
基本的に上段のメニューはそのまま流用w ただし、ベース音に基づいてピアノコードを生成は廃止にしようと思うyo これはまだコード打ち込み機能がないときに無理矢理ピアノを鳴らすために考案した奇策なので、パワーコード以外実用性もないし、ベースラインしだいでは調子っぱずれのコードになってしまうので、これは役目を終えたということでw(惜別笑)
下段のスコアシート部分が大きく変わるyo 1小節1<form>にするので、関数表記がめちゃくちゃ楽になるyo コード欄、クロック部、ベース表示部分はだいたい同じレイアウト。ベースの表示枠を左右いっぱいまで広げて見やすくする程度w そこから下がこれまではドラムの各インストトラックだったけど、かわりに様々なセレクタをつけて、小節ごとに指定できるようにするyo これらをまた例によって何段階かの折りたたみ表示ができるようにして、重要なものほど上に、枝葉の設定ほど下に配置するyo
じゃあ、ドラムのグリッド入力はどうなるのかというと、そうやってシンプルに構成された楽曲の小節が何段か並んで終了したあとに、さらに下方にドラムエディター画面としてとりあえず4×3段=12小節分を用意するyo そこではこれまでどおりにイエローセレクタとかを使ってグリッド入力ができるyo 特徴は、それぞれの小節が「A」とか「A2」とかのドラムパターンとして定義されるので、その記号をスコアシートのほうでセレクトすれば、それだけで曲中の小節にアサインされるという方式だyo デフォルトで「A-A-A-A2」みたいなパターンのくり返しを定義しておけば、エディター画面でわずか2小節分打ち込むだけで曲全体の簡易ドラムトラックが出来上がっちゃうというわけだyo なかなかの省力化だと思わないか?(微笑)
とりあえず中身の動作は無視して、「MAKE」ボタンで最初にバシッとシートを描き上げる部分だけ作ってみてるところだyo デザインさえこれだというのに決まれば、あとは自動的に出来上がっていくところがあるからne 左右の寸法もピタリ合わせたし、小さかった文字を少し大きくして見やすくしたりと、なかなか改善効果が現れていて楽しいyo あとはどのような新配列を定義するのがベストなのか、仕様を詰めていくのがキモだne それぞれのモードにおいて作らなくちゃいけない配列とかが既にいったん出そろっているので、それらの問題点や無駄な部分などを考えつつ、どうやったらできるだけSMFにコンバートしやすく、かつそれでいてリアルタイム操作性も残した配列と再生エンジンにするかだne これはなかなか面白い開発になりそうだyo(期待笑)
下段のスコアシート部分が大きく変わるyo 1小節1<form>にするので、関数表記がめちゃくちゃ楽になるyo コード欄、クロック部、ベース表示部分はだいたい同じレイアウト。ベースの表示枠を左右いっぱいまで広げて見やすくする程度w そこから下がこれまではドラムの各インストトラックだったけど、かわりに様々なセレクタをつけて、小節ごとに指定できるようにするyo これらをまた例によって何段階かの折りたたみ表示ができるようにして、重要なものほど上に、枝葉の設定ほど下に配置するyo
じゃあ、ドラムのグリッド入力はどうなるのかというと、そうやってシンプルに構成された楽曲の小節が何段か並んで終了したあとに、さらに下方にドラムエディター画面としてとりあえず4×3段=12小節分を用意するyo そこではこれまでどおりにイエローセレクタとかを使ってグリッド入力ができるyo 特徴は、それぞれの小節が「A」とか「A2」とかのドラムパターンとして定義されるので、その記号をスコアシートのほうでセレクトすれば、それだけで曲中の小節にアサインされるという方式だyo デフォルトで「A-A-A-A2」みたいなパターンのくり返しを定義しておけば、エディター画面でわずか2小節分打ち込むだけで曲全体の簡易ドラムトラックが出来上がっちゃうというわけだyo なかなかの省力化だと思わないか?(微笑)
とりあえず中身の動作は無視して、「MAKE」ボタンで最初にバシッとシートを描き上げる部分だけ作ってみてるところだyo デザインさえこれだというのに決まれば、あとは自動的に出来上がっていくところがあるからne 左右の寸法もピタリ合わせたし、小さかった文字を少し大きくして見やすくしたりと、なかなか改善効果が現れていて楽しいyo あとはどのような新配列を定義するのがベストなのか、仕様を詰めていくのがキモだne それぞれのモードにおいて作らなくちゃいけない配列とかが既にいったん出そろっているので、それらの問題点や無駄な部分などを考えつつ、どうやったらできるだけSMFにコンバートしやすく、かつそれでいてリアルタイム操作性も残した配列と再生エンジンにするかだne これはなかなか面白い開発になりそうだyo(期待笑)
今ポッカリと欠落してる部分について考えたyo それは16ビート系完成後に移植する予定としていた3拍子6拍子系。それから、現行のドラムグリッド方式では実現が困難な途中で3連符や6連符を使用する変化。あとは曲入力してて思ったのが、途中で2拍や3拍の短い小節を挿入する曲進行。そして、曲途中でのテンポ変更。曲の終わりでのスロー化も含めてw
次世代ソフトの仕様を決めるにあたって、これらをどこまで対応させて、どれを切り捨てるかは悩ましいところだne ボクがめざしているのは、あくまで自宅練習の友としての「自動ジャムマシーン」なので、せいぜい伴奏としてのベースラインとピアノコードorアルペジオまでが鳴ればいいんだyo イングヴェイのように6連符で延々とソロ演奏が鳴る必要はないし、プログレのような超変拍子をあらゆる状況でも再現する必要はないyo(妥当笑)
1拍、2拍、3拍の小節をつくる機能はつくろう。パターンは4拍分のものをそれぞれの拍でぶった切るだけの対応にするw(乱暴笑) そうすることで新たなエディターとかを作る必要もなくなるので合理的だよne 6拍は、3拍を2つ並べることで6拍とみなしてね、ということでw これは確定。
曲途中のテンポ変更は、各小節にテンポ情報の数値を持たせるだけで実現可能なのでこれは採用。小節内でもしだいにゆっくりとかできないかと言われれば、できないことはないけど、指定がかなり煩雑になりそう。ただし、エンディングの最終小節限定で、いくつかの終わらせ方パターンから選ばせるだけという方式なら余計なインターフェイスを作らなくてもすむのでそういう方式にしよう。多少動作がもたっても、どうせゆっくり終わらせるだけなので大丈夫だろうw(失笑) これも確定。
問題は3連符だよne ただ、あくまで伴奏パートの話なので、四分音符1個をボーンと鳴らして、心の中で3連符を刻み、自分はギターで3連符を弾けばいいといえばいいw(脳内笑) ただ、ずーっとハットが3連符刻むパターンの曲なんかだとそうもいかないw(苦笑) では、3拍の小節が4クロックx3拍子=12クロックだから、それを3クロックx4拍子=12クロックに読み替えて、脳内3連符にしたらどうかw ドラムだけならそれで対応可能だよne スネアとかもそれに合わせて小節内パターンを打たせるよう入力しとけばいいからw 問題はベースとピアノだよne 現行ではあくまでも4クロック=1拍で扱わせているから、ドラムとビート感がずれてしまうw(苦笑) ただし、オートベースとアルペジオではずれてしまうけど、オリジナルベースならそもそも曲に合わせて打ち込めばいいんだから問題ない。ピアノもコード弾きで小節を1つの和音で伸ばすならば、内部をどう認識しようと関係無い。つまり、疑似3連符をやりたければ、モード限定ではあるけど、できることはできるということになるne これは使う側の工夫でなんとかできるわけだから、無理矢理複雑な機構を入れ込む必要はないということで確定にしようと思うyo
さらにややこしいのがあるよne 1拍目が8分音符で、2拍目が3連符、これを交互に繰り返しというような場合w(複雑な笑) これはかなりきついne 1拍目は1拍だけの小節を選んで打ち込む。テンポを仮に96とする。2拍目は3連符をつめこまないといけないので3拍の小節をテンポ3倍の288にしてアサインする。これを交互に繰り返せば、やってできないことはないw(呆れ笑) 実際にテンポ3倍なんかにしてスムーズに動くのかどうかも疑問w ただ、もしファイル書き出しして再生させるならば、実際のsmfデータはたいしたことないのでラクラク再生できるはず。web再生では苦しくてもsmfを介するなら楽勝になるというケースだろう。
それは上記のような複雑なパターンに限らず、単純に曲が長い、和音数が多い、ドラムの手数が多い、などの理由で動作が重くなってテンポが崩れることが考えられるので、曲レベルまでのデータ量を扱うようになった今となっては、再生方法をsmf書き出ししてプレーヤーで再生するというのをメインにすることを考えてもいい段階かもne
さらに言えば、「Zkun MIDI Player v1.0」というのもちょろっとだけ出してたけど、これはJazz-Pluginの機能でplayer()というインスタンス(?)を使って、smfファイルの再生をコントロールしてるサンプルをちょっといじくったものなんだyo つまり、今までは専用配列を作ってそこからギクシャク再生させていたけど、player()用の配列のフォーマットに合わせて書き込むようにすれば、プロが作った再生エンジンに再生をおまかせできちゃうことになるから、ちょっとやそっとのデータ量程度で再生がよれたりということはなくなると思うんだよne というわけで次世代ソフトはそのあたりを見越して、内部構造のさらなる見直しを行い、できることを増やして、再生能力も上げるという良いことづくめの進化を狙っていくというわけだyo(新たな野望笑)
次世代ソフトの仕様を決めるにあたって、これらをどこまで対応させて、どれを切り捨てるかは悩ましいところだne ボクがめざしているのは、あくまで自宅練習の友としての「自動ジャムマシーン」なので、せいぜい伴奏としてのベースラインとピアノコードorアルペジオまでが鳴ればいいんだyo イングヴェイのように6連符で延々とソロ演奏が鳴る必要はないし、プログレのような超変拍子をあらゆる状況でも再現する必要はないyo(妥当笑)
1拍、2拍、3拍の小節をつくる機能はつくろう。パターンは4拍分のものをそれぞれの拍でぶった切るだけの対応にするw(乱暴笑) そうすることで新たなエディターとかを作る必要もなくなるので合理的だよne 6拍は、3拍を2つ並べることで6拍とみなしてね、ということでw これは確定。
曲途中のテンポ変更は、各小節にテンポ情報の数値を持たせるだけで実現可能なのでこれは採用。小節内でもしだいにゆっくりとかできないかと言われれば、できないことはないけど、指定がかなり煩雑になりそう。ただし、エンディングの最終小節限定で、いくつかの終わらせ方パターンから選ばせるだけという方式なら余計なインターフェイスを作らなくてもすむのでそういう方式にしよう。多少動作がもたっても、どうせゆっくり終わらせるだけなので大丈夫だろうw(失笑) これも確定。
問題は3連符だよne ただ、あくまで伴奏パートの話なので、四分音符1個をボーンと鳴らして、心の中で3連符を刻み、自分はギターで3連符を弾けばいいといえばいいw(脳内笑) ただ、ずーっとハットが3連符刻むパターンの曲なんかだとそうもいかないw(苦笑) では、3拍の小節が4クロックx3拍子=12クロックだから、それを3クロックx4拍子=12クロックに読み替えて、脳内3連符にしたらどうかw ドラムだけならそれで対応可能だよne スネアとかもそれに合わせて小節内パターンを打たせるよう入力しとけばいいからw 問題はベースとピアノだよne 現行ではあくまでも4クロック=1拍で扱わせているから、ドラムとビート感がずれてしまうw(苦笑) ただし、オートベースとアルペジオではずれてしまうけど、オリジナルベースならそもそも曲に合わせて打ち込めばいいんだから問題ない。ピアノもコード弾きで小節を1つの和音で伸ばすならば、内部をどう認識しようと関係無い。つまり、疑似3連符をやりたければ、モード限定ではあるけど、できることはできるということになるne これは使う側の工夫でなんとかできるわけだから、無理矢理複雑な機構を入れ込む必要はないということで確定にしようと思うyo
さらにややこしいのがあるよne 1拍目が8分音符で、2拍目が3連符、これを交互に繰り返しというような場合w(複雑な笑) これはかなりきついne 1拍目は1拍だけの小節を選んで打ち込む。テンポを仮に96とする。2拍目は3連符をつめこまないといけないので3拍の小節をテンポ3倍の288にしてアサインする。これを交互に繰り返せば、やってできないことはないw(呆れ笑) 実際にテンポ3倍なんかにしてスムーズに動くのかどうかも疑問w ただ、もしファイル書き出しして再生させるならば、実際のsmfデータはたいしたことないのでラクラク再生できるはず。web再生では苦しくてもsmfを介するなら楽勝になるというケースだろう。
それは上記のような複雑なパターンに限らず、単純に曲が長い、和音数が多い、ドラムの手数が多い、などの理由で動作が重くなってテンポが崩れることが考えられるので、曲レベルまでのデータ量を扱うようになった今となっては、再生方法をsmf書き出ししてプレーヤーで再生するというのをメインにすることを考えてもいい段階かもne
さらに言えば、「Zkun MIDI Player v1.0」というのもちょろっとだけ出してたけど、これはJazz-Pluginの機能でplayer()というインスタンス(?)を使って、smfファイルの再生をコントロールしてるサンプルをちょっといじくったものなんだyo つまり、今までは専用配列を作ってそこからギクシャク再生させていたけど、player()用の配列のフォーマットに合わせて書き込むようにすれば、プロが作った再生エンジンに再生をおまかせできちゃうことになるから、ちょっとやそっとのデータ量程度で再生がよれたりということはなくなると思うんだよne というわけで次世代ソフトはそのあたりを見越して、内部構造のさらなる見直しを行い、できることを増やして、再生能力も上げるという良いことづくめの進化を狙っていくというわけだyo(新たな野望笑)
v3.0までに出そろった技術を、すべてのパラメータにおいて保存・読み込み対応にさせたので、画面上で作業していた環境をまったく同じ状態でロードできるようにしたyo この曲はピアノは何番目のアルペジオパターンで、オートベースはこれこれのグルーブパターンで鳴らしたのを聴いてほしい、という注文が完全に反映されるのでバッチリな完成度に仕上がったyo
さらにメニュー体系がごちゃごちゃしていたので、上段のメニュー画面をかなり大胆に改革したyo これによって今必要でないメニューは表示されない、あるいは使用不能状態になるので、今使えるコントロールがどれなのかということがわかりやすくなったyo 常にピアノモード、ベースモードにアクセスできるようになったので操作性がかなりよくなったと思うyo
曲進行タグのAs, Ae, Bs, Be,Cs, Ce, Re, Endもテキストファイルに保存されるし、ループコントロールを有効にするかどうかのチェック状態や各ループの回数も保存されるので、デモソングを読み込んだ状態で指定どおりに進行させることができるようになってるyo これでもう完全に1曲をテキストファイルで記述することができるようになった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(苦笑)
さらにメニュー体系がごちゃごちゃしていたので、上段のメニュー画面をかなり大胆に改革したyo これによって今必要でないメニューは表示されない、あるいは使用不能状態になるので、今使えるコントロールがどれなのかということがわかりやすくなったyo 常にピアノモード、ベースモードにアクセスできるようになったので操作性がかなりよくなったと思うyo
曲進行タグのAs, Ae, Bs, Be,Cs, Ce, Re, Endもテキストファイルに保存されるし、ループコントロールを有効にするかどうかのチェック状態や各ループの回数も保存されるので、デモソングを読み込んだ状態で指定どおりに進行させることができるようになってるyo これでもう完全に1曲をテキストファイルで記述することができるようになった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(苦笑)
最近新しい機能が増えてるから、バグの種類も新しくなってきてるyo(大苦笑)
先日直したバグ。圧縮したファイルを自動解凍するときに、コピー元の小節が1ケタ番号なら正しく動いてたけど、#18小節とか2ケタになるとおかしくなってた件。これは8小節までの2列シートでばかりチェックしてたからなかなか気付けなかったyo ただ、文字数のカウントの仕方がセオリーどおりに記述してるはずなのにおかしくて、なぜか1増やすと正しく動く不思議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ファイル読み書きの膨大な解析処理をやらないといけないので、またまったく別の大作を1個つくるくらいの手順が必要になると思うので、それだけで約1カ月は要するだろうne まあ、Zkun Beatはもうすぐ骨組み的には完成するので、そっちの基礎研究をやりながら残りの肉付けをゆっくりやればいいかも。とにかく、骨組みを完成させるまでは一気にやらないと時間がたつと色んなことを忘れちゃうからne v3.1はもうすぐ完成するyo ループ機構やピアノやベースの設定も保存対応させてるので、再現性がぐっと高まってるyo さらにメニューもバラバラに作ったものが集合してるという感じだったけど、レギュラーメニューにもっと集約させることで、1つのソフトウェアとして見渡しやすい感じにしてるyo もうちょっと調整してからリリースするyo(技術者笑)
先日直したバグ。圧縮したファイルを自動解凍するときに、コピー元の小節が1ケタ番号なら正しく動いてたけど、#18小節とか2ケタになるとおかしくなってた件。これは8小節までの2列シートでばかりチェックしてたからなかなか気付けなかったyo ただ、文字数のカウントの仕方がセオリーどおりに記述してるはずなのにおかしくて、なぜか1増やすと正しく動く不思議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ファイル読み書きの膨大な解析処理をやらないといけないので、またまったく別の大作を1個つくるくらいの手順が必要になると思うので、それだけで約1カ月は要するだろうne まあ、Zkun Beatはもうすぐ骨組み的には完成するので、そっちの基礎研究をやりながら残りの肉付けをゆっくりやればいいかも。とにかく、骨組みを完成させるまでは一気にやらないと時間がたつと色んなことを忘れちゃうからne v3.1はもうすぐ完成するyo ループ機構やピアノやベースの設定も保存対応させてるので、再現性がぐっと高まってるyo さらにメニューもバラバラに作ったものが集合してるという感じだったけど、レギュラーメニューにもっと集約させることで、1つのソフトウェアとして見渡しやすい感じにしてるyo もうちょっと調整してからリリースするyo(技術者笑)
v3.0になって色々進化したyo まずはわかりやすいことから。
これまで一度作ったスコアシートは大きさを変えることができなかったんだけど、小節数を増やすか、ドラムインスト数を増やす場合は、今あるデータをそのまま引き継いでスコアシートを大きくすることができるようになったyo やり方は「MAKE Score Sheet」を押す時に「with data hold」にチェックを入れておけばいいだけだyo これで、初めはちっこいメインリフのループから作り始めて、どんどん長くしていくということができるようになったyo(大きな進化笑)
それから「COPY MENU」に久々に新しいボタンを追加したyo 1つは「COPY#→→→」ボタンで、これは指定した小節を3つ続けて後ろにコピーする機能だyo もう1つは「COPY#-# →」ボタンで、たとえば「4小節から7小節までを、10小節(から13小節まで)の位置へコピー」というように、連続した複数小節を指定した位置へコピーできる機能だyo まとめてガバッと移動させたいときにこれを使うと便利だyo
さらに細かいネタで、タイトルバーに「#8」のように小節番号を表示してる枠があるでしょ? あそこに直接キー入力で「Re」と打ち込むと、再生してきたらその小節を再生し終わったところで曲の先頭の#1へ戻ってループ再生するyo つまり、これまで4の倍数の小節数のループしかできなかったんだけど、これを使えば9小節でも10小節でも、お好きな長さでループできるようになったyo
それと似たパターンで「End」と打ち込めば、その小節のラストで再生をピタリと終了するyo いつまでもループせずにどこかで終わりをつくりたいときにこれがあると決まるよne
というわけで、いよいよ曲進行の制御に手を出し始めたyo そして今回のメインとなる「SONG MENU」を見てほしい。まだ殺風景な画面だけど、A, B, Cの3つのループを定義して、それぞれを任意の回数繰り返しさせてから続きへ進ませるという実にわかりやすいシステムだyo とりあえず3つでスタートしているけど、複雑な曲構成だと足りなくなると思うので、ゆくゆくはもっと増やすと思うyo
ループの定義のしかたは、スコアシートで先ほどと同じように「As」「Ae」のスタートタグとエンドタグを打ち込めばいいだけ。打ち込めば「SONG MENU」のテキストボックスに自動的に小節番号が転送されてくるyo そしてセレクタで演奏回数を選べばいいだけ。「1回」だとふつうに演奏されるだけ。「2回」を選ぶと1度リピートして2度演奏されるというわけだyo まあこれも、言うなれば「曲の途中から再生」というオプションを選べるようになってたけど、あれの応用で、その位置まできたときに再生位置を変更してもろもろの設定を計算して付随させて瞬時に送り出してるというわけだyo それをやる回数をカウンターで数えているというわけさw いったん曲の最終部分までたどりつけばカウンターはリセットされ、また曲の頭から再生して、新たに指定回数リピートするという仕組みだyo
まだまだ試行段階だけど、As, Aeなどのタグもテキストファイルにそのまま記録させ、SONG MENUでの設定内容もheaderなどに追加保存するようにすれば、曲としての再生方法が完全にパッケージできるので、その方向で考えてるyo そうなれば、ピアノやベースの演奏モード指定やHitsやアルペジオの選択状況なんかもすべてパッケージしたほうがいいので、ヘッダー部への書き込み方式を少々拡張して対応したほうがいいかもne まだ細かな点で詰まってないところもあるけれど、曲進行制御がとりあえず動くところまで来れたので、開発の大きな柱は立て切ったという感じがするyo(感慨笑) あとはいかに枝葉を充実させて、至れり尽くせりの便利機能で埋め尽くしていくかだne
ところで、みんなのパソコンではマシンパワー的にどうなってるの? ボクのiMac 2.66GHzではそろそろネット状況などによってもたついたりするケースも出てきたyo ちょっと和音数を増やし過ぎてるかもしれないne(苦笑) 機能的にダウンさせるのは勿体ないので、意図的に音を間引くモードをつくったり、すべてをリアルタイム操作できなくてもかまわないので、動作の軽さを優先させてfunctionを小分けして動かしたほうがいいかもしれないne 今後は速度を稼ぐ為のワザも追究していこうと思うyo(技術的笑)
これまで一度作ったスコアシートは大きさを変えることができなかったんだけど、小節数を増やすか、ドラムインスト数を増やす場合は、今あるデータをそのまま引き継いでスコアシートを大きくすることができるようになったyo やり方は「MAKE Score Sheet」を押す時に「with data hold」にチェックを入れておけばいいだけだyo これで、初めはちっこいメインリフのループから作り始めて、どんどん長くしていくということができるようになったyo(大きな進化笑)
それから「COPY MENU」に久々に新しいボタンを追加したyo 1つは「COPY#→→→」ボタンで、これは指定した小節を3つ続けて後ろにコピーする機能だyo もう1つは「COPY#-# →」ボタンで、たとえば「4小節から7小節までを、10小節(から13小節まで)の位置へコピー」というように、連続した複数小節を指定した位置へコピーできる機能だyo まとめてガバッと移動させたいときにこれを使うと便利だyo
さらに細かいネタで、タイトルバーに「#8」のように小節番号を表示してる枠があるでしょ? あそこに直接キー入力で「Re」と打ち込むと、再生してきたらその小節を再生し終わったところで曲の先頭の#1へ戻ってループ再生するyo つまり、これまで4の倍数の小節数のループしかできなかったんだけど、これを使えば9小節でも10小節でも、お好きな長さでループできるようになったyo
それと似たパターンで「End」と打ち込めば、その小節のラストで再生をピタリと終了するyo いつまでもループせずにどこかで終わりをつくりたいときにこれがあると決まるよne
というわけで、いよいよ曲進行の制御に手を出し始めたyo そして今回のメインとなる「SONG MENU」を見てほしい。まだ殺風景な画面だけど、A, B, Cの3つのループを定義して、それぞれを任意の回数繰り返しさせてから続きへ進ませるという実にわかりやすいシステムだyo とりあえず3つでスタートしているけど、複雑な曲構成だと足りなくなると思うので、ゆくゆくはもっと増やすと思うyo
ループの定義のしかたは、スコアシートで先ほどと同じように「As」「Ae」のスタートタグとエンドタグを打ち込めばいいだけ。打ち込めば「SONG MENU」のテキストボックスに自動的に小節番号が転送されてくるyo そしてセレクタで演奏回数を選べばいいだけ。「1回」だとふつうに演奏されるだけ。「2回」を選ぶと1度リピートして2度演奏されるというわけだyo まあこれも、言うなれば「曲の途中から再生」というオプションを選べるようになってたけど、あれの応用で、その位置まできたときに再生位置を変更してもろもろの設定を計算して付随させて瞬時に送り出してるというわけだyo それをやる回数をカウンターで数えているというわけさw いったん曲の最終部分までたどりつけばカウンターはリセットされ、また曲の頭から再生して、新たに指定回数リピートするという仕組みだyo
まだまだ試行段階だけど、As, Aeなどのタグもテキストファイルにそのまま記録させ、SONG MENUでの設定内容もheaderなどに追加保存するようにすれば、曲としての再生方法が完全にパッケージできるので、その方向で考えてるyo そうなれば、ピアノやベースの演奏モード指定やHitsやアルペジオの選択状況なんかもすべてパッケージしたほうがいいので、ヘッダー部への書き込み方式を少々拡張して対応したほうがいいかもne まだ細かな点で詰まってないところもあるけれど、曲進行制御がとりあえず動くところまで来れたので、開発の大きな柱は立て切ったという感じがするyo(感慨笑) あとはいかに枝葉を充実させて、至れり尽くせりの便利機能で埋め尽くしていくかだne
ところで、みんなのパソコンではマシンパワー的にどうなってるの? ボクのiMac 2.66GHzではそろそろネット状況などによってもたついたりするケースも出てきたyo ちょっと和音数を増やし過ぎてるかもしれないne(苦笑) 機能的にダウンさせるのは勿体ないので、意図的に音を間引くモードをつくったり、すべてをリアルタイム操作できなくてもかまわないので、動作の軽さを優先させてfunctionを小分けして動かしたほうがいいかもしれないne 今後は速度を稼ぐ為のワザも追究していこうと思うyo(技術的笑)
言ってたとおり結構簡単に改造できたyo タイトルバーへのコード情報入力の際に「C7/G#」のように分数表記をすることで、ルート音を変更することができるようになったyo 必ず「/」に続けてキーとあれば補助記号を書くようにしてne ただし、分母は単音指定だけで、コードonコードはできないyo(さすがに笑) これはピアノコード、ピアノアルペジオ、ベース自動生成のいずれでも実行可能だyo
さらにベース自動生成にも改良を加えたyo STOP/STARTを押すたびにコロコロパターンが変わるというのも面白いといえば面白いんだけど、狙ったグルーヴを得にくいという難点もあるよne そこでメインとなる「Hits 'A'」を指定するセレクタを独立させたyo こいつで基本となるヒットパターンを指定してやれば、生成したいベース演奏のイメージをより正確に反映させることができるようになったyo しかも、Hits 'A'のセレクタは演奏中にリアルタイムで変更がきくようになったので、これも利便性アップだne 残りの使用パターンは「Other Hits」で複数指定するけど、こちらでもし1つだけ選択しておけば、それが必ずBのパターンに固定で入ってくれるので、A,Bに具体的にこれを入れて鳴らしたい!という指定がやりやすいように進化したというわけだyo(納得笑)
あと細かいことなんだけど、ベースモードを演奏中に「自動生成」→「オリジナルフレーズ」に戻したときに、自動生成時に短い音符用に大量に作られた「MIDI NOTE OFF予約」が残ってしまうことにより、オリジナルフレーズのベースの長音が短くブツ切り再生されてしまう問題があったんだけど、そいつを解消したyo まあ、演奏をいったんSTOP/PLAYすれば直ってたんだけど、止めずとも直す方法がわかったのでそれを施しておいたyo(迅速笑)
それから動作検証用にこれまで作成したデモソングを簡単にロードできるように「COOKIE/DEMO」のメニュー画面に新たに「DEMO SONGS」というセレクタをつくったyo タイトルをクリックすると自動的にデモソングをロードするyo ロードと言っても内部にテキストデータを持たせたのでそれを読み込んでるだけだけどne 以前のバージョンでコード進行情報がなかったものにも、分数コードを含むコード情報を付加しておいたから、またちょっと違う鳴り方をすると思うyo ソングによって、ピアノコードがいいもの、アルペジオがいいもの、オリジナルベースフレーズがいいもの、自動生成ベースがいいものなど向き不向きがあると思うので、メニューで切り替えながら試聴してみると面白いyo
いやあ、けっこう完成してきたne あとは、ドラムのオカズ生成機構と、曲進行を管理する機構、そしてコード進行自体を手軽につくってくれちゃう機能、以前にちらっと話してた「日本語文章から伴奏パターンを作っちゃう機能」、それに付随してもしかしたら搭載する「カタカナ変換機能」「アルファベット変換機能」あたりかな。ピアノやベースの自動演奏に関する再生時環境指定も簡単な符号にしてデータに持たせるようにすれば、意図した環境で再生されるようにすることもできるよne それ自体はヘッダに持たせてもできるし、各小節に持たせたら曲の進行にともなって設定を変化させることもできるよne そうなると曲進行管理を作るときに一緒に考えたほうがベターかなw(技術者笑) とにかく、自分が実際に使うのに便利だと思う方向で進化させていくyo(野望笑) やるなら今でしょw(林先生副業笑)
さらにベース自動生成にも改良を加えたyo STOP/STARTを押すたびにコロコロパターンが変わるというのも面白いといえば面白いんだけど、狙ったグルーヴを得にくいという難点もあるよne そこでメインとなる「Hits 'A'」を指定するセレクタを独立させたyo こいつで基本となるヒットパターンを指定してやれば、生成したいベース演奏のイメージをより正確に反映させることができるようになったyo しかも、Hits 'A'のセレクタは演奏中にリアルタイムで変更がきくようになったので、これも利便性アップだne 残りの使用パターンは「Other Hits」で複数指定するけど、こちらでもし1つだけ選択しておけば、それが必ずBのパターンに固定で入ってくれるので、A,Bに具体的にこれを入れて鳴らしたい!という指定がやりやすいように進化したというわけだyo(納得笑)
あと細かいことなんだけど、ベースモードを演奏中に「自動生成」→「オリジナルフレーズ」に戻したときに、自動生成時に短い音符用に大量に作られた「MIDI NOTE OFF予約」が残ってしまうことにより、オリジナルフレーズのベースの長音が短くブツ切り再生されてしまう問題があったんだけど、そいつを解消したyo まあ、演奏をいったんSTOP/PLAYすれば直ってたんだけど、止めずとも直す方法がわかったのでそれを施しておいたyo(迅速笑)
それから動作検証用にこれまで作成したデモソングを簡単にロードできるように「COOKIE/DEMO」のメニュー画面に新たに「DEMO SONGS」というセレクタをつくったyo タイトルをクリックすると自動的にデモソングをロードするyo ロードと言っても内部にテキストデータを持たせたのでそれを読み込んでるだけだけどne 以前のバージョンでコード進行情報がなかったものにも、分数コードを含むコード情報を付加しておいたから、またちょっと違う鳴り方をすると思うyo ソングによって、ピアノコードがいいもの、アルペジオがいいもの、オリジナルベースフレーズがいいもの、自動生成ベースがいいものなど向き不向きがあると思うので、メニューで切り替えながら試聴してみると面白いyo
いやあ、けっこう完成してきたne あとは、ドラムのオカズ生成機構と、曲進行を管理する機構、そしてコード進行自体を手軽につくってくれちゃう機能、以前にちらっと話してた「日本語文章から伴奏パターンを作っちゃう機能」、それに付随してもしかしたら搭載する「カタカナ変換機能」「アルファベット変換機能」あたりかな。ピアノやベースの自動演奏に関する再生時環境指定も簡単な符号にしてデータに持たせるようにすれば、意図した環境で再生されるようにすることもできるよne それ自体はヘッダに持たせてもできるし、各小節に持たせたら曲の進行にともなって設定を変化させることもできるよne そうなると曲進行管理を作るときに一緒に考えたほうがベターかなw(技術者笑) とにかく、自分が実際に使うのに便利だと思う方向で進化させていくyo(野望笑) やるなら今でしょw(林先生副業笑)