VitalにCC0ライセンスのWavetableを大量に取り込む

DTMテクニック集 Advent Calendar 2022、初日が空いていたのでトップバッターをつとめることにしました。

1月にVitalのウェーブテーブルとして使えるフリー素材を大量にVital用ファイルとして取り込んだリポジトリを作ったので、その話を書きます。CC0ライセンスで誰でも使えます(大量に自作したのではなく、大量のCC0リソースを取り込んだものです)。※ウェーブテーブルのみであって、音色プリセットはありません。

github.com

※今後CC0以外のリソースを取り込んだらライセンスが変わる可能性もあります

以降は「何でこれが必要になったのか」「オープンソース互換で公開できるウェーブテーブルを生成するにはどうすればいいか」を説明します。ユーザーとして使うだけなら、すでにこのリポジトリにあるものをVitalのユーザーディレクトリ(~/.local/share/vital/Userなど)にコピーすればいいだけです(ディレクトリ構成は注意が必要です。README.mdを見てください)。

ちなみにVitalってそもそもどんな音源?という人は、この辺の日本語記事から読むと良いかもしれません。

dtmer.info

VitalのOSS版で使えるプリセットがほしい

ちょっとだけ自分のやっていることを紹介すると、オーディオプラグインフレームワークAndroidで作ろうとしていて(何しろAndroidにだけ存在しないので!)、その関係でオープンソースプラグインをいくつかAndroidに移植して遊んでいます。

去年の今頃、VitalもAndroidでビルドして動かして遊んでいたのですが、すぐに「OSSのVital(GitHubで入手出来るVitalのソースコード)には音色のプリセット(*.vitalファイル)が何も入ってない」ということに気づきました。Vitalのプロプラエタリ版はそこで商売になっているわけですね。無償版(OSS版とは違うことに注意)はその入口というわけです。コードはGPLv3、音色データは商売道具、という切り分けは、フリーソフトウェアと親和的でよくできたビジネスモデルだなと思います。

しかしAndroid版を自作して(GPLv3に基づいて)公開するのであれば、少なくとも配布データとしてプロプタエタリ音色を含めることはできないので、少なくともアプリケーションとして配布するならそれなりの音色プリセットを自作するしかありません。無償版Vitalユーザーがその音色をAndroid版に持ってきて使うのは別に問題ないのですが、わたしが配布するわけにはいかないのです。

これは大変な作業になりそうだ…でも、そういえばVitalはフリーソフトウェア界隈ではVitaliumという(ストアアクセスなどのプロプタエタリな要素を含まない)独自forkがあったはずだけど彼らはどうしているのだろう…その音色データを取り込めば解決では…?と考えましたが、結論からいえば、彼らも特に大した音色プリセットをもっているわけではない、ということでした

さらなる根本的な問題として、Vitalはウェーブテーブルシンセサイザーなので音色プリセットを作るためにはウェーブテーブル音色定義が必要になるわけですが(それをもとにさまざまなパラメーターで音色を作ることになるわけです)、VitalのOSS版にはウェーブテーブルが含まれていません(プロプタエタリなので)。ここから用意する必要があります。

Serum用のウェーブテーブルはフリー素材がたくさんある

ところで、ウェーブテーブル音源は(そういうシンセのジャンルがあることからもわかるように)Vital以外にも数多く存在しますし、その歴史も長いです。Vitalが出現する以前の代表的な音源は概ね異論なくSerumだったと言っていいでしょう。VitalはSerumの機能を数多く取り込んで実現しており、ウェーブテーブルも2048フレームまでのデータを処理できる設計になっています。

ウェーブテーブルは*.wavファイルとして配布されます。サンプリングデータ以外にもデータがいくつかあるのですが、それらはWAVファイルフォーマットの一部であるRIFFヘッダチャンクに含まれます。Serumの情報はclmというヘッダが使われるらしい、ということがあるKVR Forumのスレッドから読み取れます(Xfer Recordsの開発者が自ら書いている情報もあります)。そして、VitalではSerum用のウェーブテーブルを取り込むことができます。このclmヘッダの情報も読み取ります。clmヘッダの情報を取り込めるのはVitalだけでなく、Surgeなどでも可能なので、このジャンルでは概ね共通フォーマットと考えてもよさそうです。

ちなみにVitalのウェーブテーブルは*.vitaltableというJSONファイルになります。サンプリングデータは「JUCEのBASE64文字列」として保存されます。「」が付いているのは、これは標準的なBASE64と互換性が無いためです。

