楽譜ファイルのコンパイラを実装した
独自のサウンド記述用言語を作成
前回 の XAudio2 の問題はとりあえず置いといて、サウンドの制作に使う独自言語の定義とそのコンパイラをここ2日ほどかけて実装していた。
こんな感じの言語。テキスト形式で記述できる。
; ';'から行末まではコメント @0 ; 音色は0番 v128 ; 音量 ; ドレミファソラシドの音階 cdefgab>c
なんか MML を触っていた経験が色濃く出ていますね。
言語なんて自作しなくても、ほかにやりようあったろ…
うーん… それなあ。
まず、wav の埋め込みを考えたが、どうあがいてもサイズがデカくて断念した。趣味でやる以上、リリースするバイナリは 5MB 以内に収めたいというこだわりがあるんだ。
ogg も候補に挙がったがなんかややこしかったし…。wav ってバイナリ構造がすごく素直で扱いやすいじゃない? それに、結局のところサイズ面では楽譜ファイルには敵わない。
というわけで、
- wav ファイルの扱いやすさ
- ファイルの軽さ
- 音声の再現性の高さ
という点を考慮すれば、「楽譜を表現する独自の言語を定義する」という選択に行き着くのは至極当然のことではなかろうか?(狂気)
これを数時間で可能にしてしまったD言語の書き易さが悪いんや…
あとは、音色を用意し、コンパイルした楽譜バイナリを波形データに変換すれば、どんなサウンドも奏で放題だ。
楽譜コンパイラとD言語の unittest
話題は変わるけど、コンパイラみたいに入力と出力がはっきりしていて、外部への依存がないものはユニットテストが書きやすくていいな。
今回の楽譜コンパイラなんて、ファイル入出力を除く部分に関しては(筆者のコードにしては珍しく)カバレッジ 100% を記録した。
ユニットテストがあると、自信をもってリファクタリングできるので本当にありがたい。
もっとも、カバレッジが必ずしも品質の指標になるわけではないが、コードをいじる際に少なくとも既存の動作を壊していない確信は持てるのでだいぶ気が楽である。あと、数か月後の自分への最高の仕様書になる。
ちなみに、D言語で unittest
のカバレッジを計測するには以下のような dub コマンドを打てばいい。簡単。
dub test -b=unittest-cov
成功すると、カバレッジが記録された .lst
という拡張子のファイルがプロジェクトフォルダに出力されるはず。
このように、特別なライブラリ不要で、組み込みのユニットテストが書けるというのも筆者がD言語を気に入っている理由の一つだ。
あとすべきこと
次は波形コンバータを書けばOKだな。
よしよし順調順調。
この調子でこつこつやっていこう。
ライセンス表示
- 記事タイトル画像
- "Piano Music Score Music Sheet Edited 2020" by chocolatedazzles is licensed under CC BY 2.0