by Philipp Kotecki -

Audio Listener und Audio Sources in Unity

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 Reverb Zone im Unity Inspector mit verschiedenen Konfigurationsmöglichkeiten
Visualisierung des Hall-Verhaltens. Innerhalb des “Full Reverb”-Bereichs ist der Anteil des Diffussignals bei 100%. Im “Gradient Reverb”-Bereich sinkt der Anteil des Diffussignals zugunsten des Direktsignals, je weiter außen der Audio Listener sich 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.

Audio Source mit verschiedenen Konfigurationsmöglichkeiten

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.

Die unterschiedlichen Rolloff-Verhalten

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

by Philipp Kotecki -

Wwise Implementierung in Unity (Teil 4: Scripting)

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.

Das Aufrufen eines hartkodierten Trigger-Events, das Sounds für Fußschritte abspielt

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.

Variable “Play_SFX_Ellen_Run” mit dem gleichnamigen Wwise-Objekt im Property Drawer belegt


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.

Variable “EllenFootsteps” wird mit Wwise-Type “AK.Wwise.Event” initialisiert und in der darauffolgenden Funktion “FootstepWwiseType()” mit der “Post()”-Funktion aufgerufen

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

by Philipp Kotecki -

Wwise Implementierung in Unity (Teil 3: AkState, AkSwitch)

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.

Auswahl des States im Unity Inspector

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

Der State wird hier beim Verlassen des Triggers verändert

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.

AkTriggerExit-Skript mit dem Player als auslösendes GameObject

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

by Philipp Kotecki -

Wwise Implementierung in Unity (Teil 2: AkInitializer & AkBank)

Im letzten Blogpost habe ich die für Unity vorgefertigten Skripte AkEvent und AkTriggerEnter beschrieben, die in Kombination für das Auslösen von Wwise-Events genutzt werden. Dieses Mal möchte ich einige grundlegende Skripte zur Nutzung von Wwise vorstellen.

Damit die Unity-Engine allerdings überhaupt erkennt, dass es Wwise als Audio-Engine nutzen soll, muss zunächst Wwise beim Spielstart initialisiert werden. Das wird mit dem Skript AkInitializer realisiert. Hierfür wird ein leeres GameObject benötigt, das beim Starten des Spiels bereits vorhanden ist. Das GameObject wird im Inspector von Unity mit dem AkInitializer-Skript versehen, das automatisch beim Starten des Spiels geladen wird. Während des Spiels sorgt das Skript zusätzlich dafür, dass Frame für Frame Daten an die Wwise-Engine übetragen werden und somit die Kommunikation unter den beiden Engines gewährleistet wird. Das ist eine der Grundvoraussetzungen für die Nutzung von Wwise.

Leeres GameObject (links) mit AkInitializer-Skript (rechts)

Eine mit AkInitializer nah verwandte Funktion von Wwise ist das Laden von sogenannten Soundbanks. Soundbanks sind Audiodaten und Befehle, die während des Spiels in den Arbeitsspeicher geladen werden und somit unmittelbar ohne längeren Wartezeiten abgerufen werden können. Große Spiele arbeiten mit vielen Soundbanks, die abhängig von der Position des Spielers oder anderen Bedingungen einzeln geladen und wieder entladen werden. Das ermöglicht die Realisierung von großen und komplexen Spielwelten auf einem PC oder einer Konsole. Häufig wird vom Entwicklerteam ein Datenmengenlimit vorgegeben, welches das Audio-Team nicht überschreiten darf.

Das Skript für das Laden von Soundbanks heißt AkBank und kann an unterschiedlichen Stellen ausgeführt werden. In der Regel hat man immer eine Soundbank, die beim Starten des Spiels geladen wird. Weitere Soundbanks werden unter anderem geladen, wenn ein neues Gebiet betreten wird. Das Laden einer Soundbank dauert eine Weile, weshalb einige Spiele währenddessen eine Ladesequenz anzeigen. Bei der praktischen Anwendung erfordert das Skript im Unity-Inspector eine Information, wann die Soundbank geladen, wann sie entladen werden soll. Dabei muss auch bestimmt werden, welche Soundbank geladen werden soll. Es gibt noch weitere Optionen, mit welchen sich einstellen lassen, wie dekodiert und wie genau mit den Daten verfahren werden soll. Das hilft beim Datenmanagement und ist vor allem für umfangreiche Spiele mit großen Datenmengen praktisch.

Die Soundbank “Footsteps” wird beim Starten des Spiels geladen und beim Zerstören des GameObjects entladen

Quellen:

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

[2] https://www.audiokinetic.com/library/edge/?source=WwiseFundamentalApproach&id=understanding_soundbanks_understanding_soundbanks

