１週間ほど経過しましたが、5/30に関ケ原ふれあいセンターで開催された関ケ原Ruby会議01に東軍中堅として参加し、Picorubyを用いた個人開発のMIDIデバイス、MIDoRIの発表をしてきました。当日の感想や発表中で伝えきれなかったことなどを書きたいと思います。
そういえば、当日発表中の自己紹介では触れなかったのですが、2010年ぐらいからRubyコミュニティに出入りしているのですが、実は遠征するタイプの地域Ruby会議参加するのは初めてなんですよ。
当日までの準備など
前回のブログでも触れているのですが、今年の３月ぐらいからちょっとずつ外に発表できるレベルに仕上がってきた、個人開発のMIDIデバイスのMIDoRIの発表先として、ちょうど募集していた関ケ原Ruby会議01のCfPに応募したところ、採択していただき、発表の機会を得ることが出来ました。ありがとうございました。
単純に次の発表の場として、気軽に申し込んだのですが、関ケ原Ruby会議は関ケ原という世界観を重要視した地域Ruby会議となっており、武将ネームの登録や数々のロールプレイを求められるなど、中々不慣れなところはありましたが、オーガーナイザーの方にもフォローいただきつつ、楽しむことが出来ました。
なお今回はMIDIをテーマにした発表だったので、かの有名なRoland製品であるところの「ミュージ郎」の名前をお借りして、名乗りを上げました。人を選ぶネーミングチョイスですが、一部の人にぶっ刺さってくれたので、概ね狙い通りだったかと思います。
なお、発表内容はRubyKaigiの時点から概ね固まっていたのですが、デモだけはRuby Illuminationでやったものとは違う方向性でやろうと思っていて、関ケ原の世界観を踏襲して和楽器を使った合奏デモにしました。普段使わない音色ばかりだったので、和楽器系のYoutube動画や音楽サイトを巡回し、どういう構成にすれば和楽器演奏っぽくなるのか学びながら作りました。
発表の補足など
今回1トラックだったので、参加者全員に発表を聞いていただくことなり、MIDIに興味がある人、そうでもない人、様々な方に感想ブログや発表終了後の休憩時間・懇親会などで感想をいただけました。ありがとうございます。その上で、当日の発表の振り返り、補足、感想に対する振り返りなどを書ければと思います。
色々前提知識などを含めて話したいこともあったのですが、20分という時間の中では語りきれないことも多く、個人的反省としては後半のpicoruby-midi標準化の下りと2つ目のデモをカットしてでも、もうちょっと前提の話をしても良かったかなと思いました。
このデバイスは何に使うのか
当日発表の中では電子音楽の中に挟み込んで、RubyでMIDIメッセージの制御を出来るんですよー、という機能的な話に留めましたが、電子音楽のジャンルの中にはマシンライブというジャンルがあり、複数の電子楽器を組み合わせて、楽曲を作り上げるプレイスタイルがあります。例えば以下のような動画です。
このように複数の楽器を組み合わせる場合において、それぞれをMIDIケーブル等で結線し、MIDIメッセージでやりとりをするわけですが、なんでも自由に組み合わせられるというわけではなく、そこにはそれぞれの機器の送信側・受信側のMIDI実装の対応状況に依存します。（加えてインターフェースが相互に異なる場合もあるので、変換などが必要な場合もあります。）また対応していても設定の切り替えが難しく、プレイ中に設定を切り替えることができないケースもあります。
これを解決する手段として、PCのDAWを経由して制御するという方法があります。例えば私はAbleton Liveというソフトを使っているのですが、一旦全ての接続をPCに集約し、そこから各機器に流し直すことで、柔軟な接続が出来ます。
ただし、これはDAWが対応している機能に限定されるので、やはりそこにも一定の限界はあります。またDAWレス派という、この手の演奏にPCを使いたくない人も一定いるので、そこに何らかの解決するデバイスが必要です。実はハードウェア的に解決するような製品もいくつかあるのですが、これらは需要も少なく一つ一つのデバイスが高価になりがちです。
MIDoRIはこういうシーンにおける課題の解決を目的としています。
MIDoRIは今後どこを目指していくのか
これは懇親会で笹田さんとお話ししたときにご質問いただいた内容で、MIDoRIは今後どこを目指していくのかという質問をいただきました。自分も今後どうしていこうかというのは、悩んでいたところでした。
直近やりたいことは、発表中にお話した通りで、
1. picoruby-midiをMIDoRI専用から分離して、他のpicorubyデバイスでも使えるようにする。
2. Bluetooth MIDIに対応して、他のMIDIデバイス同様BLE-MIDIに対応した機器も繋いでMIDoRIで制御できるようにする
3. PCでRubyのコードを書いて、MicroSD経由でMIDoRIに転送するのが面倒なので、R2P2的なソリューションを考える。（発表中ではR2P2を組み込むと説明しましたが、R2P2そのものの組み込みたいわけではなく、ブラウザなどから転送するソリューションさえ確立すれば、それで良いなと後から思いました）
4. 現状はUSB-MIDIのホスト機能だけ対応している状態なので、デバイス側も対応して、PCやホスト機能を持つMIDI機器に接続したときにMIDIデバイスとして認識させるようにする。
5. タッチUIを活かして、もっと汎用MIDIデバイスとして使えるようにUIを充実させる。例えば特定のCCを操作するダイアルを実装したり、スライダーを作ったり、XYパッドのように複数のパラメータに同時に作用させられるようなものも作れるはずです。（このあたりは笹田さんから専用のハードウェアインターフェースを拡張させることも可能なのでは、という示唆もいただいており、確かにそういう拡張が簡単にできれば、それも楽しそうだなと思ってます。）
あたりをやっていこうと思います。
このあたりはもう課題設定が完了しているので、あとは時間とやる気さえあれば出来るという状態で、今後どうしていきたいか、ところに関しては、悩ましい部分があります。
一つの方向性としては、よりデバイス単体でできることを増やして、単独で作曲をできるようにしたり、もう少し機能をDAW側に近づけていくアプローチです。この方向としては、先駆者としてM8 Trackerなどのデバイスやnanoloopというソフトウェアなどがあります。
オールインワンで何でも出来る音楽デバイスというところには魅力はあるのですが、こうなってくるとpicorubyを乗せてMIDI制御するという意味合いは薄れてきます。より楽しいデバイスにはなりそうですが、敢えてpicorubyを乗せてやるからには、もうちょっと面白い方向を模索したいところです。そもそもDAWとしての機能の充実を求めるのであれば、PCでやればいいわけで、そこと張り合うのはスペックが限定された組み込みデバイスでやるにはちょっと分が悪いです。
懇親会の中で、OSC（OpenSound Control）やMIDI2.0などに対応していくのはどうかというご意見を発表者で東軍先鋒のkazzixさんからいただきました。このあたりはそもそも対応機器を持ってないと、実装のモチベーションがない、ということもあるのですが、全然考えたこともなかったので、対応するとどういう事ができるようになるのか、含めて考えていこうかなと思います。
MIDoRI開発の楽しいところとか
あまり発表中には触れなかったことですが、普段抽象化されたレイヤーの上で、仕事をしているので、あまりコンピュータを制御しているという実感はありませんが、MIDoRIは小さい組み込み機器の中ではありますが、CPU・メモリ・各種IOなど、機器のすべてを意識しながらプログラミングをしています。画面切り替えの処理の最中に別タスクでメモリアクセスをすると死ぬとか、割込みの優先度を意識しないとフリーズするとか、Web開発をしている中では、あまり意識しないことです。
FreeRTOS上で動いているので、完全独自のOS開発をしているわけではないですが、自分のコンピュータとは別の趣味の延長上にこういう世界が見られるとは思ってもいなかったことです。
今後も何か機能実装が出来たら、お披露目していきたいと思います。発表中に楽器の収集と演奏が趣味と話した通り、開発に負けないペースで電子楽器を買っていたりもするので、毎回違う電子楽器をセットアップしてデモが出来ると楽しいなと思っています。
picoruby-midi標準化について
懇親会で、picoruby作者のhasumikinさんと、今後picoruby-midiをどうしていけば良いかについて方針を相談することが出来ました。
実はちょっと前にマージ方針を相談するissueを書いていて、それについての返信を関ケ原Ruby会議01前にいただいていたのですが、私が気づいておらず、先日ようやく確認できたところです。
その上で、以下のようにする方向で、方針を合わせました。
- picoruby-midiは巨大なので、picorubyには取り込まず当面はmrbgemとして自分のリポジトリで管理する。
- picoruby-usb_midi、picoruby-uart_midiなどはRP2040/RP2350などのportもできれば、改めてpicorubyで取り込むことも検討する。
自分も発表中に話したように、picoruby-midiはメモリ面の懸念があるなど、巨大になっているのが問題と思っているので、まずはもっとプリミティブなpicoruby-usb_midi / picoruby-uart_midiが省メモリで動作するようになるように見直して、その上でこれらを統合的に管理するpicoruby-midiをMIDoRIをリファレンス実装としてメンテナンスしていければ良いなと思っています。
picoruby-midiの標準化に興味がある方や、自分のプロダクトに取り込みたいと言っていただける方もいたので、これは話せてよかったなと思います。まずはリポジトリから用意していこうと思います。
他の人の発表、感想
どの方の話も楽しく聞かせていただいたのですが、自分と同じ枠で発表していた西軍中堅のpockeさんの発表には触れておかないといけないというかｗ
今回RubyKaigi中にpockeさんからは「実はMIDIの話なんですよ」と事前情報をいただいており、MIDIの話が来るということが分かっていたので、コントラスト映えするような内容にしようと意識していたのですが、MIDIキーボードで文字入力という発想には恐れ入りましたｗ
ただ、よくよく考えてみればMIDoRIでも今後USB-MIDIデバイス対応の過程でついでにHIDデバイスクラスを作れば同じ事ができるな…とも思い。1つのUSBに複数のデバイスクラスを持たせるのはPCはともかく電子楽器では対応していないこともあるので、実際にやるかどうかはともかく別観点のヒントを頂けました。
お互いのネタをオープンにしたときに、「これ運営、ニコニコしながらこの対戦カード組んだでしょうね。」という話にもなり、今回組まれたタイムテーブルにはそういう運営の妙が光ってましたね。
Rubykajaとか
そういえば、Roppongi.rbからRubykajaに推薦していただきました。ありがとうございます。
Roppongi.rbはOmotesando.rbからスピンオフして生まれた背景もあり、共同開催することもありますし、自分の所属する企業が六本木ということもあるので、積極的に参加していたのですが、気が付いたらroppongi.rbオーガナイザーの独断で推薦されました。こういう選出方法でもいいんだ…ｗ
自分が主催するomotesando.rbはというと、特にkajaを推薦しよう、という話があったわけではなく、（仮にあったとしても）自分が選出されてマッチポンプになる雰囲気もあったので、まあそれならいいか…というつもりで今回は不参加でした。
なんですけど、これをやると今後も推薦できなくなるなー、ということに後から気づいてしまったので、まあ次からはちゃんと参加しましょうね…という反省です。
観光など
二次会、三次会と普段RubyKaigiでしかお話ししないような遠方にお住いの方も含め、色々な方とお話ししながら、総じて楽しく関ケ原Ruby会議を堪能させていただきました。運営の方ありがとうございます。
今回武将として参加することで、運営と参加者のちょうど中間ぐらいの立ち位置で参加することができ、普通に参加しているだけでは得られない経験が得られました。
2日目は、何も用がなければ早々に帰ろうとも思っていたのですが、関ケ原なんて人生で2度来るかどうか分からん、ということもあり、車を借りて、養老方面に出かけました。
武将を運転手にする大名2人 pic.twitter.com/9MSZWPE7PK
— 南谷 祐貴(MINAMIYA Yuki) (@yuki3738) 2026年5月31日
養老に出かけたのは、養老焼肉街道というのが、なんとも美味しそうだったのと、養老天命反転地という謎のネーミングの公園、養老の滝などもついでに見るか、という感じで、車でぐるっと観光してきました。
残念ながら焼肉はランチ時間の終了で、食べられなかったのですが、養老ビーフのステーキランチは養老焼肉街道の近くの店で食べられました。美味しかったです。
既に美味しそう pic.twitter.com/XUfURKgTBV
— Toshio Maki (@Kirika_K2) 2026年5月31日
最後に
たまたま発表するネタがあったから、ということで参加した地域Ruby会議への初遠征ですが、とても楽しかったです。
さすがに毎回は参加するのは、金銭的にも時間的にも厳しいので、またしばらくはないと思いますが、またたまには顔を出せればよいなと思います。
改めて、運営の皆さん、参加者、発表者、大将の皆さんお疲れさまでした。
