前回V2となった蛇腹楽器型MIDIコントローラー("Jabara MIDI")をさらに進化させた。なんじゃそれは？と経緯を知らない読者はV1の記事を見てみて欲しい。

きっかけはM5StackのAtomS3の登場である。アプリからUSBコントローラーを使えるESP32-S3を搭載し、128x128ピクセルの小さい液晶ディスプレイも付いているので、前回のLolin S2 Mini(USB MIDIデバイス本体担当)とM5StickC(操作盤担当)のMPU 2台使いという大袈裟な構成を解消できる。結果的には御覧の通りすっかりシンプルになり、「いつ崩壊するかわからない仮組みの試作品」から「準実用の試作品」に引き上げることができた。

せっかくなのでついでに気圧センサーをBME280からBMP390という新世代の高精度モデルにアップグレードした。V2と同じく内圧用と外気圧用に2個のBMP390を贅沢に(?)用いて差動動作させる。これで気圧変化の検出精度が上がり、より楽に、より豊かな表現が可能となった¹。

次の動画はV1のときと同じ音列を用いたV3によるデモ演奏である。V1に比較して音量変化がリニアであり、蛇腹の小さな動きに敏感に反応していることが見て取れると思う。また感度が高い＝空気の利用効率が高いため、蛇腹の全体的な動きも小さく、無駄が減っている。(音楽的にはそれほどいい演奏でもないが、そこは突っ込まないで頂きたい。)

AtomS3によるUSB MIDIデバイスの作り方

AtomS3をMIDIデバイスとして動作させる方法は、本質的にはV2でLolin S2 Miniを使ったときと同じである。以下にAtomS3固有の気付き事項や注意点だけ挙げる。

ボードマネージャの設定

ArduinoのESP32ボードマネージャから M5Stack-ATOMS3 を選ぶ。
設定項目の USB Mode を USB-OTG (TinyUSB) にする。
- デフォルト(Hardware CDC and JTAG)のままだと、USBはプログラム書き込み＆シリアルポートに固定され、アプリで自由に使うことができない。
USB CDC On Boot も Enabled にしてシリアルポートを使えるようにしておく。
他はデフォルト設定でOK。

アプリ実行モードとプログラム書き込みモード

USB Mode がデフォルト(Hardware CDC and JTAG)の場合、モードの区別はない。
USB Mode を USB-OTG (TinyUSB) にしてプログラムを書き込み、リセットするとアプリ実行モードに移行する。
- プログラム書き込み後自動リセットはかからないので、手でリセットボタンを押す必要がある。
- USB CDC On Boot を Enabled にしていれば、この時点でプログラム書き込み用とは別のCOMポートが見えるようになる。
リセットボタンを長押し(緑のLEDが光るまで)すると、アプリ実行モードからプログラム書き込みモードに入る。

ちなみに筆者環境ではアプリ実行モードでは左画像、プログラム書き込みモードでは右画像のようなCOMポートが見えるので、どちらのモードにあるかはこれで区別できる。

ライブラリ関連

ここまで来れば、V2でも紹介したAdafruit TinyUSB LibraryのMIDIのサンプルがコンパイル＆実行できるはずで、AtomS3のMIDIデバイスとしての動作が確認できるはず。
- Adafruit TinyUSB Libraryには最近ESP32-S3対応の修正が入っているので更新しておくこと。
- 送信/受信の片方しか動かないことがあったので、動作テストは両方向とも試すとよい。
M5StackのAtomS3用ライブラリは使わない。
- USB Mode を USB-OTG (TinyUSB) にするとコンパイルが通らなかった。実は、以前こんな記事で書いたように、そもそもM5Stackのライブラリは価値よりも多くの問題を持ち込むことがあり、必要なければ使わない方がよい。
- 画面描画にはLovyanさんがメンテしているM5GFXを使う。

蛇腹楽器部分の実装

V2で説明を保留した蛇腹楽器部分の実装について、今回は概略に触れてみたい。

ハードウェア

JabaraMIDI V3のハードウェアブロック図:

ソフトウェア

JabaraMIDI V3のソフトウェアブロック図:

蛇腹楽器としてのコア部分、つまりどのデバイスでアプリを書いても変わらない部分は JabaraMIDI Library (緑の箱)として分離してある。これには以下のような機能が含まれる。

気圧センサーの適切な設定とデータ読み取り(Sensor)
センサーのキャリブレーション(Calibrator)
気圧データのMIDIデータへの変換(Processor & Config)
USB MIDIの初期化

この上にアプリケーション JabaraMIDI App (黄色の箱)が乗る。メインループはもちろんのこと、各種ハードウェアの初期化と接続、設定UIといったデバイス依存の処理をこちらで実装する。

リポジトリはこちら:

以下主な処理を簡単に説明する。興味があればコード本体を見て欲しい。

BMP390の設定(Sensor)

JabaraMIDI Libraryに含まれるSensorコンポーネント(ファイルは JabaraMIDI_Sensor_XXX.h シリーズ)は、異なるセンサーライブラリを同じ顔に見せるラッパーであるが、同時に蛇腹楽器向けに適したセンサーの設定を行うのも仕事である。今回追加したBMP390についてはデータシートを見て次のような設定にしてみた。

