Author: Philipp Kotecki

Eines der bekanntesten Frameworks für die Entwicklung von digitalen Audioanwendungen und Audioplugins ist das JUCE-Framework. Das ist ein Framework, das speziell für die Programmiersprache C++ verfasst wurde. Es kann wie ein Werkzeugkasten betrachtet werden, mit welcher Audioanwendungen relativ einfach erstellt werden können, weil viele Lösungen für die Programmierung von DSP-Effekten bereitgestellt werden. Außerdem wird auch der rein technische Teil, wie das Erkennen von Treibern, die Kommunikation mit Wandlern usw. ebenfalls vom JUCE-Framework übernommen, womit sich der Entwickler der digitalen Klangverarbeitung widmen kann. Zusätzlich werden noch graphische Elemente zur Verfügung gestellt, welche die Interaktion zwischen Endbenutzer und Audioeffekt erleichtert bzw. überhaupt ermöglichen.
Als Alternative zu JUCE gibt es Steinbergs VST SDK und VSTGUI, welche älter sind, aber nicht so häufig geupdatet werden.

Neben dem, dass JUCE ein Framework ist, wird auch eine praktische Anwendung namens Procujer mitgeliefert. Das ist eine Oberfläche, mit welcher neue Projekte angelegt werden können. Es gibt eine Auswahl an Templates für unterschiedliche Projekttypen, wie z.B. standalone Audioanwendungen, VST-Plugins, reine Graphik-Anwendungen oder simple Konsolenanwendungen. Mit diesen Templates werden vorab erstellte Code-Fundamente geladen, welche mit eigenem Code gefüllt und erweitert werden können.

Für die Verwendung von VST-Plugins wird ein Plugin-Host benötigt. Das ist in der Regel eine DAW wie Cubase, ProTools, Ableton usw.. Normalerweise müsste bei der Entwicklung von Plugins immer eine solche DAW neu geöffnet und dabei der Plugin-Ordner gescannt werden. JUCE ermöglicht das Testen eigens erstellter Plugins mithilfe eines eigenen Plugin-Hosts, welcher virtuelle Audio- und MIDI-Inputs und Audio-Outputs bietet.

Für den Einstieg in JUCE gibt es auf der Website des Herstellers mehrere Tutorials zur Programmierung von kleinen Audio-Anwendungen. Auch werden allgemeine Konzepte des Digital Signal Processings (DSP) erklärt, was die Vorraussetzung ist bei der Erstellung digitaler Audioanwendungen. Zusätzlich wird eine umfangreiche Dokumentation mitgeliefert, welche alle einzelnen Bausteine des Frameworks erläutert.

Quellen:
https://docs.juce.com/master/tutorial_create_projucer_basic_plugin.html

https://juce.com/learn/tutorials

https://docs.juce.com/master/index.html

https://steinbergmedia.github.io/vst3_doc/vstsdk/index.html

https://steinbergmedia.github.io/vst3_doc/vstgui/html/

Titel
Theoretische Planung und messtechnische Evaluierung eines Hallraumes

Hochschule
Technische Universität Graz

Betreuer
Dipl.-Ing. Herbert Hahn

Begutachter
Ao. Univ.-Prof. Dipl.-Ing. Dr. Gerhard Graber

Autorin
Jamilla Balint

Datum
März 2014

Gestaltungshöhe
Die Gestaltung dieser Diplomartbeit ist, wie bei vielen Arbeiten, die sich mit technischen Themen außeinandersetzen, eher schlicht und übersichtlich gehalten. Die Schriftart und die vielen Formeln deuten daraufhin, dass diese Arbeit mit LaTeX verfasst wurde.

Innovationsgrad
Das Thema an sich ist nicht besonders innovativ, da sie zur täglichen Arbeit eines Akustikers zählt. Interessant ist allerdings der Aufwand der betrieben wurde, um verschiedene Messpositionen und Szenarien zu bewerten. Daraus ergeben sich Erkenntnisse, die man in der Realwirtschaft und in der praktischen Berufswelt nur schwierig bekommen würde.

Selbstständigkeit
Die Autorin schreibt die Arbeit vollständig selbständig. Auch die praktischen Simulationen, Messungen und Auswertungen werden selbstständig erledigt. Lediglich der Hallraum wird von der TWB Buch GmbH zur Verfügung gestellt.

Gliederung und Struktur
Die Gliederung und Struktur ist meiner Meinung nach gut gelungen und folgt einem logischen Aufbau. Zunächst werden die theoretischen physikalischen Grundlagen geklärt, dann wird die Software zur Simulation des Hallraumes vorgestellt. Anschließend folgt die praktische Simulation und die Messung mit einer Gegenüberstellung und Bewertung der Ergebnisse.

Kommunikationsgrad
Die Thematik ist für einen Laien schwierig zu verstehen und geht tief in die Materie. Ohne physikalischen bzw. technischen Vorkenntnissen tut man sich schwer das Geschriebene außerhalb des Abstracts zu verstehen. Mit Vorkenntnissen hingegen lässt sich das Geschriebene gut nachvollziehen.

Umfang der Arbeit
Die Arbeit ist mit einer Gesamtlänge von 113 Seiten eher lang, allerdings nehmen die physikalischen Formeln, Abbildungen und Tabellen auch viel Platz in Anspruch. Auch ist der Umfang angemessen für den praktischen Aufwand und die Komplexität des Themas

Orthographie sowie Sorgfalt und Genauigkeit
Beim Lesen der Kapitel sind mir im groben keine grammatikalischen als auch orthographischen Fehler aufgefallen. Im Quellenverzeichnis sind mir allerdings Fehler wie “Sringer-Verlag Berlin” statt “Springer-Verlag Berlin” oder aber auch “Taschenbuch der Technichnischen Akustik” statt “Taschenbuch der Technischen Akustik” aufgefallen.

Literatur
Die meiste Literatur basiert auf anerkannter Fachliteratur. Allerdings findet man auch einige Referenzen zu Studienarbeiten (Diplomarbeiten, Bachelorarbeiten) der TU Graz. Ob diese den wissenschaftlichen Standards entsprechen, um in einer Diplomarbeit zitiert zu werden ist, müsste überprüft werden. Da wissenschaftliche Quellen bei so speziellen Themen oft rar sind, wird die Autorin wohl aus diesem Grund aus anderen Studienarbeiten zitiert hat. Die Literatur, mit welcher die Autorin arbeitet, ist überwiegend aktuell, wobei auch einige ältere Werke aus den letzten Jahrzehnten vorkommen. Da ich selber Akustiker bin, kann ich aus eigener Erfahrung sagen, dass in der Akustik im Laufe der Zeit neue Erkenntnisse hinzukamen. Diese bauen aufeinaner auf, statt alte zu widerlegen, weshalb ältere Werke im wesentlichen nicht an Relevanz verloren haben.

Quelle:

https://www2.spsc.tugraz.at/www-archive/downloads/DA_Balint_final.pdf

Im Bau und Konzeption von Regieräumen haben sich unterschiedliche Konzepte zum Umgang mit Reflexionen ausgehend von den Lautsprechern entwickelt. Besonders populär ist das sogenannte “Live-End, Dead-End“-Konzept (kurz LEDE). Dieses wurde Ende der 70er Jahre von Don und Carolyn Davis vorgestellt und in den darauffolgenden Jahren häufig umgesetzt. Aus eigener Erfahrung als Studioplaner kann ich sagen, dass Konzepte dieser Art ein wenig an Bedeutung verloren haben, weil Studios heutzutage eher funktional gebaut werden. Allerdings muss dazu gesagt werden, dass durch den massiven Rückgang der Verkäufe von Tonträgern auch die Budgets für teure Studiokonzepte und -umsetzungen fehlen.

