MIDI INのデータがPortMidiSharpで上手く取れない問題は解決した。バッファサイズを修正して、戻って来るバッファが中途半端であることを前提として、生バイトからメッセージへの変換処理を実装したら、きちんと動くようになった。...というには一つまだメモリアクセス違反が生じる問題が残っているのだけど。Marshal.UnsafeAddrOfPinnedArrayElement()が返す値だか引数のindexだかがおかしいようだ。とりあえずそういうアクセスを起こさない形にしたら、上手く動くようになった。
あと、今日になって気づいたのだけど、たぶんバルクダンプのsysexの戻り値は、そもそも音源あるいはportmidiのプラットフォームレイヤのレベルで、順番通りに返ってこない。これはportmidiのダンプでも同じことだった。今試しているのは10年以上前のRolandの音源なのだけど、YAMAHAの5年くらい前の別の音源だとまた別かもしれない。
まあそんなわけで、寄り道だったMIDI INはクリアということにしようと思う。これでリアルタイム入力を使ったシーケンサの作成も出来るようになったと考えれば、なかなか悪くない。MIDIメッセージを送りつけるようなハードウェアを自作しても役に立ちそうだ。
ついでにこの前のb=の問題も解決させておいた。引数が二重に定義されていた。最適化以前のコンパイラでは、引数の扱いが異なっていて、チェックされていなかった。いや実におそろしい。
ちなみに先日知人とマクロ定義の引数のスコープの扱いを変えた話をしていたら（MMLの話をしていたというよりは、コンパイラで関数を展開する話をしていた）、これはどうやら古典的lispとschemeの違いでもあるらしい。lispでは呼び出し元の関数で定義した引数をそのまま参照できていたが、それでは呼び出し元を全て辿って参照解決しなければならないので引数参照の解決の効率が悪いとして、schemeではこれを許さないようにしたという。たかだかMMLコンパイラでも、過去の話が繰り返されているようだ。面白い話があったものだ。
Leave a comment