消費電力は度外視して全力で計測
精度と測定速度のバランスを取るため、オーバーサンプリング4倍(計測時間約12ms = 毎秒約80個のデータポイント)
IIRフィルタを軽くかける

JabaraMIDI_Sensor_BMP3XX.h

// Measure at the maximum speed and power
bmp.setOutputDataRate(BMP3_ODR_200_HZ);
// Use 4x oversampling (~12ms = ~80Hz) with a light filtering to balance
// the accuracy, responsiveness, and the number of data points
bmp.setPressureOversampling(BMP3_OVERSAMPLING_4X);
bmp.setIIRFilterCoeff(BMP3_IIR_FILTER_COEFF_3);

気圧データのMIDIデータへの変換(Processor & Calibrator)

V1で作ったProcessing版JabaraMIDIアプリをC++に移植したものである。ただしV3はセンサーが2個あるので、気圧の絶対値の代わりに、2個のセンサーの値の差をデータとして用いる。

キャリブレーションもV1と同等のアルゴリズム(c.f. 値が一定時間安定したら静止状態と見なしてその値を基準値として採用する)により行うが、やはり気圧の絶対値ではなく2個のセンサーの値の差を用いる。これにより、センサー1個のときは外気圧を推定するキャリブレーションであったのに対し、センサー2個のときは両センサーの個体差等によるオフセットの補正を行うキャリブレーションとなる。

気圧データ取得＆MIDIデータ送信ループ(Engine)

以下の処理をFreeRTOSの高優先タスクとして約80Hzで回す。

2つのSensorの値を読み、差を取る
Calibratorに突っ込んで基準値を取得
基準値に基づき補正した値をProcessorに突っ込む
ProcessorからのコールバックでUSB MIDIを叩いてMIDIイベントを送出する

設定UI(Controller)

M5StickCで作ったV2の操作盤と同等のものをAtomS3の128x128の画面に移植したものである。動作についてはこちらのV2版のデモ動画を見て頂きたい。

このUIで変更できるパラメタは、CC#、CCの最小値(蛇腹静止時の値)、感度、感度カーブの形である²。V1の説明で詳細に突っ込んでいるのでそちらも参照のこと。またミュート・アンミュートの切り替えもできる。

こういうUIや設定永続化を毎度毎度作るのは面倒なのだが、フレームワーク化したり手を抜いたりするうまい方法がなかなかない。下手にサボるとユーザエクスペリエンスの低下として跳ね返って来るので、まぁ致し方ない。

評価(V2方式との比較)

MPUの統合とI2C配線の見直しによりハードウェアが簡略化できたのは大きな進歩。その場限りの実験的なV2とは異なり、恒久的にメンテできる実用品になった。
気圧センサーをBMP390にアップグレードしたことで演奏性能が上がったのも大きな進歩。
イベント送出性能は、実際にDAWに記録されたMIDIデータから、設計通り約80Hz出ていることがわかった。(c.f. MPUの統合によりCPUやI2Cバスが忙しくなり性能が出ないのではないかという懸念があったが、特に目につく問題はなかった。) なお、Engineのタスク呼び出し周期を100Hzに上げてみたところ、イベント送出性能は逆に下がってしまった。一回の処理に10msちょっとかかっている様子で、これ以上の最適化なしには80Hzがギリギリのようだ。
操作用エンコーダーは左手親指で操作できるのが理想。→後日ノブの位置と形を工夫して改善した。
V2を作った際に「そもそもスタンドアロンのMIDIデバイスにする意味は(PC上で追加のソフトウェアを動かすのが苦ではない自分にとっては)特にない、単なる技術チャレンジ」という評価を述べたが、これはV3でも本質的には変わらない。ただ、実用的なハードウェア構成が見いだせたことにより、自分以外の人がこれを作って使う可能性が上がったとするなら、あながち意味がないとは言えないかもしれない。

リファレンス一覧

M5Stack AtomS3ドキュメント
このサイズでESP32-S3と液晶ディスプレイ付き、coolですよ。
AdafruitのBMP390ボード
珍しくAmazonの怪しいパチ物より安かった。STEMMA QTコネクタ付き、アドレス選択ジャンパーが出ているのもプラス。ライブラリはこちら。
BMP390データシート (Bosch)
オーバーサンプリング等のパラメタを選ぶのに理解が必要。
M5Stackのエンコーダーユニット
設定操作用のロータリーエンコーダー＆プッシュボタン。ライブラリはこちら。
M5GFXライブラリ
M5Stackのデバイス共通の画面描画ライブラリ！日本語のガイドはこちら。
M5AtomライブラリのLED機能は使うべからず
M5StackのAtom用ライブラリのdis。優しい意図は感じるし、彼らのライブラリすべてがダメなわけでも決してないのだが、「あーこれは適当に作ってんな」という臭いがするものは確かにあって、そういうのは自分で嗅ぎ分けて避ける必要がある。

科学的に評価したわけではなくプラシーボの可能性は排除できない。あくまで筆者の主観である。 ↩
MIDIチャンネルは1に決め打ちで、この設定UIからは変更できない。最近のDAWは入力先をMIDIチャンネルではなくデバイスで指定できるのが普通なので、まぁ不要だろうと判断。 ↩