Das LEDE-Konzept wurde unter der Beachtung psychoakustischer Effekte, wie dem Haas-Effekt und dem Richtungshören entwickelt. Dabei ist die Grundidee, dass der Regieraum in zwei Hälften geteilt wird. Der vordere Teil des Raums (Dead-End), wo sich auch die Lautsprecher befinden, ist komplett mit absorptivem Material verbaut, während die zweite Hälfte (Live-End), also die Rückwand und ein großer Teil der Seitenwände und Decke komplett reflektiv ist. Das Ziel ist es einen Direktschall zu erhalten, der sich hinsichtlich Prägnanz, Lautstärke und Zeit deutlich von den Erstreflexionen unterscheidet. Dazu wird die “Live-End”-Seite diffus gestaltet und der Schall so gestreut, dass man keine harten, diskreten Einzelreflexionen hat, welche den Klang zu sehr färben. Außerdem soll der Raum durch diese Maßnahme lebendiger und natürlicher klingen als typische Regieräume, die überwiegend mit Absorption bedämpft werden.
Um dieses Konzept noch zu optimieren, werden die Lautsprecher in die Frontwand eingebaut, sodass die kugelförmige Abstrahlcharakteristik tiefer Frequenzen unterbunden wird. Damit bleibt der vordere Teil des Raumes komplett reflexionsfrei.

Es gibt aber auch den Ansatz Tonregien genau andersrum zu gestalten. In diesem Fall wird der vordere Bereich reflektiv gebaut und die Rückseite absorptiv. Dabei werden potentielle Erstreflexionen von der Rückwand und den Seitenwänden absorbiert.

Welches Konzept sinnvoller ist, ist in vielen Fällen eine Frage des Geschmacks und des gewünschten Höreindrucks. Erst durch das längerfristige Arbeiten in beiden Arten von Räumen kann ein eigenes Urteil gefällt werden.

Quellen:

Philip Newell. 2012. Recording Studio Design. Third Edition. S. 391 ff.

https://www.soundonsound.com/techniques/sos-guide-control-room-design

Um das Abklingverhalten eines Raumes zu beschreiben, wird der Begriff Nachhallzeit verwendet. Dieses bezeichnet die Zeit, in welcher ein Schallpegel um 60 dB abnimmt, nachdem die Schallquelle abgeschaltet wurde. Die Nachhallzeit ist dabei abhängig von der Raumgröße, der Raumgeometrie und der Oberflächenbeschaffenheit von Wänden, Böden und Decken. Nachhallzeiten verhalten sich im Frequenzspektrum nicht gleich, sondern unterscheiden sich, abhängig vom Oberflächenmaterial von Räumen, teilweise stark. Häufig brauchen tieffrequente Schallanteile länger um abzuklingen als hochfrequente.

Nachhallzeiten können zum einen gemessen, zum anderen aber auch berechnet bzw. simuliert werden, wenn die wesentlichen Variablen bekannt sind.
Zur Berechnung der Nachhallzeit finden in der Praxis zwei Formeln Verwendung. Die Eyring’sche und die Sabine’sche Formel.

Für eine Nachhallzeitenkalkulation nach Eyring wird das Volumen des Raumes V und die gesamte Absorptionsoberfläche A benötigt. Letztere wird durch Addition der einzelnen Absorptionsoberflächen, die sich wiederum aus der Multiplikation der jeweiligen Absorptionsgrade α und der Oberflächengröße der unterschiedlichen Oberflächenmateriale ergibt, berechnet.

Daraus kann der mittlere Absorptionsgrad α des gesamten Raums berechnet werden. Dafür die gesamte Absorptionsfläche A mit der Gesamtoberfläche des Raumes S_ges dividiert.

Mit diesen Variablen kann nun die Nachhallzeit nach Eyring berechnet werden. Hinzu kommt die Energiedämpfungskonstante. 4mV beschreibt die Absorption von Schall im Medium Luft. Bei kleinen Räumen und nicht zu hohen Frequenzen ist diese allerdings vernachlässigbar.

Schwach bedämpfte Räume, also Räume mit einem mittleren Absorptionsgrad von α < 0,25 werden mit der vereinfachten Formel von Sabine berechnet.