by Philipp Kotecki -

Wwise Implementierung in Unity (Teil 1: AkEvent & AkTriggerEnter)

Es gibt verschiedene Methoden Wwise-Elemente in der Gameengine Unity zu implementieren. Zum einen gibt es es die klassische manuelle Implementierung mithilfe von Skriptbefehlen in den Programmiersprachen C# (am populärsten), UnityScript und Boo zum anderen gibt es auch vorgefertigte Skripte (in C#) und Funktionen, die ein schnelles Implementieren innerhalb des Unity-Editors ermöglicht.

Vorgefertigte Skripte

Diese Skripte werden bei der Installation von Wwise in einem Unity-Projekt mitgeliefert und decken eine allgemeine Bandbreite von unterschiedlichen Implementierungsmöglichkeiten ab.

Eine der am häufigsten benötigten Funktionen bei der Nutzung von Wwise-Elementen ist das Abrufen von Wwise-Events. Diese übermitteln Informationen an Wwise, die Anweisungen, wie die Audio-Engine handeln soll, beinhalten. In den meisten Fällen ist es das Abspielen oder Unterbrechen von Sounds. Das für Unity vorgefertigte Skript heißt AkEvent. Dieses ist an Bedingungen geknüpft. Häufig ist es das Betreten oder Verlassen eines GameObjects, wie z.b. eines Colliders. Ein Collider ist eine geometrische Form (häufig unsichtbar für den Spieler) im Spiel, die für das Triggern verschiedener Funktionen genutzt werden kann.

AkEvent, das auf das Betreten des Triggers ausgeführt wird


Zusätzlich muss dabei erwähnt werden, dass Collider nur auf GameObjects reagieren. In der Regel möchte man allerdings spezifizieren, welche GameObjects genau diese Trigger auslösen können, sonst reagieren die Trigger auf jedes Eintreten irgendeines GameObjects, also auch auf Elemente, wie überlappende Bausteine aus der Spielwelt. Mit dem Skript AkTriggerEnter kann man festlegen welches GameObject diesen Trigger auslösen kann. Häufig soll nur die eigene Spielfigur, die der Spieler steuert, triggerfähig sein.

AkTriggerEnter mit dem “Player” als einziges GameObject, das diesen Trigger auslösen kann

Quellen:

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

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

by Tobias Bettke -

Hochpassfilter (Part 3)

Ein Hochpassfilter (HPF) ist ein elektronischer Filter, der Signale mit einer Frequenz über einer bestimmten Grenzfrequenz überträgt und Signale mit Frequenzen unter der Grenzfrequenz dämpft. Die Höhe der Dämpfung für jede Frequenz hängt vom Filterdesign ab. Hochpassfilter haben viele Einsatzmöglichkeiten, wie z.B. das Blockieren von Gleichstrom von Schaltkreisen, die auf nicht Nulldurchschnittsspannungen oder Hochfrequenzgeräte reagieren. Sie können auch in Verbindung mit einem Tiefpassfilter zur Herstellung eines Bandpassfilters verwendet werden. Außerdem werden sie auch in anderen Bereichen wie der Mechanik, Akustik, Hydraulik oder in Antennenweichen eingesetzt, wo sie jedoch oft einen anderen Namen tragen. In der Tontechnik beschreibt er also, welche Frequenzen noch enthalten sind, werden also hauptsächlich als Equalizer benutzt werden.

Hochpass 1. Ordnung

Ein einfacher elektronischer Hochpassfilter erster Ordnung wird realisiert, indem eine Eingangsspannung über die Reihenschaltung aus Kondensator und Widerstand gelegt und die Spannung über dem Widerstand als Ausgang verwendet wird. Das Produkt aus Widerstand und Kapazität (R*C) ist die Zeitkonstante (τ); sie ist umgekehrt proportional zur Grenzfrequenz fc, also,

wobei fc in Hertz ist, τ in Sekunden, R in Ohm und C in Farad ist.

Tiefpassfilter

Ein Tiefpassfilter (LPF) ist ein Filter, der Signale mit einer Frequenz, die niedriger als eine ausgewählte Grenzfrequenz ist, überträgt und Signale mit Frequenzen, die höher als die Grenzfrequenz sind, dämpft. Der genaue Frequenzgang des Filters ist abhängig vom Filterdesign. Der Filter wird manchmal als High-Cut-Filter oder Treble-Cut-Filter in Audioanwendungen bezeichnet.

