どうしても先にやらなくてはいけない別のことが立て込んでいて、プロジェクトがとまってるだけです。

多分6月ぐらいから再開予定です。

なにもかもどうにも手が遅くてすみません。

Serial MIDI は、レガシー MIDI の規格と違うのですね。不勉強でした。レガシー MIDI にしないとつなぐ機器がありません。

解決法を思案しています。今のところ思いついているのは2つ:

1. USB MIDI -> レガシー MIDI 変換をするデバイスを作る
2. Serial MIDI -> レガシー MIDI 変換をするデバイスを作る

もあさんの PepperMIDI をベースにできるならば 1. の方法のほうが良さそうです。

PepperMIDI の作りは、以前 SX-150 の MIDI/CV に使ったときにはあまり詳細を見なかったのですが、気になるのは

• クロックはどうなっているか？MIDI 信号を出すならクロックはそれなりに精度が必要
• Pepper MIDI がマイコンの UART 機能を使っていると、実装が面倒になる

の二点です。早速ソースコードをざっとチェック

クロックは RC クロックを USB 信号を基準にして 8.25MHz に校正するようです。よくできています。USB 信号の精度が MIDI クロックに使うのに十分なら、ここは問題ないはずです。

UART は、PepperMIDI で使われている ATTiny45 にそもそも用意されていないので、問題ないようです。

ということで、PepperMIDI の MIDI 受けの部分を ATTiny2313 に移植すれば USB MIDI -> レガシー MIDI 変換はやれそうと今のところ考えています。さてさてどうなることやら。あっ 2313 のプログラム領域に全部入りきるかも気にしないといけませんね。ATTiny45 を使うなら問題なさそうですが、シリアル通信プロトコルを実装するのがちょっと面倒かもしれません。あと、手持ちがない :-)

今度こそデバッグ機能が必要になるかな。AVR dragon の使い方を覚えなくては。近頃覚える必要のあることが多くてちょっと泣きそうです。

それにしても、PepperMIDI のコード、かっこいいです。とてもきれいに書かれています。

nanoKEY の信号をシリアルポートに出力させるところまでできました。

一日60分程度しか時間を割いていない（さけない）亀プロジェクト．．．ですが、なんとかじわじわと前進．．．

今のところ、プログラミングなしでできています。遅延の問題がなければ、このままスクリプト作成ぐらいで済ませても良い気もしてきました。問題は、小型化したときにディスプレイなしでどうやって起動確認するかですね。電気的にシリアルの TxD 信号をモニタするのが良いかもしれません。信号を検知したら LED を光らせる回路をくっつけておくのはどうかしら。

http://gaje.jp/projects/labo/usb_midi_host/#section5

• 開発機(デスクトップPC)に Linux をインストールしてみる (debian)
• とりあえず何でもいいからソフトで認識をさせる (kmidimon)
• それがどんな API を使っているか調べる (ALSA sequencer API)

まで進みました。どうやら、ALSA sequencer API というものを使えそうです。前の記事に、自分が MIDI ドライバ作るなら、サーバとして作ってイベントのやりとりはソケットで、と書きましたが、理解違いでなければ、どうやら、実際にもそれにかなり近いつくりになっているようです。

詳しく、もないですが、詳しくはこちら。

http://gaje.jp/projects/labo/usb_midi_host/

しかかり中プロジェクト置き場のページを作りました。

近頃話題の nanoKEY、私も入手しました。nanoKEY、小さくて便利ですが、USB MIDI のみ対応なので、USB ホストがないと使えません。

普段のシンセ作業では、nanoKEY 導入以前から、PC から MIDI モニタソフト経由で MIDI 信号を出していたので、USB MIDI でも全く不都合ないのですが、nanoKEY をたとえばデモなどで持ち出して使いたいときには、PC がなくてはいけなくて少しとりまわしが悪いです。

ということで、nanoKEY をスタンダロン MIDI 化すると、とっても便利そうです。

シンセ自作界隈の皆様同じように考えられているようで、マイコンを使って USB ホストの実装をすることを検討し始めている方もいらっしゃいます。

ところで、そもそもスタンダロン化するにはどんなアプローチがあるでしょうか？だいたいこんなところでしょうか

• nanoKEY 自体を改造して、レガシー MIDI が直接出せるようにしてしまう
• じゃまにならない程度に小型のホストを開発してしまう

前者は、仕上がりすっきりしますが、MIDI 信号を発生するプログラムを書き直す必要があります。nanoKEY は、使ってみるとわかりますが、弾き具合など、とてもしっかりチューンされていて、同じ弾き具合を再現するのは（とても勉強になりそうですが）ちょっと大変そうだし、内部に手を入れて壊してしまうリスクも伴います

ということで、まずは後者のアプローチのほうが無難そうです（とはいえ楽ではないのですが）。そこで、マイコンを使って USB ホストの実装、となるんですが、私にはUSBホストを実装するウデはない、でもやっぱりスタンダロン化はしたい、ということで、ちょっと違うアプローチをとってみることにします。

それはこんなアプローチ：

nanoKEY -> (USB) -> シングル・ボード・コンピュータ (Linux) -> (シリアルポート) -> MIDI out

シングル・ボード・コンピュータというのは、超小型の PC です。どれぐらい小さいかというと、たとえば 3.5インチディスクぐらいの大きさです。中にはフロッピーディスクサイズのものもあります。れっきとした 386 互換機もあって、普通に Windows や Linux などがインストールできます。ディスプレイも普通のを使えます。これだと、使い勝手は普通の PC と変わりませんから、USBホストの知識がなくてもやれます。でもまあその、高くつきます。SBC の値段は nanoKEY の何倍もします。なのでちょっとアホらしい方法なのですが、今、死蔵している SBC があるので、「新たにモノを買わない」というルールのもとにプロジェクトを立ち上げました。

現在のところの進捗状況

• まずは、テスト・開発を行うため、普通のデスクトップ PC に Linux をインストール
• nanoKEY をつないで、認識されることを確認

MIDI 出しのところは、シリアルポートから MIDI 信号を出すソフトを書いてしまおうかと。ということで、USB-MIDI ドライバから情報をもらう必要があるので、次には、Linux の USB-MIDI ドライバがどんな仕組みになっているかを調べ上げることになります。

ここはドキュメントあさりになります。が、あまりに安易なので、ちょっとは考えてみることにしました。もし自分が USB-MIDI ドライバを作るのだったらどうするかな？ええと、USB-MIDI の信号を拾いたいアプリは、一度にひとつとは限らないから、ドライバは共有できるようにしたいです。そして、リアルタイム性が重要だから、ドライバとアプリの通信は、プロデューサ・コンシューマモデルがいいでしょうか。共有するプロデューサ・コンシューマモデルといっても、シェアドメモリとかファイルとか、共有の受け渡しリソースを介すると、どっから読み始めて？、とかリソースサイズは？、とか、かなりうっとおしそうなので、受け渡し自体はアプリと一対一の接続で、ドライバからアプリに一方的にイベントを流し込むやり方が楽そうです。
と、いうことで、ドライバはサーバとして実装して、アプリとの通信はソケット経由、イベントは、サーバからアプリへ一方的に流し込めばいいし、ネットワークを介さなければパケットの消失もあまりなさそうなので、通信は UDP でやるのがいいのかな？こんな感じかなぁ

ということで、次には実物のつくりを調べて答え合わせしてみますです。

http://tldp.org/HOWTO/MIDI-HOWTO.html