zkunがいろんなことを横書きするブログのようですw(含み笑)
ていうか、予測どおり外的な要因で疲労がたまりまくっていて、じっくりまとまった時間をプログラミングにあてる余裕がないんだよne(苦笑) zkunの場合、アクシデントまできちんと予測済みなところが凄過ぎるんだけどne まあ、どっちみち無理に完成を急いだところで完成品をのんびり使ってる時間もとれなさそうなので、こういう場合は急いでストレスをためる必要性はないようですw(妥当笑)
あとは細かい部分を足し込むだけなので、zkunの開発者魂としては、すでに次のプロジェクトに重心が移っているようですw(せっかちな笑) 1月から着手しようと考えているのは、リアルタイムセッションアプリのようですw 昔から、そんなことができたら凄いな、と思いつつ、その実現方法がまったくわからなかったものの1つのようですw ただ、今ならなんとなくゴールまでの道筋が見えているようですw どの程度のものになるか、反応速度は大丈夫なのか、という疑問はあるとしてもですw(苦笑)
MIDIキーボードからの入力に反応させるのがオーソドックスなパターンでしょう。ただ、ボクは鍵盤奏者ではないので、それだけだと楽しくないようですw なので、GKピックアップでギター演奏を拾って、GRからMIDI信号を吐き出させて、それをUSB-MIDIインターフェイスで変換して、パソコンのUSBに送り込み、それをJazz-Pluginで受信させて、何弦でどの音高を弾いたかを認識させますw ここまでは、通常のDAWなんかに取り込むときも同じことなんですが、問題はMIDIデータ化するときの精度の悪さですw もしかしたらそこを改善させるために、最新のGRなりなんなりのRoland製品を調査して買い替えることがあるかもしれませんne(出費笑)
そこから先がキモの部分。今度はリアルタイム処理なので、SMFを作ってそれを再生実行するというかたちではなく、Zkun Beatの時代のようなクロック計算してWaitさせてから、次のリアルタイム発音命令を実行させる方式でいくと思うyo ドラムスはある程度事前に設定したビートを鳴らすのが基本で、フィルインの入れ具合や、パターンの変更をどのように実行するかに関して、ギター演奏内容からなんらかの影響を受けさせるという処理になると思うne それにしたって、あまり奇妙なところでチェンジするわけにもいかないから、ある程度4小節サイクルで回していくという大枠の中での自由度にすると思うne つまり、ドラムス部分に関しては技術的な難しさはほとんどなく、ほぼ、どういうルールにするかという定義づくりの問題になるne
ベースはそうはいかないyo ギターから送られてきたノート情報を拍単位、小節単位でプールさせて、どのコードである可能性があるかを随時判定させて、弾いても大丈夫な音の集合を用意させるyo 母集合さえ決まれば、あとはzkun伝統のオートベース技術でベースラインをアドリブで生成させることが可能なので、そこから先は技術的な問題はまったくないyo つまり、ベースに関しても、単位時間あたりに発音された音高の集合から、どのコードを指定するかというルールづくりが最大のキモになるne そこまでできたなら、それにピアノ伴奏を付加して、コードやアルペジオを鳴らすのはすでにある技術で可能なので朝飯前だよne いずれのパートも、ロジックを考えることはできたとしても、それを具体的に演奏コマンドとして吐き出させる技術も知識もないという人がほとんどじゃないかなw(含み笑) zkunの場合、これまでの積み重ねがあるので、どのようにすれば既存のルーチンを転用して簡単に演奏させられるかがわかっているので、ものすごいアドバンテージだよne 開発を続けているということは、このように絶大なメリットがあるということだne あとに続く中高生のみんなも是非zkunを参考にすることだne 将来、中高生プログラムコンテスト優勝者のコメントで「zkunさんを目標にがんばってきました!」というコメントが聞けるのを楽しみにしてるyo(妄想笑)
まあ、それはいいとして、技術的にはほとんどBeat v2.8までで使ったもので足りる。単位時間あたりのノートを蓄積するのだって、クロックで区切って、その間に受信したメッセージからノートオンの場合だけ、音高の数値を配列変数の要素番号に順に放り込んでいき、時間を締め切ったら、次の子配列に移る、というだけの処理だよne その後をどう処理するかだけだne
単純に来た音高をその時間中は全部使っていいとするだけなら、アホみたいに簡単なロジックになるne まあ、試作段階ではそのパターンのやつも作ってみようw ただ、音楽ルールはそこまで単純ではないよne(苦笑) 音楽の授業なんかでも少しかじったルールがあると思うけど、それらもあくまで、あらかじめ調性記号がわかっている場合に、その小節では何が使えるかというような説明じゃなかったかな? 事前になにもわかってない状態でいきなり「レミファソラー#ドーー」などと音の羅列が来たときに、はたしてどれをコード構成音、どれを経過音として処理するかは、さまざまな解釈が可能で、前後関係があってはじめてどれが正解になるかが決まるものだよne それをリアルタイム処理でどのようにつじつまを合わせて自然な感じで聴けるようにするかがポイントだろうne
おそらく、より単純な調性、より単純なコードの優先順位を高くすることで、ふつうの素人演奏家が送ってくるノートデータに対して、適切なコードが割りふれる可能性が高くなるような気がするよne(素人の限界を逆手にとる笑) 真っ先にヒットするものがあれば、それに即決させていくという方法で記述していけば、内容もいい線いくし、処理も速いだろうne(微笑) 基本的にそういう感じで構想していってみようかw(方針は決まった笑)
それにしても、なかなか凄い動作になると思うyo いままでありそうでなかったジャンルだからne ポータブルキーボードなんかで、半自動で伴奏が追従してくるなんていうのはあったと思うけど、ほとんどお遊びでしかなかったからne しかも、ギターを弾いて、それについてこさせるなんていうのは、これまでに見たことも聞いたこともないので、これが実際にちゃんと動いたときの感動はなかなか大きいものがあるんじゃないかなと思うne
処理自体はリアルタイム発音になるけど、受信したデータをレコーディングする技術もあるし、伴奏側で何をしたかもすべてログに残せるので、やろうと思えば、今やったセッションをSMFで吐き出して、というリクエストに応えられないこともないだろうne 多少手間ではあるけど。最終的にはその機能もつけるという前提でシステム設計しようじゃないかw(納得笑) 1月からの新プロジェクトはなかなか楽しみなものになりそうですw(含み笑)
あとは細かい部分を足し込むだけなので、zkunの開発者魂としては、すでに次のプロジェクトに重心が移っているようですw(せっかちな笑) 1月から着手しようと考えているのは、リアルタイムセッションアプリのようですw 昔から、そんなことができたら凄いな、と思いつつ、その実現方法がまったくわからなかったものの1つのようですw ただ、今ならなんとなくゴールまでの道筋が見えているようですw どの程度のものになるか、反応速度は大丈夫なのか、という疑問はあるとしてもですw(苦笑)
MIDIキーボードからの入力に反応させるのがオーソドックスなパターンでしょう。ただ、ボクは鍵盤奏者ではないので、それだけだと楽しくないようですw なので、GKピックアップでギター演奏を拾って、GRからMIDI信号を吐き出させて、それをUSB-MIDIインターフェイスで変換して、パソコンのUSBに送り込み、それをJazz-Pluginで受信させて、何弦でどの音高を弾いたかを認識させますw ここまでは、通常のDAWなんかに取り込むときも同じことなんですが、問題はMIDIデータ化するときの精度の悪さですw もしかしたらそこを改善させるために、最新のGRなりなんなりのRoland製品を調査して買い替えることがあるかもしれませんne(出費笑)
そこから先がキモの部分。今度はリアルタイム処理なので、SMFを作ってそれを再生実行するというかたちではなく、Zkun Beatの時代のようなクロック計算してWaitさせてから、次のリアルタイム発音命令を実行させる方式でいくと思うyo ドラムスはある程度事前に設定したビートを鳴らすのが基本で、フィルインの入れ具合や、パターンの変更をどのように実行するかに関して、ギター演奏内容からなんらかの影響を受けさせるという処理になると思うne それにしたって、あまり奇妙なところでチェンジするわけにもいかないから、ある程度4小節サイクルで回していくという大枠の中での自由度にすると思うne つまり、ドラムス部分に関しては技術的な難しさはほとんどなく、ほぼ、どういうルールにするかという定義づくりの問題になるne
ベースはそうはいかないyo ギターから送られてきたノート情報を拍単位、小節単位でプールさせて、どのコードである可能性があるかを随時判定させて、弾いても大丈夫な音の集合を用意させるyo 母集合さえ決まれば、あとはzkun伝統のオートベース技術でベースラインをアドリブで生成させることが可能なので、そこから先は技術的な問題はまったくないyo つまり、ベースに関しても、単位時間あたりに発音された音高の集合から、どのコードを指定するかというルールづくりが最大のキモになるne そこまでできたなら、それにピアノ伴奏を付加して、コードやアルペジオを鳴らすのはすでにある技術で可能なので朝飯前だよne いずれのパートも、ロジックを考えることはできたとしても、それを具体的に演奏コマンドとして吐き出させる技術も知識もないという人がほとんどじゃないかなw(含み笑) zkunの場合、これまでの積み重ねがあるので、どのようにすれば既存のルーチンを転用して簡単に演奏させられるかがわかっているので、ものすごいアドバンテージだよne 開発を続けているということは、このように絶大なメリットがあるということだne あとに続く中高生のみんなも是非zkunを参考にすることだne 将来、中高生プログラムコンテスト優勝者のコメントで「zkunさんを目標にがんばってきました!」というコメントが聞けるのを楽しみにしてるyo(妄想笑)
まあ、それはいいとして、技術的にはほとんどBeat v2.8までで使ったもので足りる。単位時間あたりのノートを蓄積するのだって、クロックで区切って、その間に受信したメッセージからノートオンの場合だけ、音高の数値を配列変数の要素番号に順に放り込んでいき、時間を締め切ったら、次の子配列に移る、というだけの処理だよne その後をどう処理するかだけだne
単純に来た音高をその時間中は全部使っていいとするだけなら、アホみたいに簡単なロジックになるne まあ、試作段階ではそのパターンのやつも作ってみようw ただ、音楽ルールはそこまで単純ではないよne(苦笑) 音楽の授業なんかでも少しかじったルールがあると思うけど、それらもあくまで、あらかじめ調性記号がわかっている場合に、その小節では何が使えるかというような説明じゃなかったかな? 事前になにもわかってない状態でいきなり「レミファソラー#ドーー」などと音の羅列が来たときに、はたしてどれをコード構成音、どれを経過音として処理するかは、さまざまな解釈が可能で、前後関係があってはじめてどれが正解になるかが決まるものだよne それをリアルタイム処理でどのようにつじつまを合わせて自然な感じで聴けるようにするかがポイントだろうne
おそらく、より単純な調性、より単純なコードの優先順位を高くすることで、ふつうの素人演奏家が送ってくるノートデータに対して、適切なコードが割りふれる可能性が高くなるような気がするよne(素人の限界を逆手にとる笑) 真っ先にヒットするものがあれば、それに即決させていくという方法で記述していけば、内容もいい線いくし、処理も速いだろうne(微笑) 基本的にそういう感じで構想していってみようかw(方針は決まった笑)
それにしても、なかなか凄い動作になると思うyo いままでありそうでなかったジャンルだからne ポータブルキーボードなんかで、半自動で伴奏が追従してくるなんていうのはあったと思うけど、ほとんどお遊びでしかなかったからne しかも、ギターを弾いて、それについてこさせるなんていうのは、これまでに見たことも聞いたこともないので、これが実際にちゃんと動いたときの感動はなかなか大きいものがあるんじゃないかなと思うne
処理自体はリアルタイム発音になるけど、受信したデータをレコーディングする技術もあるし、伴奏側で何をしたかもすべてログに残せるので、やろうと思えば、今やったセッションをSMFで吐き出して、というリクエストに応えられないこともないだろうne 多少手間ではあるけど。最終的にはその機能もつけるという前提でシステム設計しようじゃないかw(納得笑) 1月からの新プロジェクトはなかなか楽しみなものになりそうですw(含み笑)
PR