VST hostingが上手くいかないの巻

mugeneはまだコンパイラとしてきちんと使いやすくなっているとは言い難い。今のところほぼ自分専用ツールになってしまっている。これはよろしくない。というわけで、ある種のテキスト編集機能をもったGUIと連動して演奏できるようなツールを作ろうと考えた。

しかし、テキストエディタを自作するのはいくら何でも無謀すぎるので、どちらかと言えば「ファイルを登録しておいてボタン1つでコンパイルして再生までやってくれる小物ツール」さえあれば足りると思うようになった。

それならば、どうせVSQもサポート出来ているのだから、vocaloidを同時にkickして同時再生できるようにしてしまいたい。...と思ったところから、今日の話にはだんだん暗雲が立ちこめてくる。

VSTは、そもそもプラットフォーム依存が大きいので（vocaloid自体Windows専用だ）、あまり積極的にサポートする意思は無かった。しかし、vocaloidはCrossoverを使うとwine経由で動かせるようだし、Linuxでもwine 1.2になると動くのではないかという期待が大きい（実のところ1.2RCをインストールしてあるので、必要なDLLさえセットアップすれば確認もできるのだが、まだ試していない）。まあどうせWindows依存になるのは仕方ないので、MIDIと同時に鳴らせたら楽しいだろうと思うことにして、いろいろ実験してみたのだった。

VSTのホストを作成するには、通常であればSteinbergからVST SDKをダウンロードしなければならない（クローズドソース）。これは面倒だ。

というわけで、まず、以前から気にはなっていたVST.NETを使うアプローチを探ることにした。これは本来はVSTを「動かす」ホストを作るためのものではなく、VST（ゲスト）を「作る」ために作られたライブラリなので、今回の目的とはベクトルが違うのだけど、どうやらホスト環境もある程度作られているようだ。そしてさらに、VST.NETは他にあるC#用ラッパーの類とは異なり、Steinbergのコードを必要としない。

というわけでこれを真っ先に試したのだけど、Visual StudioはExpressしか手元にないのに、C#とC++が混在するVST.NETのビルドではまって四苦八苦したのだった。VC++は特に慣れていないというのが結果的には大きかったのだけど。

何とかビルドできるようになって、一部のサンプルのHostを取り込みながら、VSTiを読み込むところまで書いてみたのだけど、これがVocaloid2のdllだと、dllmainなどの読み込みまでは成功するのに、その後でエラーになってしまって先に進めない。VOPMという別のVSTiを試してみたらあっさり読み込んだので、おそらくまだVST SDKのようには完動しないのだろう（と思うことにした）。

それから、仕方ないので公式VST SDKまわりでやっつけられないかと思い、Steinbergのわかりにくい公式サイトから何とかSDKのあるページを探し当てて（外部からもリンク切れだらけで実に到達しにくい）、ダウンロードしてきたのだけど、やはりC++なのでP/Invokeも出来ないし、そもそもラッパーを作る気にもなれず、面倒になってきた。

そんなわけで、とりあえず自分で実装するのはあきらめて、VSTHostとMIDI Yokeを使って、仮想MIDIデバイスに対してPortMidiPlayer...から名前を変えたmanaged-midiのコンソールプレーヤで.vsqファイルをSMFとして再生すれば、普通に出来るんじゃないか...と思いついた。思いついた時はいいhackだと思ったのだけど、調べてみたらVSTHostとMidiYokeは実に一般的なアプローチでいろんな人が試していたようだった。

ともあれまずvsqを生成するところから...と思ったら、生成されたvsqがmanaged-midiで正しく解析されず、しばらくバグ取りをすることになってしまった（生成側の問題だった）。それでvsqをVOCALOID2_Realtime.dllに向けて再生してみた。しかしやはりうまくいかない。VSTHostもMIDI Yokeも（そもそもVST自体）あまり理解しているとは言えないので、この辺は少し調べてみないと分からなそうだ。

なかなか先は遠い...というか、vocaloidは後回しにしてエディタツールだけ作った方が良いような気がしてきた。