Lukas Wendt, Class ‘16
Procedural lyd er løftet om at kunne skabe lyd ud af den blå luft. Idéen fanger fagfolks fantasi, men vejen fra fantasi til virkelighed kan ofte være lang, når implementering og performance skal overvejes. I efteråret 2015 skrev jeg min bachelor, som forsøgte at identificere nogle af udfordringerne ved teknologien, og give forslag til hvordan tilgængelige og effektive værktøjer kan designes. I det følgende blogindlæg vil jeg gennemgå vejen hen til den færdige opgave og dele erfaringer omkring udfordringer og opdagelser.
Udover den skriftlige del, inkluderede opgaven to produkter. Det ene produkt var en prototype på et værktøj og det andet et lille projekt som gjorde brug af prototypen.

Motivation

Under mit praktikforløb og i forbindelse med andre projekter, har det flere gange været et ønske at bruge kunne bruge procedurale teknikker. Filosofien og teknologien bag feltet har et stort udviklingspotentiale men mangler udvikling og afprøvning. Flere større firmaer er begyndt at omfavne teknologien, men for mindre aktører med begrænsede ressourcer, kan den stadig virke utilgængelig og usikker.

Problem

Mange af de eksisterende værktøjer til at udvikle procedural lyd, har alle nogle centrale problemer til fælles. Enten er de svære at integrere og komplicerede at lære at kende, ellers integreres de let men virker fastlåste. Der mangler en mellemvej, som både kan tilbyde en fornuftig læringskurve og mulighed for høj grad af kontrol.

Disse problemer ledte til spørgsmålet:

Hvordan kan værktøjer til implementering af procedural lyd i spilproduktion designes for at gøre teknologien mere tilgængelig?

Hvad er procedural lyd?

Opgaven definerede procedural lyd som værende non-lineær og ofte syntetisk lyd, skabt udfra regler og udefrakommende input. Den beskrivelse stammer fra Andy Farnell, som af mange anses for at være procedural lyds gudfar. Han har skrevet bogen Designing Sound, som gennemgår en bred vifte af felter relaterede til forståelsen af lyd som et både fysisk og psykisk fænomen. Gennem en bred vifte af videnskabelige felter giver bogen et grundlag for at forstå lyd som en sum af flere processer. Det er en idé som er central for procedural lyd – at lyd er en proces og ikke data.

Overordnet bliver der arbejdet med to former for procedural lyd. Den ene form bygger på analyse og resyntese, hvor brugeren indlæser en lydfil i et program, som derefter skaber variationer af lyden. Denne teknik ses blandt andet i SoundSeed i Wwise og Nicolas Fournels arbejde for Sony. Det er en effektiv måde at lave mange variationer på, og som lyddesigner er det ikke nødvendigt at tilegne sig ny viden.
Den anden form består af at skabe modeller af lyde. Til at starte med, skal den ønskede lyd analyseres. Det skal besluttes hvilke processer der sammen giver den ønskede lyd. Disse processer skal herefter syntetiseres, og kobles sammen med input fra spillet eller andre modeller.
I arbejdet med procedural lyd indgår viden om fysik, mekanik, matematik, programmering, syntese psykologi, akustik og anatomi. Mangel på viden inden for disse områder, står ofte i vejen for gode resultater og udvikling på området.

Hvornår er procedural lyd relevant?

Procedural lyd er blandt andet relevant i spilproduktion, når projekters størrelse gør asset-management til en stor opgave. Ved at bruge procedurale modeller, kan det undgås at lyde skal produceres og arkiveres i mange variationer for at at undgå repetition. Variationen kommer med modellen, da varierende input fra spillet giver forskellige output fra modellen.
Det kan være svært at genbruge lydeffekter til spil, med mindre det accepteres at de kommer til at lyde ens. Hvis procedurale modeller bliver designet fleksibelt nok med kraftfulde parametre, vil der opstå helt nye muligheder for genbrug både internt og i andre projekter.

Eksisterende værktøjer