さて、Serum用のウェーブテーブルデータは、実は無料しかもオープンライセンスで大量に手に入ります。 waveeditonline.comにはいろんな人が作ってCC0ライセンスで登録したウェーブテーブルが大量にあります。

WaveEdit Online もうひとつ、kimuratato.comからも大量のウェーブテーブルを ダウンロードできます。日本語でGNU Octaveを使ったウェーブテーブルの作成方法なども公開されています。

vitaltableファイルへの自動変換

WAVファイルとclmヘッダが公知情報なら、その情報をもとにこれらの大量のWAVファイルを自動的に変換するツールを作るのは難しくないはずです…が、実際にはclmの情報をどう取り込むかはVitalの実装次第かもしれないし、前述のJUCE BASE64のような罠が他にもあるかもしれないことを考えると、自前で変換ツールを作るよりも、Vitalのコードベースを使って*.vitaltableに変換したほうが、実装としては安牌です。

そういうわけで、コンバーターは「Vitalのソースに手を加えて一括変換用のコマンドを追加する」というかたちで実装しました。つまり、Vitalのforkとなっています。

github.com

ソースの変更内容はこれだけです: https://github.com/mtytel/vital/compare/main...atsushieno:vital:batch-import-wavetables

プラグインでもよいのですが、make standalone等で実行ファイル版をビルドして起動するのが一番簡単でしょう。ビルドされるのはVialという実行ファイルであることに注意してください(README.mdを読むとわかりますが、Vitalという名称はMatt Tytelのものなので、OSSでは混乱を防ぐためにVialという名前になっています)。ビルドして起動できたら、Wavetableエディタの画面に移動して、メニューを開くと、"Batch Import Wavetables"というVital本家にはないコマンドが出現します。

Batch Import Wavetable

これを実行すると、ディレクトリ選択ダイアログが出現するので、変換元wavファイルを含むディレクトリを指定すると、その下にある*.wavから*.vitaltableが生成されます。

冒頭の繰り返しになりますが、すでにatsushieno/open-vital-resourcesリポジトリで公開されているウェーブテーブルを使用するだけであれば、ここまでやる必要はありません。リポジトリの内容をダウンロードして、Vitalのデータディレクトリ(~/.local/share/vitalなど)にしかるべきディレクトリ構成でコピーするだけです。

あと、もちろんホントにほしいのはWavetableじゃなくて音色プリセットなんですが、これはさすがに一朝一夕では大量には作れないので、どこかから湧いてこないかな〜って思っています(他力本願)

オープンリソースの可能性

最後に与太話を書きたいのですが、わたしがAndroid版をビルドしているのは「どこで音楽を打ち込んでもどこでも再生できる」ような世界を作りたいと思っていることがまあまああります。VitalだけだとOne synth challengeか??みたいな状態になってしまいますが、他にもOSSプラグインはたくさんあるので、さまざまなプラットフォーム上で使えるようになるといい世界になると思いませんか? ふとんにくるまってAndroid端末で音作りして、それをPCに持っていけたり、同じデバイス上でDAWから呼び出せたりしたいですよね。(まあそうは言ってもVitalのUIは現状モバイルでは到底使い物にならないわけですが…!)

ちなみにVitalの公式Discordでは「iOS版とAndroid版を作っている」という情報も見かけたので、別にわたしがやらなくてもそのうち出てくるかもしれません(書いていた人はコア開発者ではなく真偽は不明です)。いずれにしろAndroidにはオーディオプラグインの仕組みが存在しないので、あくまでstandaloneで使えるものということになるでしょう。

FLOSSで音楽制作ツールを作っていると、サンプルやテスト用に楽曲がほしくなるのですが、その音源データがプロプラエタリだと、リポジトリに取り込むにも抵抗があります(不可能だ、と言ってもいいのかもしれません)。そういう場合にはオープンリソースで作成した楽曲データが有用なのです。たとえばわたしは自作MMLコンパイラのサンプル楽曲で著作権の切れたオーケストラ楽曲の打ち込みデータを試験的に公開しているのですが、submoduleにはsfzのフリー音源のみが使用されていて、GitHub ActionsでMP3レンダリングまで実現しています。つまり自分のPC以外でも再現できたということです。

オープン音源リソースのエコシステムが拡大すると、こういうことをやりやすくなるので、この世界がもっと広まってくれるといいなと思っています。