Tiefpassfilter gibt es in vielen verschiedenen Formen, darunter elektronische Schaltungen wie ein Rauschfilter, der in Audio verwendet wird, Anti-Aliasing-Filter zur Aufbereitung von Signalen vor der Analog-Digital-Wandlung, digitale Filter zur Glättung von Datensätzen, akustische Barrieren, Unschärfe von Bildern und so weiter. Die in Bereichen wie dem Finanzwesen verwendete gleitende Durchschnittsoperation ist eine besondere Art von Tiefpassfilter und kann mit den gleichen Signalverarbeitungstechniken analysiert werden, die auch für andere Tiefpassfilter verwendet werden. Tiefpassfilter bieten eine glattere Signalform und entfernen die kurzfristigen Schwankungen.

Beispiele für Tiefpassfilter finden sich in der Akustik, Optik und Elektronik. Eine steife physikalische Barriere neigt dazu, höhere Schallfrequenzen zu reflektieren und wirkt so als akustischer Tiefpassfilter zur Schallübertragung. Wenn Musik in einem anderen Raum gespielt wird, sind die tiefen Töne leicht zu hören, während die hohen Töne abgeschwächt werden. In einem elektronischen Tiefpassfilter für Spannungssignale werden hohe Frequenzen im Eingangssignal gedämpft, aber das Filter weist unterhalb der durch seine RC-Zeitkonstante bestimmten Grenzfrequenz eine geringe Dämpfung auf.  Elektronische Tiefpassfilter werden an den Eingängen von Subwoofern und anderen Lautsprechern verwendet, um hohe Töne zu blockieren, die sie nicht effizient reproduzieren können. Funksender verwenden Tiefpassfilter, um harmonische Emissionen zu blockieren, die andere Kommunikationen stören könnten. Der Klangregler vieler E-Gitarren ist ein Tiefpassfilter, mit dem die Höhen im Klang reduziert werden.

Tiefpass 1. Ordnung

Eine einfache Tiefpassfilterschaltung besteht aus einem Widerstand in Reihe und einem Kondensator parallel zur Spannungsquelle/-abnehmer. Der Kondensator weist eine Reaktanz auf, blockiert niederfrequente Signale und drückt sie stattdessen durch die Last. Bei höheren Frequenzen sinkt die Reaktanz, und der Kondensator wirkt effektiv als Kurzschluss. Die Kombination aus Widerstand und Kapazität ergibt die Zeitkonstante des Filters τ = RC. Die Grenzfrequenz (in Hertz), wird durch die Zeitkonstante bestimmt:

Diese Schaltung kann unter Berücksichtigung der Zeit verstanden werden, die der Kondensator zum Laden oder Entladen durch den Widerstand benötigt:

Bei niedrigen Frequenzen bleibt genügend Zeit, damit der Kondensator praktisch auf die gleiche Spannung wie die Eingangsspannung auflädt.

Bei hohen Frequenzen hat der Kondensator nur Zeit, eine kleine Menge aufzuladen, bevor der Eingang die Richtung wechselt. Der Ausgang geht auf und ab, nur ein kleiner Bruchteil der Menge, die der Eingang auf und ab geht. Bei doppelter Frequenz bleibt nur Zeit, um die Hälfte des Betrages aufzuladen.

by Tobias Bettke -

Passive Filter (Part 2)

Passive Filter basieren auf Kombinationen von Widerständen (R), Induktivitäten (L) und Kondensatoren (C). Diese Typen werden zusammenfassend als passive Filter bezeichnet, da sie nicht von einer externen Stromversorgung abhängig sind und/oder keine aktiven Komponenten wie Transistoren enthalten.

Induktoren (Spulen) blockieren hochfrequente Signale und leiten niederfrequente Signale, während Kondensatoren den umgekehrten Weg gehen. Ein Filter, bei dem das Signal durch einen Induktor geleitet wird oder bei dem ein Kondensator einen Erdungsweg bereitstellt, weist gegenüber niederfrequenten Signalen eine geringere Dämpfung auf als Hochfrequenzsignale und ist daher ein Tiefpassfilter. Wenn das Signal durch einen Kondensator geht oder einen Erdungspfad durch einen Induktor hat, dann zeigt das Filter eine geringere Dämpfung gegenüber hochfrequenten Signalen als niederfrequente Signale und ist daher ein Hochpassfilter. Widerstände allein haben keine frequenzselektiven Eigenschaften, sondern werden Induktoren und Kondensatoren hinzugefügt, um die Zeitkonstanten der Schaltung und damit die Frequenzen, auf die sie reagieren, zu bestimmen.