De tidligere nævnte værktøjer Pure Data, SuperCollider og Csound er ikke designet til brug i spilproduktion. Her er en gennemgang af nogle løsninger, som allerede bliver brugt i produktion af spil.
FMOD og Wwise er to middlewareprogrammer, som på mange måder minder om hinanden. De bliver her nævnt i samme omgang, da begge løsninger hovedsagligt fokuserer på arbejdet med samplebaseret lydimplementering. Programmerne kan implementeres i mange platforme, heriblandt Unity. Det er muligt at bruge og udvikle plugins til begge programmer, hvilket betyder at der allerede er blevet udviklet plugins til implementering af procedural lyd.
AudioGaming er et firma som producerer forskellige procedurale modeller. Serien indeholder vind-, regn-, motor- og fodtrinsmodeller. Med deres plugin AudioRain kan brugeren lave alt fra stille regndryp til voldsomme skybrud. Brugerfladen er delt op i moduler med parametre relaterede til henholdsvis rumble, shower og to forskellige liquids. Her kan brugeren indstille forskellige filtre, densiteter, viskositetsniveauer og amplitude. Det er muligt at bruge AudioGamings plugins i FMOD, hvilket gør dem nemme at implementere i projekter, som i forvejen bruger FMOD som middleware tool.
SoundSeed er et integreret værktøj i Wwise, som indeholder forskellige lydgeneratorer. Den ene bruges til kollisionslyde, og virker ved at udføre forskellige slags analyse, for at lave syntetiserede modeller ud fra en valgt lydfil. Det betyder, at brugeren kan nøjes med at lave en enkel lydfil, som derefter vil blive varieret i frekvens, frekvensbåndsbredde og størrelse. Den anden lydgenerator er specialiseret i luft, og kan både syntetisere vind og whooshes, ved at indstille de tilgængelige parametre. De fleste parametre i begge modeller kan moduleres fra spillet.

Udvikling af Signal

Signal blev navnet på den prototype, som blev udviklet sideløbende med opgaven. Udviklingen af prototypen havde til formål at konkretisere de idéer, behov og koncepter som interviews og egen refleksion afdækkede i løbet af arbejdet med opgaven.
Prototypen gør det muligt at udvikle og afvikle procedural lyd direkte i Unity. Den er delt op i en editor hvor patches kan sættes sammen, og en del som kører når spillet sættes i gang. Hvis man er bekendt med det visuelle programmeringssprog Pure Data, vil objekterne i Signal se bekendte ud. Objekterne er designet til at opføre sig, som de gør i Pure Data, hvilket betyder, at eksisterende teknikker og modeller nemt kan overføres.
Der er vigtigt at identificere hvilke behov lyddesignere har til de værktøjer, som gerne skulle blive en del af deres arbejdsprocess. Der er stor forskel på, hvor tekniske lyddesignere er, hvor mange ressourcer de har til research og udvikling og om de primært bruger lydbiblioteker eller skaber lyde fra bunden. Det er svært at skulle tilfredsstille alle de behov, men det er værd at forsøge at tænke dem ind i designprocessen. I prototypen er workflowet delt op i tre lag, for at passe til flere grader af behov for kontrol og kompleksitet.
Det nederste lag kræver mest teknisk kunnen, da der her er en høj grad af kontrol og kompleksitet. Dette lag er basis for de øvre lag, da der her kan udvikles moduler og hele plugins.

Eksempel på low level i Signal

Det midterste lag bygger på en modular tilgang, hvor mindre objekter bliver samlet i større bokse. Det medfører, at unødvendig kompleksitet bliver gemt væk, samtidigt med at brugeren stadig har en høj grad af kontrol over sin patch.

Eksempel på moduler i Signal

Det øverste lag indeholder præfabrikerede plugins og kan med fordel bruges af folk med begrænset erfaring med lydsyntese. I opgaven bliver det nævnt, at denne tilgang ofte bliver kritiseret, men at der også kan argumenteres for tilganges værdi. Når der arbejdes med lyd til spil, skal der ofte produceres store mængder lydeffekter på meget kort tid. Ved at kunne bruge præfabrikerede modeller, vil lyddesignere få gavn af de fordele der følger med procedural lyd, uden at skulle investere store mængder arbejdstimer i udviklingen.

Eksempel på præfabrikeret model i Signal

Prototypen beviste, at værktøj som inkluderer en tredelt brugerflade kan lade sig gøre og dermed gøre procedurale værktøjer tilgængelig for en større brugergruppe med mindre teknisk fokus. En fordel ved inklusionen af disse tre lag er, at den kollektive udvikling af teknologien kan fremmes, da flere brugere kan deltage og bidrage.

Refleksion

Et af Signals store styrker ligger i, at en lyd kan udvikles og integreres på samme tid. Det sørger for, at der er kortere vej mellem iterationer, da det færdige resultat hurtigere kan opleves og bedømmes.
Det blev fra starten besluttet, at Signal skulle bruge Pure Data som et visuelt sprog. Det medførte en masse fordele, blandt andet at der i forvejen er en masse dokumentation tilgængeligt. Det betyder at nye brugere nemt kan sætte sig ind i, hvordan sproget fungerer. Modeller der er udviklet i Pure Data, kan også oversættes til brug i Signal. En ulempe ved at bruge Pure Data som sprog er, at det forventes at alle objekter virker på præcis samme måde. Det giver et kæmpe rekreationsarbejde, da listen af objekter i Pure Data er lang.

Videre undersøgelse
Hvis du er interesseret i procedural lyd, er der her et par anbefalinger til videre undersøgelse af emnet: