November 2009 Archives

今使っているPCがVistaなのだけど、購入したのがほんの数ヶ月前なので、Windows 7へのアップグレード権もほぼ無料で付いてきた。7は失敗作Vistaよりは多かれ少なかれマシであるようなので、7に移行しようかと思っていた。

しかし、どうやらプロプラエタリOSの移行でネックになるのは、プロプラエタリドライバしか配布していないハードウェアが新しいOSでサポート対象になるかどうか、であるようだ。いま手元にRoland SC-8820があるのだけど、Webで簡単に調べてみたところ、RolandはどうやらWindows 7のドライバを提供しないらしい。

しかし、Windows 7のカーネルはVistaとあまり変わらないはずだ。Vistaで動作して7で動作しないとしたら、一体どのような変更が7で加えられたのだろうか。そう思って調べてみたところ、むしろVista SP1では、Windows 7で使用されるドライバのモデルと整合するように、いろいろ手を加えたはずだということが分かった。だとしたら、Vista SP1までドライバが提供されていた製品が、Windows 7で動作しなくなるとしたら、それはだいぶcorner caseなのではないか。

そう思ってさらに調べてみたら、どうやらVista互換モードでドライバのインストールを実行すれば、MIDIデバイスとして認識するようになるらしい。どうやらドライバにまで互換モードがあるようだ。

2010-05-06 追記: ...と思っていたのだけど、実際にWindows 7にアップグレードして互換モードでドライバをインストールしようとしても、不明なエラーで失敗してしまうようだ。VectorにはSC-8820で動作確認したという報告があるのだけど、これがウソである可能性は考慮しておくべきだった。これはWin7にアップグレードするべきではなかったかもしれない。

ちなみに、Windows 7とだいたい同じくらいの時期に登場したSnow Leopardでは、何も手を加えなくてもドライバがきちんと機能しているようだ。こちらの方がOSのAPIの不安定ぶりが大きいように思うのだけど、Core MIDI Serverに変更が無かっただけなのかもしれない。

もちろんLinux環境では、大きな変化も無く安定して動作している。こちらも11月に出たOpenSUSEに刷新したばかりだ。Linux環境では、pulseaudioが大きく進化していることはあるけど、alsa midiまわりで大きく変化することは無いだろう。

今日はかなり余談。

最近...に限った話でもないけど...Googleは以前から社内でかかえていた...と思われる...Web技術を公開してきていて、独自色が目立つようになってきた感がある。nacl (native client), protocol buffer, wave protocol, SPDY, あと微妙に関係ないところでgolang...そのうち「何でも自社技術で」みたいなことになりはしないかと思わなくもない。ともあれ、どれにもあまり深入りしてはいないのだけど、それぞれなかなか面白そうに思う。（他にもnoopとかmapreduceとかopensocialとかandroidとか、googleの技術はいろいろあるけど、際限が無いのでこれくらいで。）

goはいずれGAEでサポートされるようになるだろうし（そのためにあるものだと思っている）、まだforeign function interfaceの実態が見えてこないので様子見としている。ffiが使えるようになれば、既存のライブラリやフレームワークとembedded APIを通じてinteropできるようになるだろうから、期待している。けど、一方でnaclの時も似たような期待をしていて、未だにそういう現実が来ていないことを考えると、そっちの未来は来ないかもしれない。

