Interaktive Musik: Übergänge auf der Audio-Clock planen

Eine Clock verwenden, die zum Audio-Renderer gehört

Ein Callback im Game-Thread, der meldet, dass ein Beat eingetroffen ist, kommt zu spät, um zu garantieren, dass neu angefordertes Audio genau auf diesem Beat beginnt. Audio wird in Buffern gerendert, während Game-Frames ungleichmässig eintreffen können. Stattdessen ist das Rendering für einen künftigen Zeitpunkt zu planen. Quartz von Unreal unterstützt musikalische Quantisierung auf seiner Audio-Clock; AudioSource.PlayScheduled in Unity plant relativ zur absoluten Zeitachse, die über AudioSettings.dspTime verfügbar ist. [1][2]

Den musikalischen Scheduling-Vertrag festlegen

Festzulegen sind ein gemeinsamer Ursprung, das Tempo, die Taktart und die Grenzen, an denen Übergänge erlaubt sind. Ausserdem ist zu bestimmen, wie viel Vorbereitungszeit ein neues Segment benötigt, einschliesslich Laden und Dekodieren. Alle Layer sind auf derselben Clock zu halten, und die Grenzen sind aus der musikalischen Position abzuleiten, statt gerundete Game-Frame-Dauern wiederholt aufzuaddieren. Eine Änderung der Intensität kann den nächsten gültigen Übergang anfordern, ohne sofort einen neuen Sound zu starten. Wiederholte Anfragen sind zusammenzufassen, damit der Scheduler keine doppelten Einsätze einreiht.

Durchgerechnetes Beispiel: Der nächste Takt kann schon zu nah sein

Angenommen sei zur Illustration ein Tempo von 120 Schlägen pro Minute mit Viertelnoten-Beats im 4/4-Takt und eine Audiorate von 48000 Sample-Frames pro Sekunde. Jeder Beat dauert 0,5 Sekunden bzw. 24000 Frames; jeder Takt dauert 2 Sekunden bzw. 96000 Frames. Der musikalische Ursprung liege bei Zeit null.

Bei der Audiozeit von 5,3 Sekunden beginnt der nächste Takt bei 6 Sekunden, es bleiben also 0,7 Sekunden zur Vorbereitung. Angenommen, dieses System verlangt bewusst 0,1 Sekunden Vorlaufzeit. Eine Anfrage bei 5,95 Sekunden lässt nur 0,05 Sekunden, daher ist der nächste zulässige Takt erst bei 8 Sekunden. Der Wert für die Vorlaufzeit ist eine beispielhafte Vorgabe, keine Garantie der Engine. Ein verspäteter Start an der verpassten Grenze würde die musikalische Beziehung verändern.

Übergänge unter Last überprüfen

Zunächst mit Klicks auf dem Beat und einem zweiten Layer beginnen, der an einer Taktgrenze einsetzt. Das gerenderte Audio ist aufzuzeichnen und die Einsatzpositionen sind zu untersuchen, statt das Timing aus einer visuellen Benachrichtigung abzuleiten. Anfragen knapp vor und knapp nach der Scheduling-Frist sind zu testen. Dabei werden Hänger im Game-Thread und Cold Loads von Assets provoziert und geprüft, ob der gewählte Fallback die laufende Musik beibehält oder den Einsatz verschiebt.

Zudem ist das Verhalten bei Abbruch, Pause, Fortsetzen und Tempowechsel festzulegen. Ein Übergang, der für einen bestimmten Zustand der Clock bereits eingereiht wurde, muss nach einer Zustandsänderung unter Umständen ausdrücklich ersetzt werden. Loop-Grenzen sind auf Stille, doppelte Attacks und nicht passende Segmentlängen zu prüfen. Crossfades müssen demselben Timing-Vertrag folgen wie die Segmentstarts.

Den Genauigkeitsanspruch präzise halten

Sample-Genauigkeit beschreibt die Platzierung innerhalb des gerenderten Audios. Sie beseitigt weder die Pufferung der Ausgabe noch die Gerätelatenz noch die Verzögerung, bis eine Gameplay-Anfrage den Scheduler erreicht. Benachrichtigungen aus dem Game-Thread sind nicht als sample-genau anzunehmen. Für Gerätewechsel und nicht verfügbare Assets braucht es Wiederherstellungsstrategien. Zu bewerten sind sowohl die musikalische Kontinuität als auch die Reaktionszeit; ein perfekt ausgerichteter Einsatz kann sich dennoch träge anfühlen, wenn die gewählte Grenze zu weit entfernt liegt.

Quellen

• [1] Quartz Overview — Epic Games, Unreal-Engine-Dokumentation.
• [2] AudioSource.PlayScheduled — Unity Technologies, Unity-6.0-Scripting-API.