Die Nachhallzeit wird nun für jedes einzelne Frequenzband (in der Regel Terz- oder Oktavbänder) berechnet, um ein frequenzunabhängiges Verhalten der Nachhallzeit bestimmen zu können. Solche Kalkulationen werden vor allem bei der Planung von Gebäuden insbesondere von Konzerträumen, Tonstudios oder Konferenzräumen benötigt, um richtige Entscheidungen bezüglich der Innenausstattung und der Auskleidung von Oberflächen treffen zu können.

Quellen:

https://www.soundandrecording.de/tutorials/studioakustik-die-nachhallzeit-im-studio/

Der Choreograph und Tänzer Merce Cunningham gründete 1953 die Merce Cunningham Dance Company, die eine große Rolle in der Welt der performativen, modernen Kunst spielten. Weltweiten Erfolg erlangte die Tanzgruppe vor allem 1964 bei der sechsmonatigen Welttournee. Die Merce Cunningham Dance Company gab bis 2011 Aufführungen. 2 Jahre zuvor ist Merce Cunningham im Alter von 90 Jahren verstorben.
Die Werke der Tanzgruppe beinhalten eine Kombination verschiedener Medienformen, wie Fotografie, Film, Klang und natürlich der Live-Performance. Für dieses Projekt waren John Cage und David Tudor involviert als Komponisten. Die Kompositionen David Tudors für die Tanzgruppe basieren vor allem auf der Verwendung experimenteller elektronischer Elemente.

Eine der bekanntesten Werke, das David Tudor für die Merce Cunningham Dance Company vertonte, ist das im Jahre 1968 veröffentlichte “RainForest”. Für das Bühnenbild wurde Andy Warhols Installation “Silver Clouds” verwendet. Das sind silberne, mit Helium gefüllte Kissen, die in der Luft hängen und zufällig angeordnet sind. Während der Aufführungen verhielten sich die Kissen oft unberechenbar. Im Werk “RainForest” gibt es an sich keine Handlung, die Dramaturgie wird stattdessen durch die gesamte Atmosphäre geschaffen. Die Musik besteht aus elektronischen Klängen, Vogelgezwitscher und anderen Klängen von Tieren. Auch wurden verschiedene Objekte wie Tassen, Krüge, Vasen usw. zur Generierung von Klängen verwendet.

David Tudor komponierte zum einen die Musik für einige Werke, gleichzeitig entwickelte er aber auch Systeme, die das interaktive Zusammenspiel der Tänzer mit der Musik ermöglichten. Im Werk “Variations V” entwarf Tudor zusammen mit Cage ein System, das den ausführenden Tänzern mithilfe von Lichtschranken ermöglichte, unterschiedliche Klangerzeuger zu steuern. Zusätzlich wurden Antennen auf der Bühne verteilt, die weitere Klänge steuern und manipulieren, sobald die Tänzer sich den Antennen nähern. Desweiteren wurden alle Requisiten elektronisch vernetzt, sodass auch diese Klänge generieren konnten. Damit wollten Tudor und Cage das standardmäßige Verhältnis, bei welchem der Tanz auf Musik folgt, aufbrechen und die Musik abhängig vom Tanz machen.

Weitere Werke:

Quellen:
https://www.staatsoper.de/biographien/cunningham-merce

https://www.faz.net/aktuell/feuilleton/buehne-und-konzert/merce-cunningham-dance-company-es-war-einmal-in-amerika-11576852.html

http://www.see-this-sound.at/werke/189.html

https://www.mercecunningham.org/the-work/choreography/rainforest/

In meinem letzten Blogeintrag habe ich das grundlegende Prinzip der Soundengine von Unity, die auf der Verwendung von Audio Listenern und Audio Sources basiert, vorgestellt. Die Wwise-Soundengine arbeitet auf dem selben Prinzip und hat standardmäßig bereits vorhandene Skripte mit welchen die selben System realsiert werden können. Diese Skripte heißen AkAudioListener und AkGameObj. AkAudioListener ist der Wwise-Ersatz für den Audio Listener von Unity.

Ist die Position und Blickrichtung eines GameObjects notwendig, was bei den meisten diegetischen Klänge einer dreidimensionalen Spielwelt der Fall ist, muss dieses GameObject auch als ein solches in Wwise registriert werden. Dafür gibt es das AkGameObj-Skript, das auf alle GameObjects gelegt wird.