waveは(gadget APIだのrobot APIだのにはあまり興味が無く） protocolに興味があって、中で使用されているXMPPなども読んでみたりしたのだけど、あまり深入りしていない。XMPPのC#ライブラリなんかは、ほとんどがフリーソフトウェア (free as in speech)なので、組み込み向きではなく、たとえばiPhone向けにはフルスクラッチで作る必要がありそうだ。waveではprotocol bufferも使用されていて、これのC#版はそのまま流用できるのではないかと思う（開発しているのも知り合いみたいだし）。今あるwaveのUIはあまり気に入っていない。ブラウザ向きではないのだと思う。この観点では、既に登場してきた他のサーバ実装についても、あまり期待していない。

SPDYはHTTP 1.1みたいに、少しずつWebを変えていくことになるかもしれないとは思う。Windows Liveの開発者から「これはHTTPのembrace and extendだ」などと嫌悪の声が上がっていたので（勘違いも甚だしいと思うけど）、liveは対応しない可能性が低くないと思うし、IEも対応しない可能性はある。でもそうするとIEは他のブラウザに比べてただ遅くなってしまう。MSがいくら自社でSilverlightで高速化できたとしても、Silverlight自体はブラウザ中立技術だからこそ「ActiveXとは違って」普及しているわけだし、他所のサイトまで変えることは出来ない。既にHTML5対応の遅れでwaveなんかは開けなくなっているし、IEは今のままでは技術的に可能なことを政治的に実現できなくなる可能性が低くないと思う。この方面でも旧弊を駆逐する新しい波があると良いのだけど。

まあWeb方面は手が付けられるようになったら適当につけてみよう、くらいに（は）思っている。

前回はrenoiseで遊んでみようと思い立ったのだけど音色が多くないという話を書いた。書いてからrenoise用の音色をいろいろ落として遊んでみたが、やはりMIDIほどのバラエティは無い。で、renoise自体はMIDIデバイスを叩くこともできるようなので、それだったらMIDIと連動するようにしたらいいんじゃないかと思うようになった。ここでもちろん餅楽やSC-8820などを繋いでも良いのだけど、今のところ自宅にはミキサーすら無いので、できればPCのオーディオ出力だけで完結させたい。そしてクロスプラットフォームなやり方で作業したい。

そんなわけでまず有名どころでtimidity++を見てみた。実のところtimidityは以前にも使ってみたりなどしたのだけど、Mac OS上ではCore MIDI Serverとして動作してくれるような常駐モード (-iA) が無い。歴史もかなり古いもので、ソースは今ほとんどいじられていない。なるべくなら他の選択肢がほしいと思った。

それで次に発見したのがfluidsynthだった。これはsoundfontを読み込んでMIDIデバイスとしてしよう可能にするもので、MacではCore MIDI Serverデバイスとして動作することも出来るし、パッチメールなどを見る限り、WindowsでもMIDIでバイスとして動作するのだろう。しかも最近でも積極的に開発されている。すばらしい。おまけにタイムリーに今ちょうどReactOSのデフォルトMIDIデバイスに使用するのはどうかという話まであるようだ。というわけでfluidsynthを使ってみることにした。

さて、fluidsynthはそのままでは何も音をならしてくれない。サウンドフォントが必要になる。これはいたる所からダウンロードできるようだけど、とりあえずfluidsynthのtracのページでリンクされている2つをダウンロードして入れてみた。30MBのものと140MBのもので、後者はdebianのパッケージになっていてそのままでは他の環境で使えないのだけど、オリジナルアーカイブがほぼそのまま使えるようだった。Mac OS上でportmidi-sharpのサンプルを使って演奏させてみたところ（Core MIDI Serverモードだとそういうことが出来る）、SC-88Proで作成したSMFは、前者の方が音量バランスが近いかたちで再生できた。

他にもいろいろ調べたけど、今日書くのはとりあえずここまで。

先週末にようやく重い腰を上げてMotif Rack ES（以下餅楽ES）を分解して、ヘッドホンの先端が折れたまま残ってしまった部分の修理を試みたのだけど、さすがに簡単に取り出せることはなく、仕方ないので接続ケーブルだけ外して、別のオーディオ出力（そんなものが付いているのである）から配線して、何とか音を出せるようになった。めでたい。

しかし、いざ餅楽ES用のエクスクルーシブを使ったマクロを作成していじり倒してやろうと思い、マニュアルを開いてみて、大変がっかりさせられる事実に気がついた。どうやらMIDI演奏を行うためのマルチパートモードでは、インサーションエフェクトが1種類しか使えず、それが8チャネルで共用されるだけに過ぎないのである（これがまた、先の製品紹介ページの説明からは到底読み取れない事実なのでますます腹立たしい）。Roland SC-8820ですら2種類同時に利用できるというのに、何とも失望させられる話だ。

そんなわけで、コレをいじる最大の動機が失われてしまったので、後はボイスモードを使った単なる音作りを主目的として使うことにして（餅楽ESはウェーブテーブルをアルゴリズムに基づいて接続して加工する分には実に面白そうな音源である）、別途遊べるソフトウェアシンセサイザを探すことにした。

それで引っかかったのがrenoiseだ。trackerベースのDAWで、Linux/Windows/Macのバージョンがある。有償なのだけどまあ4９€だし、1ライセンスでどの環境向けの製品も利用できて、そもそも機能制限がほとんど問題にならないレベルなので、しばらく遊んでみようかと思っている。MIDIやVST、ReWireをいじることも出来るようで、vocaloid2と連動させた例も紹介されている。単なるMIDIよりは表現力がある（まあDAWなのだから当たり前か）。

そしてどうやらデータフォーマットがかなりオープンに出来ているらしく、phpやC#をはじめさまざまなデータ作成ツールが公開されている。データは実際音色のもとになるoggやflacと、楽曲情報を記述したxmlファイルをzip圧縮しているだけで、そのXML形式のスキーマも（残念ながらxsdではあるものの）renoise自体に含まれている。これはもしかしたらもしかしちゃったりするんじゃなかろうか。mugeneをそのまま再利用するのは面倒そうだけど、類似のコード構造で何か作れそうな気もしてくる。まあ、いいかげんDAWの操作に慣れた方が良いのかもしれないけど。

問題は、音をいろいろ加工しようと思ったら、DSPを通す以上やはりMIDI音色ではなくPCM音色をいろいろ調達しなければならないのだけど、プリセットで用意されている音色が大変少ないということだ。ユーザーが公開している音色がそれなりにあるようなので、かき集めてくればいろいろ作れそうではあるけど、ちょっと面倒かもしれない。

ちなみに既存のツールの中で興味を引くものは無かったので、やるならフルスクラッチで書くことになるんだろうなあと思う。まあ11月はいろいろ忙しくなる予定なので、やるなら12月になってからだろうか...

しばらく仕事でてんぱっていたのと、REST系のプログラムを書いたりなどしていたことなどもあって、音楽系のプログラミングから遠ざかっていたのだけど、最近ちょっと某冬の祭典に参加してみようかと思ってリハビリがてらFM音源をいじっている。というと正確ではないのだけど...エミュレータだから。しかしFM音源環境で新しく楽曲を打ち込むにはちょっと時間が足りなそうだったので、昔MIDIで打ち込んだものを移植するという、何とも中途半端なことをすることになった。

それで改めて昔の文法に沿ってMMLを書いたりなどしたのだけど、やはりMIDIは楽だ。あるいはそれなりによく出来ている。あるいは、違う文化圏のMMLを移植するのはなかなか大変だ。MIDIはトラックがポリフォニックで、かつ複数トラックで1つのチャネルを叩けるのがすばらしい。MIDIではキックドラム、スネアドラム、ハイハットを別々のトラックに記述できるが、YM-2608のリズム音源を叩く音源ドライバで該当トラックがひとつしかなかったら（これが実際に無かったりするわけだ）、それぞれのリズムパターンを融合したMMLを記述しなければならない。これがどんだけ大変なことか...めんどうなので説明は省略させていただきたい。

で、ひとつパート数の多い（15パートくらいあった）、かつ3分以上ある楽曲を、FM6音とSSGまたはPCM3音とリズム音源、の組み合わせに移植する作業を行ったのだけど、あまりにも見込み（移植可能性）が低いと思ったので、まずgoogle docsにスプレッドシートを作って、そこに曲のブロックごとのパートの同時発音数をマトリクスにしてまとめることにした。

まとめてみると、どこの部分が大変でどのパートを削るのが良いかとか、どの部分でチャネルが余るのでエコーチャネルにできるのか（FM音源は音に厚みが無いので、ディレイをかけて周波数を微妙にずらして音量を下げるとそれなりに厚みのある音になる）など、いろいろ戦略を立てて打ち込み（まあこの場合移植だけど）にあたることができて、これは意外と良いアプローチなのではないかと思った。

そんなわけで、今日はもう1曲コピーしてみようかなと思ってアナリーゼ（と呼ぶとなんか違う気もするけど）をやってみた。6分くらいある大曲（打ち込み屋的には）を8全音符のセクションで約25分割、それが現在確認されているだけで20パート弱もあって、マトリクスを全部まとめるだけでも2時間くらいかかってしまった。それぞれがリピートフレーズだったりするので、音さえ作れればそれほどしんどくはないはずだけど。実際に打ち込みに着手する日がちょっと楽しみだ（すぐにやらないつもりなのか）。