Die Induktivitäten und Kondensatoren sind die reaktiven Elemente des Filters. Die Anzahl der Elemente bestimmt die Reihenfolge des Filters. In diesem Zusammenhang wird eine LC abgestimmte Schaltung, die in einem Bandpass oder Bandsperrfilter verwendet wird, als ein einziges Element betrachtet, obwohl sie aus zwei Komponenten besteht.

Aktive Filter

Aktive Filter werden mit einer Kombination aus passiven und aktiven (verstärkenden) Komponenten realisiert und erfordern eine externe Stromquelle. Operationsverstärker werden häufig in aktiven Filterdesigns eingesetzt. Diese können einen hohen Q-Faktor (Höheres Q bedeutet einen geringeren Energieverlust im Verhältnis zur gespeicherten Energie des Resonators; die Schwingungen sterben langsamer ab. Bei einem Filter ist dann die Grenzfrequenz steiler) haben und ohne den Einsatz von Induktivitäten Resonanzen erzielen. Ihre obere Frequenzgrenze wird jedoch durch die Bandbreite der Verstärker begrenzt.

by Tobias Bettke -

Elektronische Filter (Part1)

Elektronische Filter sind Schaltungen, die Signalverarbeitungsfunktionen übernehmen, insbesondere um unerwünschte Frequenzanteile aus dem Signal zu entfernen, gewünschte zu verbessern oder beides. Sie verändern es abhängig von der Amplitude, der Frequenz und der Phasenlage. Filter können in verschieden Kriterien klassifiziert werden, wie zum Beispiel passive oder aktive Filter, analoge oder digitale, HP/LP/BP Filter, linear und nicht-lineare Filter. Die meisten der genutzten Filter sind lineare Filter. Die ältesten Formen von elektronischen Filtern sind passive analoge lineare Filter, die nur aus Widerständen und Kondensatoren oder Widerständen und Induktivitäten bestehen. Diese werden als RC- bzw. RL-Einpolfilter bezeichnet. Diese einfachen Filter haben jedoch nur sehr begrenzte Einsatzmöglichkeiten. Mehrpolige LC-Filter bieten eine bessere Kontrolle über Ansprechform, Bandbreite und Übergangsbänder. Der erste dieser Filter war der konstante k-Filter, der 1910 von George Campbell erfunden wurde. Campbells Filter war ein Leiternetz, das auf der Theorie der Übertragungsleitungen basiert. Zusammen mit verbesserten Filtern von Otto Zobel und anderen werden diese Filter als Bildparameterfilter bezeichnet. Einen großen Schritt nach vorne machte Wilhelm Cauer, der den Bereich der Netzwerksynthese zur Zeit des Zweiten Weltkriegs gründete. Cauers Theorie erlaubte es, Filter zu konstruieren, die genau einer vorgegebenen Frequenzfunktion folgten.

Filtertypen

Bei einem TP (Tiefpassfilter) werden alle tiefen Frequenzen bis zu einer Grenzfrequenz durchgelassen, alle höheren Frequenzen abgeschwächt. Das HP (Hochpassfilter) im Gegensatz lässt alle hohen Frequenzen durch und schwächt die tieferen Frequenzen ab. Die Kombination dieser beiden Filtertypen wird BP (Bandpassfilter) genannt, weil es zwei Grenzfrequenzen gibt, wobei alle höheren und tieferen Frequenzen abgeschwächt und ein mittleres Frequenzband durchgelassen wird. Das Bandrejectfilter ist das Gegenstück dazu, indem er nur das mittlere Band abschwächt und filtert, die Randfrequenzen jedoch durchlässt.

Der Idealfall einer rechteckigen Grenzfrequenz ist in der Realität nicht erreichbar, daher wird normalerweise zur Bestimmung der Parameter von einem normierten TP ausgegangen.

Lineare- / Nichtlineare Filter

Bei nichtlinearen Filtern sind die Eigenschaften des Filters abhängig von dem Signalpegel und dem zeitlich verlauf. Es können Verzerrungen entstehen, daher werden sie auch als Begrenzer, Verzerrer oder Medianfilter eingesetzt. Bei linearen Filtern jedoch sind die Filtereigenschaften unabhängig von der Laustärke und das Signal wird nicht verzerrt. Die grundlegende Form des Signals wird nicht verändert, nur mit einem Faktor multipliziert. Dazu gehören auch TP, HP oder BP Filter.

by Katsiaryna Palishchuk -

Modules for analog synthesizers using Aloe vera biomemristor

The study, made by Kiyu Nishida showing the usage of natural resources, such as slime mold and aloe vera leaves in modern music performances. In this particular research and experiment, the aim was to show the novel possibilities of sound based on unconventional technologies such as integrating biological forms and structures into traditional circuits — in our case, aloe vera. A biosignal has been used in experimental music as the material for composition. 