Das GameObject, das als Main Camera dient und auf welchem das AkAudioListener-Skript liegt, muss ebenfalls mit einem AkGameObj-Skript versehen werden, weil auch dessen Position und Blickrichtung notwendig ist, um den Abstand und die Richtung zu anderen GameObjects berechnen zu können. In Wwise kann das Verhalten des Richtungshörens und auch des Pegelabfalls bei steigernder Distanz von Audio Listener zu klangerzeugenden GameObject (wie der Rolloff in Unity) konfiguriert werden.

Das AkGameObj-Skript kann zusätzlich auch noch andere Parameter aus dem Spiel übermitteln, wie Switches, RTPCs oder Umgebungsinformationen.

Reverb Zones werden Wwise mithilfe von Aux-Bussen realisiert, mit welchen innerhalb von Wwise ein Hall-Effekt zum Direktsignal hinzugemischt wird. Tatsächlich können auch andere Effekte statt Hall-Effekte verwendet werden. Das hierfür benötigte Skript ist das AkEnvironment-Skript, welches auf einen Collider gelegt wird. Im Inspector des Collider-GameObjects kann ausgewählt werden, welcher Aux-Bus aktiviert werden soll, sobald der Collider betreten wird.

Dabei ist wichtig, dass das GameObject, wie z.B. der Audio Listener (also die Main Camera) im AkGameObj so konfiguriert wird, dass diese auf AkEnvironment-Skripte reagieren und damit ein Signal an den jeweiligen Aux-Bus senden.

Quellen:

[1] https://www.audiokinetic.com/courses/wwise301/?source=wwise301&id=Audio_Listener

[2] https://www.audiokinetic.com/library/edge/?source=Unity&id=class_ak_audio_listener.html

[3] https://www.audiokinetic.com/library/edge/?source=Unity&id=pg__wwise_components.html

[4] https://www.audiokinetic.com/library/edge/?source=Unity&id=class_ak_game_obj.html

[5] https://www.audiokinetic.com/library/edge/?source=Unity&id=unity_use__ak_environment__ak_environment_portal.html

Eines der grundlegenden Prinzipien der Soundwiedergabe in der Gameengine Unity ist das Zusammenspiel aus sogenannten Audio Listenern und Audio Sources. Auf diesem Prinzip basieren alle mit Unity entwickelten Spiele und Klangrealisierungen. Man muss sich ein Spiel ein wenig, wie einen Film vorstellen, bei welchem der Regisseur (oder aber der Spieleentwickler) genau festlegt, was der Spieler sehen kann und was nicht. Zwar hat der Spieler viel mehr Freiheiten als im Film, aber im Grunde ist es ein ähnliches Prinzip. Auf visueller Ebene wird eine Kamera genutzt, die der Spieler lenken kann. Diese wird oft Main Camera genannt und ist oft an die eigene Spielfigur in der ersten oder dritten Person gebunden. Gesehen werden können alle GameObjects die im Blickwinkel der Kamera sind und mit sichtbaren Texturen belegt sind.

Ähnlich verhält es sich auch auf klanglicher Ebene. Analog zum Visuellen kann man Audio Listener als die Main Camera sehen und Audio Sources wie visuelle GameObjects. Tatsächlich ist der Audio Listener in den meisten Fällen mit der Main Camera verknüpft und Audio Sources mit den GameObjects, die Sound erzeugen. Der Audio Listener ist quasi ein Mikrofon, der Signale von Audio Sources erhält und weiter an die Audioausgänge schickt. In Unity kann es standardmäßig nur einen Audio Listener geben.

Audio Listener empfangen also Signale von Audio Sources, welche aber noch durch Effekte, wie z.B. einen Hall, geschickt werden können, wenn der Audio Listener sich in einer sogenannten Reverb Zone befindet. Reverb Zones sind kugelförmige GameObjects, die ein bestimmtes Gebiet umfassen und nach Eintreten des Audio Listeners den Anteil des Halls hinzumischen, je nachdem, wie nah sich der Audio Listener am Zentrum der Reverb Zone befindet.

