この記事を読み終える頃には、Wwise Authoring API (WAAPI) を使ったことがない方々も興味がわいてくるはずです。

プログラマーでなければ、WAAPIがややこしそうに見えるのも分かりますし、理解しにくいと思うかもしれませんが、少しだけ我慢してください。一緒に（作者の私と、読者のあなたで）あなたの仕事の仕方をガラリと変えられるかも、しれません。

きっと役に立つ情報になりますよ。

Wwise Authoring APIとは？

熱狂的WAAPIファンである自分が、どれほどあなたの助けになれるか熱弁をふるう前に、機能のおさらいです。

Wwise Authoring APIは、Wwise 2017.1と共にリリースされました。名前の通りAPI（Application Programming Interface）なので、ほかのプログラムに影響を与えるコードだという意味です。この場合、対象プログラムはWwise Authoringツールです。

WAAPIはネットワーク経由でWwiseと通信し、情報パケットを送受信します。これを達成する手段として採用した通信方式は、“WAMP” (Web Application Messaging Protocol) というプログラミング言語に依存しないものです。平たく言うと、WAAPIコードを書くのにいくつもの異なる言語が使え、Wwiseとローカルでもネットワーク経由でも通信できるということです。

WAAPIを使えばオーディオファイルのインポートや、Event作成や、広範囲のプロパティ変更や、SoundBanks生成などの作業を自動化できるほか、自分のカスタムGUIをつくることも可能です（自分のミキサーみたいに）。すごくクレイジーな人ならWwiseの複数インスタンスが互いに話せるようにだって、できます。（例えば自分のプロジェクトの旧バージョンと新バージョンを比較したいときなどに。はい、私はやりました。）

かなり気になってきましたか？

そう、私も好きなんだけど、残念ながら、欠点がないわけではないのです。

初心者が感じる弊害

最初にWwiseユーザーに披露されたWAAPIを見たとき、少し面喰いました。このAPIの可能性に私は圧倒され、多少頭を柔らかくして考えるだけで、膨大な数の新しい使い方やワークフロー改善が思い浮かびます。

でもどうやら、ほかのユーザーは....まだまだピンと来ないようです。

Audiokinetichはとても上手にWAAPIの膨大な可能性を説明してきました。でもプログラマー以外の多くの人には、その具体的な意図が伝わりにくく混乱しがちです。WAPPIを新しいWwise機能かな、なんて思っていると、実は自分でカスタム機能を作成するための機能なのです。

そこまで頭の中で理解できたところ、次にAPIドキュメンテーションを開くと、2つのことが起こります。

• 可能性を知り、すごく興奮する。
• プログラミング初心者であれば、大変そうで絶対に使えないと思う。

この2番目が、私は残念でなりません。

例えば、このようなシナリオを考えてみてください:

まず、WAAPIの機能が理解できてくると、早速新しい便利な機能をつくりたいと思うあなたは、超興奮して、例えばSoundBanksをスケジュール通り自動的に生成するツールなどを思いついたとします。

次に、APIドキュメンテーションに突き進みます。最初は単刀直入で読みやすく、とりあえず機能名は理解できます。ところがWAMPサンプルコードのところまでくると、途端に分からなくなります。

そして、やや圧倒されたあなたは、“これはプログラマーの仕事だ！”と考え、先ほど思いついた素晴らしい案件の作成を、手伝ってくれそうなプログラマーに任せることに。

と思ったのら、周りにプログラマーなどいません。失礼。

または、プログラマーはいるけれど、エンジンの大事なバグをフィックスしたり、ゲームユーザー向けの新しい機能をビルドしたりで、忙しいかもしれません。

そうやって、便利に違いないと思ったWAAPIがあっという間にあなたの頭の片隅に追いやられてしまいます。このテクノロジーを使うべき人、是非使いたいと思う人、でもとっかかりのハードルがちょっとだけ高すぎると感じる人が大勢いて、あなたもそう感じてしまいました。

それを、私は変えたいのです。

ハードルを乗り越える

私は自分よりも賢い人たちの助けを借りて、WAAPIをC#で使いやすくするという単純なゴールに向かって動き始めました。

つまり、以下を目指したのです:

• WAMPとJSONを計算式から外し、抽象化（隠蔽）してエンドユーザーから離します。
• WAAPIの使い方を簡単にして、テクニカルサウンドデザイナーやオーディオインプリ担当者がすぐに使え、プログラマーの助けが必要ないか、それほど頼らずにすむようにします。
• 既存WAAPIシンタックスから大きくずれないようにして、ユーザーがオブジェクトのプロパティなどについてWAAPIドキュメンテーションを参照できるようにします（オブジェクトプロパティを網羅したリストあり）。

私は数週間かけてラッパー（wrapper、あなたの代わりにWAAPIと直接やり取りするコード層）である、WaapiCSを作成し、上記がすべて達成できるようにしました。現在、MITライセンス（商用利用、配信、修正が可能で、元の作者として私の名前を記載するだけでいい）で無料提供中で、あなたも今すぐ使えます。ソースのダウンロードリンクは、この記事の文末に掲載してあります。

実際にどのように使えるのかが分かるように、いくつかのコードを並べて比較します。

コールするのはak.wwise.core.getInfo

“ak.wwise.core.getInfo”へのファンクションコールを詳しくみます。Wwiseに送るとWwiseの一般的なデータが返され、例えば稼働中のバージョンや、Wwise .exeへのパスなどが分かります。

ドキュメンテーションで最初に提供されるサンプルプロジェクトコードは、以下のようなものです:

上記の一連のコードは、WaapiCSを使うと、こうなります:

以上です。“ak.wwise.core.GetInfo”をコールするとDictionaryが返され、ループで反復できます。C#プログラミングについて少しでも知っていれば、十分対応できます。

プログラミング用語

使い始める前に、私が何を工夫して、どう使えばいいのかを、具体的に説明したいと思います。もしも、あなたの計画していることが少しでも範囲が広いものであれば、やはりプログラマーの助けを多少お願いした方がいいかもしれません。フレームワークを全く変更するつもりがなければ、おそらくここを飛ばしてもいいと思います。

2つのレイヤ

WaapiCSは、2層構造が念頭にあります。下位レイヤの “WaapiCS.Communication”がWwiseとのWAMP/JSON通信を担当します。次のようなシンプルなオブジェクトで成り立っています:

• Connection – 一回限りのコールを使う場合、Wwiseとの接続を確立させます。
• Subscription – 特定のWwiseコールにサブスクライブして、コールバックを待ちます。
• Packet – ユーザーの引数をすべて含むオブジェクトです。これはWAMP処理の中で送信され、JSONに変換されます。
• Results – すべてのコールバックの結果が含まれる、一般的なC#オブジェクト。Wwiseは様々な種類のJSONを返す可能性があるので、コールバックのあとにJSONから変換するときに、これを特定タイプにキャストします。

“高い”レイヤ（ネームスペース“ak”内）に、ユーザーが目にする実際のAPIがあります。WAAPIシンタックスに近づけるために、どのメソッドも静的です（私の選んだ方式で、WaapiCSは、あとから削除したり変更したりもできるように設計されています）。下位レイヤのpacketオブジェクトは、ユーザーの引数に基づいて構築されます。Wwiseがreturn結果を返した場合、ファンクションコールの終わりにユーザーに返却されます。例えば、このような形になります:

上記は“ak.wwise.core.remote.Connect”へのコールです。文字列の引数は、リモート接続する対象ゲームのホストIPです。残りのコードでパケットオブジェクトの結果をクリアして（すでに使われた場合は）、WAAPIと使うための手順を設定し、パケットにホストIPを追加し、Wwiseがこちらをコールバックするときに使うべきファンクションを宣言してから、Wwiseへ“connection.Execute”経由でパケットを送信します。すべてが終わると、パケットオブジェクトをもう一度クリアにして、次の利用に備えます。このパターンを、APIの各ファンクション経由で同じようにリピートします。

もちろんユーザー対面の静的コールのシステムは、すべてのチームで上手くいくわけでなく、おそらく採用されない可能性の方が高いです。これが理由で、WaapiCSは複数のレイヤで構築されています。下位レイヤはWAMP/JSON経由のWAAPIとの通信が強固なので変更する必要はないはずです。ただし、ユーザーに対面するコードの設定についてあなたのチームの考え方が違う場合は、自由にトップレイヤを完全に削除したり書き換えたりしても、WAMP通信レイヤに影響しません。

使い道は？

一般的に、WAAPIやWaapiCSを使いWwiseオーサリングツールのファンクションを自動化したり、バッチ処理したり、再作成したりでき、例えば以下のように使えます:

• オーディオファイルの大量インポート、EventやSoundBankの作成
• パラメータやバスなどに対する、大規模なプロジェクト変更
• SoundBank生成の自動化、スケジューリング
• Wwiseと様々なプログラムの間の通信
• Wwise Authoringツール用カスタムコントロールインターフェースの作成
• TTS VOのバッチ作成と、Wwiseへの自動インポート

など、多用な可能性があります。

WaapiCSのプルーフオブコンセプトとして、シンプルなカスタムミックスインターフェースを作成してみました。

上図GUIはC#で書かれ、Wwise内にあるどのバスやオブジェクトノードのボリュームでも、コントロールできます。複数の最新デジタルミキシングコンソールをページビューのように表示して、Wwise階層の深くまで入り、たった1つのオブジェクトや上位レベルのミックスバスの設定を、クリック数回だけで調整でき、しかもWwiseをゲームに接続した状態でリアルタイムに行えたら、なんと便利なことか。特定のフェーダー群や、複数のプロパティのスライダーや、複数のAux sendなど、自分だけの「デスクスナップショット」として保存していつでも表示できるようにすることも技術的に可能で、可能性はあなたの想像力の限界まで広がります！

このイメージ図だけではパッとしないかもしれませんが（プロトタイプなので）、かなりすっきりして便利だと思います。あなたも自分の好きな通りに組み合わせたミキサーGUIを、Wwise外に簡単にビルドできます。

なにもプロトタイプ的なC# GUIでなくてもいいのです。あなたが使っているゲームエンジンに簡単に組み込め、UnityでもUnrealでも独自仕様エンジンでも、自由です。OSCにマッピングすれば、WwiseのミキシングをiPadやコントロールサーフェスから直接行える可能性もあります！

WAAPIを活かす

まだあなたも、あなたの所属チームも、WAAPIの機能を利用していなければ、ここまで読んで絶対に使うべきと納得できましたか？  私のWaapiCSは無料で使えるので、作成途中ですが、今すぐにダウンロードし、好きなように手を加えて構いません。商用上の制約もなく、料金も発生しません。

ここで書いたような状況にあなたがいるとして、ツールをつくりたいけれど時間もリソースもない場合は、どうぞ私にご連絡ください！私は新しいクライアント大歓迎なので、Wwiseプラットフォームがあなたにとってさらに使いやすくなるように、協力したいと思います。