How does it work?

For controlling the sound with the help of electricity level, we need to use a resistor. Exist more complex resistor — memrisotor. The functions are all the same, but memristor can memorize information and use it for further notice. Fascinating, that there are couple of memristors in a nature, such as slime mold and aloe vera. They are the bio-memtistors. 

Nowadays, people are trying more and more to connect technologies with nature. One by one. Result is not always successful, but always worth it. The aloe vera sound creates new possibilities for performance, music experimenters in a new unique way. 

The sound of the outcome you can listen below.

Links:

https://zenodo.org/record/4813249#.YM83JS1c5QJ

by Janina Schindler -

Usability Testing | Usability is an attribute of good design

»If you want a great site, you’ve got to test. After you’ve worked on a site for even a few weeks, you can’t see it freshly anymore. You know too much. The only way to find out if it really works is to test it.«

– Steve Krug in Don’t make me think (2000)

To observe, if a (digital) product really fits the user’s needs and what are potential problems and pain points, there is a method called usability testing. I watched a talk of Steve Krug, experience professional and author, in which he explains why usability testing is so important and runs through some tips for improving your own usability tests. To break it down usability testing basically is watching people trying to use what you have created, even if it is just a prototype, and let them think out loud in order to have access to their cognitive process and looking for the frustration points, questions etc. It should start at an early state of the project and includes the user’s direct feedback into the creation process, to figure out the problems before you build them into your project and discover them at a (too) late status.   

Why are we doing usability testing?

They take a lot of time to build, get the data, cost money and the main question is, is it all worth it? It is! There are many reasons for you to test your product in order to have a good user experience and improve your work. Steve Krug said:  

»Usability is an attribute of good design«

Steve Krug

He defined a thing as usable if:

  1. A person of average – or even below average – ability and experience (i.e., most people)
  2. can figure out how to use the thing for the intended purpose
  3. without it being more trouble than it is worth.

A common issue is that a deeply involved person e.g. a designer is very into the subject and gathered a lot of information throughout the research phase of the project. While designing the product, she/he of course uses all that knowledge and creates the prototype as if the user has all that knowledge too, because it is just obvious to her/him and why should anybody think of it different? Usability testing gives the creators the opportunity to watch somebody else have the experience without former knowledge about it and let the participant use it in their own individual, intuitive manner. This discovers lots of problems in best case at an early state of the project and can happen in only a very short amount of time if well planned and organized. As Leisa Reichelt, Head of Research and Insights at Atlassian, said: 

»You are not your user and you cannot think like a user unless you are meeting users regularly.« 

Leisa Reichelt

In his talk, Krug also mentions that we are basically all users and we imagine that everybody uses it the same way as we do, but we are not our users. He says that users are incredibly diverse and all use is idiosyncratic (depending on prior knowledge, situation, goals…).  Sometimes it can be very hard for us creators to remember that the user does not know what we know.

Usability issues can slow down the whole process of use, it can cause anxiety, be annoying and sometimes even scare people of to use something any further at all. Usability testing can prevent the product from all this, in order to guarantee a good user experience and usability throughout the process of use. Most usability issues and problems are contextual, it depends on the thing that you are building, there are only a few absolute truths in therms of usability and UX, says Krug. He gives a good example, talking about that people mostly get their jobs because of who they are as a person. He describes that e.g. people become a developer, because they like complicated stuff and figure out how things work. For a pure developer, interfaces can totally look different as if a designer or another involved person in the process looks at it and it can also differ from how the user would look at it. If you now take into consideration every member of a team, including developers, designers, project managers etc. it is sometimes just very hard to agree on something and make a decision and proofs the idiosyncratic use. A good solution can be to just test it and see how the user can cope with the discussed particular element. 

In his talk, Krug gives a short introduction in DIY usability testing (nutshell version) and goes on by a live usability testing to demonstrate how easy it can be. After that, he goes on and introduces his 6 maxims, which you can also see in the video beneath. 

For user centered design, it is necessary to be aware how the user would interact with your product or service, whether it is a website, an app, a streaming service or anything else. For me it influences my design decisions and helps to discover usability problems, that I sometimes would have never imagined to be a problem at all. Every design decision kind of starts off with a hypothesis, that this is how the user would like to experience something and this is also very much influenced by own assumptions and previous knowledge. User Testing proves your decision wrong or right and puts yourself in the user’s shoes to see the project from his point of view.

Sources:

Don’t make me think : Web usability – das intuitive Web by Steve Krug

Video 01: Usability Testing: How to Do-It-Yourself with Steve Krug:
https://youtu.be/VTW1yYUqBm8