Audio Sources können auf zwei Arten implementiert sein: 2D und 3D, diese können mit dem Spatial Blend-Regler reguliert werden.

2D bedeutet, dass sowohl Abstand als auch Richtung zum Audio Listener nicht relevant sind und der Sound unabhängig davon abgespielt wird. Der Sound, außer er wird im Unity-Mixer oder im Inspector des selben GameObjects noch weiter bearbeitet, wird so wie er ist abgespielt. Das wird vor allem für Soundtracks oder klangliche Hintergrundkulissen, wie Atmo-Aufnahmen, verwendet.

3D hingegen setzt einen Sound Source in die dreidimensionale Spielwelt und erlaubt Richtungshören und zugleich variable Pegel, je nach Abstand des Audio Sources zum Audio Listener. Das Richtungshören wird ermöglicht, indem das ausgehende Audiosignal in ein Monosignal gewandelt wird und durch Pegelunterschiede ein Panning erhält. Es gibt zwar auch Lösungen für komplexere Surround-Sound-Verfahren, aber standardmäßig arbeitet Unity nur mit dieser vereinfachten Form, welches das Richtungshören ermöglicht. Von den verschiedenen 3D-Konfigurationsmöglichkeiten ist vor allem der Rolloff von großer Bedeutung. Damit lässt sich bestimmen, wie der Pegel, je nach Abstand zum Audio Listener, abfällt. Standardmäßig verwendet man entweder einen logarithmischen oder einen linearen Rolloff. Alternativ kann auch ein eigener, händisch eingezeichneter, Rolloff erstellt werden. Zusätzlich bestimmt man noch die Parameter Min Distance und Max Distance. Diese markieren einen Bereichen, in dem der Audio Listener sich befinden muss, um den Audio Source hören zu können und in welchem der Rolloff sich abspielt. Ist der Audio Listener außerhalb dieses Bereichs, wird das Signal nicht an diesen weitergegeben und folglich wird das Signal auch nicht abgespielt.

Quellen:

[1] https://docs.unity3d.com/Manual/class-AudioListener.html

[2] https://docs.unity3d.com/Manual/class-AudioReverbZone.html

[3] https://docs.unity3d.com/Manual/class-AudioSource.html

[4] https://docs.unity3d.com/Manual/AudioSpatializerSDK.html

[5] https://docs.unity3d.com/Manual/AmbisonicAudio.html

Neben der Nutzung vorgefertigter Skripte, die für die Implementierung von Wwise in Unity mitliefert sind, gibt es auch die Möglichkeit eigene Skripte bzw. eigenen Code zu schreiben, um Befehle an Wwise zu senden. Der Vorteil davon ist, dass man ganz genau bestimmen kann, an welcher Stelle Befehle an Wwise übermittelt werden sollen. Viele Funktionen werden außerdem von den mitgelieferten Skripten nicht abgedeckt und müssen deshalb selbst erstellt werden. Häufig muss z.B. ein Sound abgespielt werden, wenn ein Spieler eine Taste betätigt oder etwas im Spiel geschieht, was nicht mit Triggercollidern zu tun hat.

Für das Implementieren von Wwise in Unity mittels Skripte gibt es grundsätzlich zwei Möglichkeiten: Die direkte Hardkodierung eines Befehls oder die Kodierung mithilfe von Wwise-Types, die im Unity-Inspector einen Property Drawer anzeigen, mit welchem man Wwise-Objekte (Event, State, Switch usw.) auswählen kann.

Jeder hardkodierte Befehl beginnt mit dem Begriff AkSoundEngine, der quasi eine Information für Unity darstellt, dass ein Wwise-Objekt aufgerufen werden soll. Daraufhin wird bestimmt, welche Wwise-Funktion ausgeführt werden soll. Eine der grundlegendsten Funktionen ist “PostEvent” für das Aufrufen eines Wwise-Events. Desweiteren gibt es noch die Funktionen “setState” bzw. “setSwitch” zum Bestimmen eines States bzw. Switches, “setPosition“, damit Wwise die Position eines GameObjects bekommt, was für die korrekte dreidimensionale Wiedergabe von diegetischen Sounds benötigt wird, “setRTPC“, mit welchem Parameter aus dem Spiel an Wwise übermittelt werden und viele weitere Funktionen, die in der Wwise-Dokumentation nachgeschlagen werden können.
In den runden Klammern wird immer der Name des Wwise-Objekts als String mit angegeben. Manchmal werden noch andere Argumente benötigt, wie das GameObject, von dem der Befehl ausgeht.

