Wwise用の汎用グラニュラーシンセサイザーがあれば、それで幅広い種類の音を出すことができ、ゲームでも様々な使い方が予想されるので、私たちはずいぶん前から開発してみたいと思っていました。

私自身、何年か前にNative InstrumentsのReaktor向けにグラニュラーシンセシス風のパッチを作ったことがあります。自分で少し使ってみると思う通りにいかないので、新しい機能を追加しました。そのあとまた、機能を少し増やしました。それから、さらに追加。とやっているうちに、このような結果に...。

ボタンを並べた醜い「壁」（これはReaktorではありません、Reaktorはクールで、これはクールではありません）

グラニュラーシンセシスで生み出せる音の種類が多く、グラニュラーシンセサイザーの開発が有機的に進展しがちなので、機能を次から次へと追加していくうちに、大混乱に陥ってしまうことがあります。

焦点を絞りつつ、柔軟性を確保できるか

オーディオプラグインは、特定の目的を効率的にこなす方が成功する、というのが通説です。例えばCrankcase Revはグラニュラーシンセシスと、とても洗練されたシグナルプロセシングを組み合わせ、車の内燃機関の音をうまく模倣しています。このような音を簡単につくれるように、ユーザーエクスペリエンスやユーザーコントロールの設定も工夫されています。もちろん、私たちはRevがすでに巧みな内燃機関の専用プラグインを作っているので、同じことをしようとは考えませんでした。

焦点を絞ることが肝心だと述べつつ、それに反しますが、私たちはグラニュラーシンセシスを必要とするようなアプリケーションの大半に対応できるプラグインを開発したいと思い、同時に、特定のアプリケーションに特化する必要はないと考えました。できれば、ユーザーが自発的に自分達のアプリケーションと合うような調整を、私たちのグラニュラーシンセシスに対して行うような、クリティカルマスの流れに期待しています。そこで、シンプルな疑問点から踏み出すことにしました。実際に、ゲームオーディオ用のグラニュラーシンセサイザーに人々は何を求めているのか、という疑問です。

最もシンプルなグラニュラーシンセを描いたモックアップ

その後のモックアップ。

ユーザーリサーチ

何でもできて、特に何かの専用でないシンセサイザーを設計しようと努力しているうちに、どうもWwiseユーザーのコミュニティを巻き込む必要がある、ということが明らかになってきました。

そこで「あなたが（従来の）グラニュラーシンセサイザーを（仕事で）何に使いたいですか？」と聞いて回りました。回答例をあげると:

• 「車のエンジン、テキスチャーのあるアンビエンス、転がる音、雨、火」

• 「爆発、破壊、ワンショットの崩壊音」

• 「展開していくアンビエンスベッド、SF、半自然」

• 「不自然で妙な音」

• 「音楽をつくるためのWavetableシンセキャップ」

• 「細かく制御できる、ランタイムのエフェクトやインタラクティブなエフェクトの実装」例えば「モンスターのうろこが皮膚からはぎ取られるときに、モンスターのヒットサウンドを粗く、まばらな音にしたい」時など。

• 「DAWに戻して編集したくなるような、クールなグラニュラーサウンドの生成」

「まだ分からない」と回答した人も多く、使い道がないと答えた人も1人いました！

当然、幅広い分野でユースケースが考えられます。コミュニティとの意見交換は、ユースケース収集で終わったわけではありません。

• グラニュラーシンセシスに関して、デザイン開始前からすでにデザイナー達と私達が交わした文面も、集めてみました。

• 社内のヒアリング調査を行いました。

• 簡単なプロトタイプを開発して、試してくれる人がいることを期待しGDCに持っていきました。

• プロトタイプ第2弾をつくってユーザーに出荷し、彼らの感想や新しいアイディアを聞かせてもらうために、フォローアップのヒアリングを行いました。

• アルファ版を出荷し、さらなるフィードバックをお願いしました。

勉強し、テストし、検証するという長いプロセスとなり、道中、常に貴重な知識を得ることができました。ユーザーが回答してくれた質問や、ユーザーのヒアリング中に話題となったトピックは、主に、

• ユースケース

• ワークフローと、苦労のポイント

• 機能の表示方法について、具体的な質問

