keebkaigi2023でPRK_FirmwareにMIDIを実装する話をしました #keebkaigi

松本から帰宅して、しばらく療養生活をしていたため、ブログに書くのが遅くなりましたが、5/11～5/13に松本で開催されたRubyKaigi 2023の前日イベントとして開催されたkeebkaigiにLTスピーカーとして話してきました。

2018年にキーボード会議を開催して以来、最近のRubyKaigiでは何故かキーボード勢として参加している気がしなくもないのですが、これまでゲリラ開催だった突発的キーボードミートアップが、オーガナイザーの手により、一イベントとして独立するようになったことに嬉しさを感じ、日常の多忙さ（仕事・家庭・etc）に二の足を踏みつつも、無謀にLTを申し込んだのでした。

資料もアップしようかと思いましたが、当日はYouTubeチャンネルで中継があり、YouTubeにもしっかり発表記録が残っているため、そのまま流用させてもらいます。
www.youtube.com

発表の意図など

発表内容はLTとは関係なく以前からやろうと思って考えていたもので、選考があるとは聞いていたものの、内容的にACCEPTされる可能性は高いと考えており、LT申込をした時点から実装を開始しました。

当初から目指していた実装目標として、以下のようなものを考えていました。

PRK_FirmwareをMIDIデバイスとして認識させる。
QMK Firmwareと同等のキーマップでMIDIキーボードとして使用することができるようになる。
PRK Firmwareで使用されているMusic Macro Languageの実装を流用し、MIDI再生に応用する。

実際、ギリギリではありましたが、すべての実装が発表に間に合い、無事LTに持っていくことができました。
その分発表資料を練る時間には回せなかったので、そこはまずまず…でしたが、発表自体もあんまり練習もなく一発勝負で臨んだ割には、ほぼ5分ぴったりにLTが収まったのは良かったなと思います。

個人的反省としては、実装したものや背景を紹介するのに必死すぎて、いまいち内容が伝わってなかったんではないかと思いました。
ネタバレを防ぐつもりで、デモを展示の場に出していなかったのも敗因ですね。

次の日以降RubyKaigiには、デモ機（iPad）とキーボードの最小構成デモを持ち歩いて、作ったものをプレゼンし歩いてました。

昨日の #keebkaigi で消化不足だったデモの部分をiPadのSC88proと実装したMIDIキーボードの最小構成でデモしたら、特定年齢層に刺さりまくったので、今日のデモは成功です。 #rubykaigi pic.twitter.com/5WWNrPWdsm
— Toshio Maki (@Kirika_K2) 2023年5月11日

開発の裏側

MIDI自体は非常にシンプルなパケット（2～3バイトの組み合わせ）なので、Ruby<->C言語のブリッジを書いてしまえば、後はRuby側でパケットを作って配列を渡すだけで良く、さほど苦労もなかったのですが、一番苦戦したところは、MIDIデバイスとしてPRK Firmwareを認識させる、というところだったりします。

PRK Firmwareは複合デバイスとして作られており、キーボード以外にも（マウス・ジョイコン等の）HIDデバイス・シリアル通信・ストレージデバイス（PRK Drive）などとしても振舞うため、複数種類のデバイスクラスを持っており、ここにさらにMIDIデバイスクラスを追加する、という改修を入れました。MIDIデバイスクラスのサンプルを参考に実装したのですが、当初は全くUSBデバイスが反応しなくなり、そのたびにpicoprobe（デバッグモニタ）とキーボードを繋いで、gdbでデバッグをしてました。

Windowsで開発していたのでUsbTreeView.exeも役に立ちましたね。おかげでUSBディスクリプタがバイナリのままでもある程度読めるようになりました。
infinitegra.co.jp

USBディスクリプタが正しく動くようになったとしても、その後ブートしてRubyVMが立ち上がり、そのうえでRubyのバイトコードが動くようになるまでデバイスとして表示されることはないため、暗中模索で本当にこれで大丈夫なんかいな…と不安でした。gitのコミット日付によるとMIDIの実装を完了したのが4/16で、実際動作して、ドレミファソラシドが叩けるようになったのは4/30らしいです。ギリギリすぎますね。

とりあえず発表になりそうな最低限までは達したので、ここから映えを上げていく。
— Toshio Maki (@Kirika_K2) 2023年4月30日

MIDIデバイスとして動作するようになってからは、シリアルコンソールが動作するようになったため、デバッグが大幅に楽になり、残りの実装をGW中に終わらせました。
ほぼすべての休日をこれに充てていたので、家族には感謝です。

当日の話

　当日はLTが終わるまでは多少の緊張はあったものの、デモも事故なく終えることができました。他の方の発表もみんな色んな着眼点を持っていて聞いていて楽しかったです。
　好きなものにかける情熱の話は聞いていて楽しいですね。そこに人が集い、新たなコミュニティが生まれるというのはとても心地よく感じました。

　私もMIDI方面で、これまでお話したことがなかった方たちとお話しする機会を沢山いただき、RubyKaigi中を含め、楽しい時間を過ごすことができました。
　オーガナイザーの皆様、お疲れさまでした＆ありがとうございました。

After Keebkaigiの話

　東京に戻ってきて、いくつかやり残したことがあり、土日で片付けてました。
　Keebkaigi前にこの発表で使用したコードを事前にDraft PRを出していたのですが、これをちゃんと本PRにしようかどうか悩んでました。

github.com

　取り込んでもらいたいのは山々なのですが、既存のキーボードクラスにがっつりと食い込むうえに、リソースを食うので、やるにしても環境変数をつけてビルドするオプショナルなやり方かなぁ…と。QMK Firmwareもコンパイル時にMIDI使用のオプションで振り分けるやり方ですし。
　最近SQLiteの取り込みがPICORUBY_SQLITE 環境変数を使ったオプショナルになったっぽいので、それに倣おうかと考えてます。

　このPRを提出した際に、case whenのwhenを大量に書くと落ちる、という問題があり、それを解消する必要があったのですが、prk_firmware作者のhasumikinさんとお話しして、Debug print有効化のオプションがあることを教えてもらい、この土日でオプションを有効化して調査したところ、parserのstackがオーバーフローしている問題に関連していることが分かり、現在サイズの拡張を提案中です。

Syntax Error at case / when statement · Issue #145 · picoruby/picoruby · GitHub

　ただ、このスタックサイズの拡張で問題は解決したのですが、PRK Firmwareに持っていったときに、またしてもRubyVMが立ち上がる前にファームウェアが死ぬという問題に当たってしまい、まだ原因の特定に至っていないのですが、安易なスタックサイズの拡張でいいんだろうか、という迷いもあります。この話に決着をつけたら、ようやく自分のKeebkaigiが終わりそうです。

　次は発表の内容にも書いていたように、次は手元のMIDIキーボードをPRK Firmware化するのにチャレンジしようかなと思います。