Alternativ dazu kann man auch mithilfe von Wwise-Types Implementierungen realisieren. Dazu wird zunächst eine Variable mit einer Wwise-Type-Klasse initialisiert. Wwise-Type-Klassen sind die verschiedenen Arten von Wwise-Objekten. Das ist z.B. AK.Wwise.Event für Wwise-Events, AK.Wwise.State für Wwise-States und viele andere. Auch alle Wwise-Type-Klassen können in der Wwise-Dokumentation nachgeschlagen werden.

Daraufhin kann im Unity-Inspector im Property Drawer des Skripts das jeweilige Wwise-Objekt, welches im Wwise-Editor angelegt ist, ausgewählt werden.

Nach der Initialisierung wird die Variable in einer Funktion im Skript aufgerufen. Dabei wird die Variable mit der jeweiligen Wwise-Funktion aufgerufen, wie z.B. “Post()” bei Wwise-Events oder “SetValue()” bei RTPCs, States oder Switches.

Quellen:

[1] https://www.audiokinetic.com/courses/wwise301/?source=wwise301&id=Posting_Events_using_WwiseTypes#read

[2] https://www.audiokinetic.com/courses/wwise301/?source=wwise301&id=Creating_a_WwiseType_Event_property#read

[3] https://www.audiokinetic.com/library/edge/?source=SDK&id=waapi_functions_index.html

[4] https://www.audiokinetic.com/library/edge/?source=Unity&id=annotated.html

Bei meinem letzten Blogeintrag habe ich die Wwise-Implementierungsskripte AkInitializer und AkBank, die eine grundlegende Voraussetzung für die Nutzung der Wwise Audio-Engine bilden und das Laden von Soundbanks ermöglichen, beschrieben.

Ein Grundbaustein eines adaptiven Sounddesigns ist das adaptive Verhalten von Sounds, das auf unterschiedliche Gegebenheiten im Spiel reagiert. Dafür gibt es Switches und States, die quasi Zustände repräsentieren und wie Schalter aktiviert werden können. Der Hauptunterschied zwischen Switches und States ist, dass ein Switch jeweils einem einzigen GameObject zugeordnet wird, während States von unterschiedlichen GameObjects aktiviert werden können. Die Nutzung und Konfiguration beider Parameter ist hingegen identisch.

Für das Verändern eines Switches oder eines States gibt es extra dafür vorgefertigte Skripte namens AkSwitch und AkState. In Wwise müssen dafür bereits die unterschiedlichen States bzw. Switches und die State bzw. Switch-Container mit den Audiofiles vorhanden sein, damit man sie in Unity implementieren kann. Ist das gegeben legt man ein AkSwitch- bzw. AkState-Skript auf ein GameObject. In diesen kann man nun über den Unity-Inspector den Switch bzw. State wählen, der aktiviert werden soll.

Des Weiteren muss noch bestimmt werden, was den Switch bzw. State triggert. Klassischerweise ist es das Betreten oder Verlassen eines Colliders.

Hierbei sollte noch ein AkTriggerEnter– bzw. AkTriggerExit-Skript hinzugefügt werden, der spezifiziert, welches GameObject den Trigger auslöst, ansonsten löst jede Kollision mit irgendeinem anderen GameObject den Trigger aus, was in den meisten Fällen nicht gewünscht ist.

Quellen:

[1] https://www.audiokinetic.com/library/edge/?source=SDK&id=soundengine_switch.html

[2] https://www.audiokinetic.com/courses/wwise301/?source=wwise301&id=Setting_States_using_the_AkState_Component