• 足りない機能

などについてでしたが、これを超えた内容もたくさんありました！

最初の機能したプロトタイプ（GDC）

ユーザーに送ったプロトタイプ。

Wヒアリング中に出てきた様々な話題について、全て細かく説明したいところですが、この一連のプロセスの感じをつかんでもらうために、1つだけ事例を紹介したいと思います。（次回はあなたも参加してくれるかもしれないので！）

例: Grain Window

あるユーザーが熱望したのはカーエンジンをデザインすることでした。波形の上にウィンドウ枠を表示させ、そこからランダムにグレインをピックアップすることを考えていました。また、このグレインはオリジナルファイルの爆発に対応することが前提でした。ゲーム中に変化する何らかのRPMに紐づけられたRTPCで、ウィンドウ枠自体が動くような計画でした。

グレインの許容されるスタート位置を、ウィンドウやマーカーで表す。 

スタート位置を選択するための特別な"grain window"機能は、この類の使い方には適していても、時間で変化するエフェクトやWavetableシンセなどには向いていません。Positionカーソルにランダムなモジュレータを使えば同じ動作を同様に設定できますが、モジュレーションからこのウィンドウへ変換する方法をイメージとして表現するのは難しく、爆発と同時にグレインが開始されるようにするのは、不可能です。

Alpha版

そこで”Grain Window”のような特別な、カーエンジンのユースケースに適した機能を追加することはやめてしまいましたが、コンセプト自体と、それにまつわるディスカッションのおかげで、Snap to Markers機能や、自動トランジェント検知につながり、Grain Visualization（波形ビューにオーバーレイ表示）がつくられました。これらの機能の方が、対応できるユースケースの数が大きいとみています。こういった機能を使い、Positionの調整を併用し、"grain window"的なものを模倣する方法を、ここで見ることができます。

一方、シンセサイザーで"grain window"をエミュレーションする方法は、ここで説明します。

1. PositionプロパティをRTPCにアサインし、それを、RPMなどの適切なゲームパラメータにバインドします。このRTPCが、マクロウィンドウの左境界線を定義します。

2. Positionプロパティを、Random+のモジュレータにアサインし、一定のAmountを設定します。ここで選ぶAmountによってマクロウィンドウの幅がきまり、設定はファイルのDurationに対して単位%で表します。

3. RPMと共にウィンドウ幅が変わる場合は、RTPCを使い、それをRPMにバインドします。

グレインの開始位置を強制的に、オリジナルサウンドの厳密なポジション、例えば1つ1つの爆発に合わせるには、マーカーを追加し、"Snap to markers"というオプションを利用してください。トランジェントの自動検出機能が時間の短縮につながるかもしれません。

2018.1.4で、見える化されたエンベロープ、grain window、そしてスライダーの下のライブトラッキング

結論として、SoundSeed Grainは開発の最後までユーザーたちから継続的にもらえた貴重なフィードバックに基づいて形づくられたのです。同様に、ユーザー意見をもとに微調整することに成功した機能の具体的な例が、こちらです:

• 画面中央にあるEnvelope Visualizerは、グレインの長さ、エミッション、エンベロープの形などが相互に影響しながら変化する様子をユーザーが理解するのに、不可欠です。

• スライダーフィードバック（各スライダーの下にあるライブモニタリング表示）は、モジュレーションで作業するのに必要です。

Envelope Visualizer

 

リアルタイムのフィードバック付きのスライダー

ユーザーを軸にしたプラグイン開発のアプローチを今後も絶対に続ける予定なので、あなたも次のプラグインに関するディスカッションに参加したければ、是非ここで登録してください！

謝辞

ここで、デザインプロセスに参加してくれた全員の方々にお礼を申し上げたいと思います。 意見や感想を聞かせてくれた私たちの素晴らしいコミュニティ、特にトム・バイブル（Tom Bible）、ニコラス・ボナルディ（Nicholas Bonardi）、マイク・カヴィーゼル（Mike Caviezel）、そしてアンドリュー・クイン（Andrew Quinn）は、私たちが方向性を決める上で大いに貢献して助けてくれました。 

最後に、SoundSeed Grainについての短い動画をご覧ください！