【DTM】 VST 3.5 リリース！ということで現状での VST 開発まとめ

備忘録をかねて、たまには DTM の話題でも。といっても開発者視点の話題ですが f^^;

Steinberg の 2 月 10 日の記事によると、VST 3.5 がそろそろ出るみたいですね。SDK のダウンロードも可能。ということで、VST 開発に関する日本語情報が少ないので、（VST 3.5 新機能を含む）まとめ記事を作成してみました。

まず VST (Virtual Studio Technology) とは、一言で言うと DAW ホスト（DTM ソフト）にプラグインの形でソフトウェア音源やソフトウェアエフェクトを追加することができるようにするための規格で、音楽業界でデファクトスタンダードになった Cubase というソフトを作った会社 Steinberg の規格です。ちなみに、ASIO ドライバなんて聞いたことがある人もいるかとは思いますが、これも同じ会社の規格です。Steinberg というと聞きなれないかもしれませんが、実は Steinberg は YAMAHA が最近買収したので経営権は日本にあります。ちなみに、MIDI も日本発の技術で、昔から「音楽業界の標準技術は日本にあり」なんて言われているのは業界では有名な話です。

前置きはさておき、今回は一クリエイターではなく、一開発者の視点から VST 開発全体について情報整理してみます。

まず、VST を開発するには、開発キット SDK を入手する必要があります。無償で公開されており、誰でも入手可能です（要ユーザー登録）。なので、無償の Visual Studio Express Edition 等を組み合わせれば能力次第で誰でも本格的な VST の開発ができます（OOP プログラミング、デジタル音楽の知識、音響物理学、英語と色々必要ですが）。開発言語は C++ で、クロスプラットフォームです（GUI 開発には独自ライブラリの VSTGUI が付属します）。ただ、開発ドキュメント（特に日本語）が少なく、誰かが作ったソースをダウンロードして解析するぐらいしかまともな勉強方法がありません。また、開発者の母数が少ないからか、SDK のドキュメントやサンプルソースも最低限のため、ある程度のトラブルは自力で解決できる経験が要求されます。さらに、音響効果をつけるためにはどのような波形処理を行うべきかといった音響物理の知識がいりますし、VST はリアルタイム処理のため処理に使える時間制限が厳しく、直接メモリ操作を行うような低レベルでのコード記述が要求されるなど、開発難易度は非常に高い部類だと思います。

VST のバージョンに関して。3.5 がリリースされる以前は、VST2 系と VST3 系の２つの規格がありました。VST3 では VST2 に比べ構造が柔軟になりましたが、その分複雑になってしまい、複雑になったわりに有用な機能が少ないことから、結局 VST2 系が現在では広く使われています。VST3 には存在していて、VST2 に無い機能としては、サイドチェーンあたりが有名どころでしょうか。後は、柔軟な構造を活かして音響処理ＰＣと操作ＰＣを分離したりできたりするらしいですが、これは結局 DAW ホスト（DTM ソフト）側に依存するので、特殊な用途向けと言えると思います。

ここに VST 3.5 が投入されることになります。VST 3.5 はこれまでの VST3 系とは独立のようですから、それぞれの系の最新バージョン VST 2.4、VST 3.1 と、今回の VST 3.5 の３規格が存在することになります。冒頭の Steiberg の記事（英語）によると VST 3.5 がリリースされることで、VST 3.0 に乗り換えなかった多くの人が 3.5 に移行することになるだろうと書かれているようですね。VST 3.5 の目玉機能は Note Expression という機能で、記事を読む限り、個々の MIDI ノート（イベント）に「MIDI の枠を超えた膨大なアーティキュレーション情報がついてくる」ことで、開発者にとって無限の柔軟性が生まれる、ということらしいです。記事の例を引用するとすれば、同じ楽器でも例えばピッチカート奏法やレガート奏法、トレモロ奏法を行うことができる楽器において、これまでは奏法ごとにトラック（チャンネル）を分割し、それぞれのトラックで MIDI ノートを入力していましたが、これらを自動的に切り替える機能が Cubase/Nuendo 側で実装され、それに対応したプラグインを開発することができる、ということが挙げられています。後は小さな新機能として XML ベースのパラメータのインポート・エクスポートに対応するとか、ホスト側のコンテキストメニューを作成できたりするみたいです。

うーん、VST 3.5 はどちらかというとエンタープライズ向けの拡張かな…。仕事でやるならともかく、一個人の趣味プログラマーにとってはそこまでメリットなさそう。アーキテクチャも、VST 3.1 の時点で複雑なのに、もっと複雑になってそう。。サンプルも少なそうだし、公式サンプルをちょっと試すだけ試してみて、しばらくは VST 2.4 での開発を続けることにしようかな。

ところでもうすぐ Cubase 6 が出ますね。欲しいけど、Windows 7 専用か。XP がデフォになってるし、どうしようかなぁ…

ニコニコ生放送と Ustream のコメントを統合する Nwhois プラグイン - UniUnifier

…を作ってみました。

今まではブログ記事に乗せていましたが、流れてしまうので独立ページに移動しました。こちらからどうぞ。

Ubuntu 10.04 で C++ が利用可能な環境を整える （g++ のインストール）

Ubuntu 10.04 にはデフォルトで C++ コンパイラがインストールされていませんので、インストール方法の紹介です。

C++ コンパイラをインストールするには、[アプリケーション]-[アクセサリ]-[端末]を起動して、次のようなコマンドでインストールできます。

% sudo apt-get install g++

パスワードを聞かれたら入力し、その後本当にインストールしてよいか聞かれるので、「はい」を意味する y ボタンを押してインストールを実行します。インストールが終わったら、もう既に利用可能になっています。ソースコードのファイル名が "program.cpp" だった場合、次のようなコマンドでコンパイルします。

% g++ program.cpp

このように実行して、何も出力されなかったら正常にコンパイルされています。a.out という実行ファイルが生成されているはずです。もし、No such file or directory のようなエラーが出る場合、作業ディレクトリにソースファイルが存在するか確認してください。

生成された実行ファイル（a.out）は、コロンとスラッシュを頭につけて、次のように実行します。

% ./a.out

ちなみに、はじめからインストールされている C コンパイラは gcc という名前なので、g++ の代わりに gcc を使うと C コンパイラを使うことになります。

Ubuntu 10.04 への OpenGL + GLUT のインストール

Ubuntu 10.04 で OpenGL を利用するためのインストール手順です。OpenGL + GLUT での開発ができる環境を構築します。

まず、ビデオカードのドライバを入れるところから始めます。無くても一応動きますが、ビデオカードによる並列処理が利用できないのでかなり動作が遅くなります。ドライバは GNOME メニューの [システム]-[システム管理]-[ハードウェア・ドライバ] あたりからでも入れられるかもしれないですが、無理な場合はビデオカードのベンダーのホームページに行ってダウンロードし、手順に従ってインストールします。その後おそらく再起動を求められると思うので、再起動します。

次に、OpenGL と GLUT を利用するために必要なパッケージ群をインストールします。Ubuntu ではインストールは基本的に apt が自動的にやってくれます。実は Ubuntu 10.04 では、freeglut3-dev だけをインストール指定すれば、全ての必要な依存パッケージを芋づる式に自動的にインストールしてくれます。OpenGL の最新機能を利用したい場合は、libglew1.5-dev （とそれについてくる依存パッケージ）をインストールすると良いみたいです。ターミナルを開いて、

% sudo apt-get update
% sudo apt-get install freeglut3-dev libglew1.5-dev

あたりでできるはずです。依存パッケージもインストールしてよいかと尋ねられるので、許可します（１回目の sudo コマンドでパスワードを求められるので入力して下さい）。

ここまでできたら、こちらの４章に従ってサンプルプログラムを動かしてみましょう。有名な床井先生の入門ページです。あ、もうインストールは全て終わっているので、２章の「GLUT のインストール」は必要ないですよ。プログラム起動時、ビデオカードのドライバが正常に利用できない場合（あるいは入っていない場合）、３Ｄアクセラレータが使えないよ、という警告をしてくれるようです。

ちなみに床井先生のページの３章のコンパイルコマンドについて、プログラムのソースコードが program.c の時、

% cc program.c -lglut -lGLU -lGL

で動くことを確認しています。

もし動かない場合は、大文字小文字等の打ち間違い注意や、-lglut -lGLU -lGL の順番も揃えた方がいいかもしれません。上で紹介した方法は最小限の構成なので、それでも動かない場合はさらにパッケージ libxmu-dev libxi-dev を追加した後、ライブラリを可能な限り全てリンクすると動くかもしれません。これらは昔必要だったけど、今は必要ない（と思われる）パッケージです。上の作業に加えて、次のようにしてみてください。

% sudo apt-get install libxmu-dev libxi-dev
% cc program.c -lglut -lGLU -lGL -lXmu -lXi -lXext -lX11 -lm -lpthread

もしこれで動作したら、一つずつオプションを減らしていって最小限の構成を調べてみてもいいかもしれません。

# Ubuntu にはＣ＋＋コンパイラが標準でインストールされていないので、Ｃ＋＋を使いたい場合は g++ も入れて下さい。

% sudo apt-get install g++

[XREA] PHP による .htpasswd の生成

今回は apache で会員用ページに認証をかける時、XREA/coreserver のコントロールパネルの .htpasswd の生成ツールと同じパスワードを出力する php スクリプトの紹介です。このスクリプトを使うことで、php のスクリプトで .htpasswd を作成できるようになります。

色々と調査してみたのですが、どうやら XREA/coreserver の .htpasswd 生成スクリプトでは標準 DES を用いているようですね。他の認証方式としては md5 等もありますが、同じ入力文字列に対して得られる出力結果（ハッシュ値）が固定なので、出力結果を比較することで同じパスワードが利用されているかどうかがばれてしまいます。一方、DES には平文に加え、salt（調味料ぐらいの意味？）というパラメータの組で一意の暗号化結果が得られるようになります。これにより、同じパスワードを暗号化しても、その都度 salt を変更すれば同じ出力結果になることを避けることができます。

標準 DES を用いた場合、平文に２文字の salt を与えます。また、出力結果の始め２文字にも salt 自身が示されます。例えば、XREA/coreserver でパスワード "a" を暗号化した場合、

aiDm98/1yAB/6

を得ました。この中の、始めの "ai" が salt に該当し、元のパスワード "a" と、salt "ai" の二つの組み合わせで暗号化すれば上記の "aiDm98/1yAB/6" が得られることになります。

php でこの標準 DES による暗号化を行うには、少なくとも XREA/coreserver 上では、$pass を平文、$salt を２字の文字列として

$r = crypt($pass, $salt);

とすれば、戻り値として暗号化結果が得られます。なお、php の crypt 関数は引数の状態（数や文字数）やオペレーティングシステムによって挙動が違うようなので、他の環境で完全に動作するかは未確認です。以上から、XREA/coreserver の出力結果を PHP からも再現したい場合、

echo crypt("a", "ai");

とすることにより、XREA/coreserver の .htpasswd 生成ツールと同じ結果が得られます。実行してみると、

aiDm98/1yAB/6

きちんと同じパスワードが得られていることが確認できました。

ファイルを一括ダウンロード＆一括ファイル名編集

最近、ある会員用ページで２００曲以上の mp3 データをダウンロードできる権利を手に入れました。ところが、まとめてダウンロードできずに一つ一つリンクが貼ってありました。しかも、そのダウンロードしたファイルが全てローマ字表記で、"hajime.mp3", "tsugi.mp3" といったように非常にわかりにくかった。

番号	タイトル	ファイル名
1	始めの曲	hajime.mp3
2	次の曲	tsugi.mp3
3	三番目の曲	sanbanme.mp3
：

そこで、データを丸ごとダウンロードし、このダウンロードした mp3 をローマ字じゃなくて全部日本語の曲名のファイル名にしたい、というお話。例えば、「hajime.mp3」は「1-始めの曲.mp3」に、「tsugi.mp3」は「2-次の曲.mp3」に変換といった具合。もし数曲程度なら手動で整理した方が早いけれど、３桁もの数の曲データの手動ダウンロードと手動ファイル名修正はいかがなものかと。

とりあえず、ファイルの一括ダウンロードはすぐにできそうなので、ダウンロードツールを探しました。

あ…会員ページにログインする機能のないダウンロードツールは利用できないんだった。。そこで、Firefox のアドオンで、表示されているコンテンツを丸ごとダウンロードできる DownThemAll をインストールしてデータを一括ダウンロードしました。

ダウンロード設定。しばらく待つと、全部のファイルが無事ダウンロード完了。

さて、次はファイル名編集。幸い、HTML のテーブルの形でデータが整理されてたので、HTMLのソースから該当のテーブル部分を抜き出して、XML パーサにかけたらできそうですね。HTML の元のソースから table タグを見つけて抜き出し、拡張子 XML で保存。

ブラウザで開いてみると…構文エラーが発生。

エラー： invalid attribute value
<td width=5%>

…そうか、XML の構文はかなり厳格で、属性値にダブルクォーテーションがないとか、閉じ括弧があらゆるタグについてないとエラーになるとか、色々あったんですね。HTML 構文はそのあたり適当でもブラウザが適宜解釈してくれるんだけど、XML ではそうは行かない。HTML を XML に変換するのに躓くのは想定外というか、そういうことがあったって忘れてた。

そこで、このあたりを修正できるツールを探していると、Tidy というツールを発見。XML ドキュメントのエラーを探して自動で修正してくれるツールみたいです。早速 Windows 版をインストールして試してみる。

お…文字化けで肝心の日本語を変換できず…。あれこれ他のページを探してみるとこのページを発見！

http://html.idena.jp/program/index.shtml

このツールを使うと、無事に XML 構文が修正されて、XML として読み込むことができました。

ちなみに、Linux にても Tidy は利用できました。文字コードを UTF-8 にしておいて、次のコマンドを使いました。

% tidy -utf8 -asxml input_file > output_file

ただし、この方法で生成した出力ファイルには１つ問題がありました。&nbsp; が存在した場合、これは XML で定義されていないためにこの後使う expat でエラーになるようです。あまり綺麗ではないのですが、結局ストリーミングエディタを使って無理やり矯正してみました。

% sed -e 's/&nbsp;/ /g' output_file2 > out.xml

さて、この XML を構文解析して、ファイル修正スクリプトを組む必要がありますね。XML パーサだったらどこにでもあるだろう。なんとなく、python で作る方法を調べる。xml.parsers.expat あたりが軽量で使いやすそうなことがわかったので、このあたりを使うことにした。

…ソースを載せようと思ったけど、よく考えたら会員じゃない人は試せないわけね。雰囲気だけ載せときます。

#!/usr/bin/python
# coding: utf-8

import sys
import os
import xml.parsers.expat

# XMLファイルをパース
def parseDocument(p, file):
    f = open(file, 'r')
    p.ParseFile(f) 
    f.close()

# 要素の開始（<td> とかのときに呼ばれる。attrs には td の属性値）
def start_element(name, attrs):
    # if name == 'td': とかの処理

# 要素の終了（</td> とかのときに呼ばれる）
def end_element(name):
    # if name == 'td': とかの処理

def char_data(data):
    # data に値が入る

# パーサの作成
p = xml.parsers.expat.ParserCreate()

# ハンドラの設定
p.StartElementHandler = start_element
p.EndElementHandler = end_element
p.CharacterDataHandler = char_data

# table.xmlをパース
parseDocument(p, 'table_new.xml')

ここまで結構長かった。。

Python のリダイレクトでエラー？

普通に動いている Python のプログラムをリダイレクトしたらエラーが...

codeEncodeError: 'ascii' codec can't encode characters in position 2-9: ordinal not in range(128)

調べてみると、どうやら内部仕様からこのエラーが出てくるようですね。出力文字コードに ASCII 以外の文字が含まれる時は何かにエンコードする必要があるようです。標準出力の時のみ自動でＯＳの利用している文字コードにエンコードしてくれるのでエラーが出ませんでしたが、リダイレクト時には何にエンコードしたらいいのかわからずエラーが出たようです。

str = u"あ"
print str.encode(sys.getfilesystemencoding())

で解決するようです。

...どうでもいいですが Python って便利って聞いてますがですが、文字コード周りは面倒ですね...。