Author Archive: Magnus

3 April

Wednesday, April 3rd, 2013 by Magnus

Idag analyserades Impulserna vi spelat in i förra veckan.

Anledningen till att vi analyserade de är för att vi skall ha en insikt hur inspelningarna blev och om de kan tänkas fungera och uppnå sökt effekt.

Vi använde audacity för att rita upp ett hanning fönster med FFT analys av några av inpsleningarna.

Nedan följer två av inspelningarna, vid 30 d.v.s. snett framför testpersonen, och vid nittio grader, rakt ut från höger öra.

Vi valde att namnge inspelningarna efter vinkel med början framifrån och hela varvet runt (360 grader) istället för att som man tydligen brukar göra i sådana här sammanhang, 180 grader för respektive öra, eftersom det blir mer logiskt ur spelsammanhang, då fft filtret inte skall agera på ett öra utan en riktningsvektor +- 90 grader.

Vi spelade in en ‘ren’ brus signal, d.v.s. vi försökte spela in ett brus som inte fick någon yttre påverkan innan det nådde mikrofonen, vi hoppades på att detta skulle få en jämn frekvensrespons, då kunde vi ha varit gelt säkra på impulsenrnas trovärdighet. Den inspelning vi gjorde utan påverkan fick dock vissa dalar och kurvor.

Vi kan tyvärr inte veta om desssa är från högtalaren vi använde, från mikrofonerna eller från rummet vi spelade in i. Vi gjorde ett försök at balansera denna inspelning med en equalizer för att få en baskurva att applicera på de andra impulserna, detta fungerade dock inte då det uppstod missjlud när samma eq-kurva applicerades på de andra impulserna.

Om man tittar på dessa två impulser ser man det mönster vi är ute efter, man kan se att topparna och dalarna varierar med vinkeln, både i dess frekvenser och i dess amplitud.

Förhoppningsvis räcker 12 inspelningar för att trovärdigt återge 360 grader.

 WorkbookFFTANALYSIS

Det som förvåmade oss mest med resultaten var hur mycket amplituden skiljde sig så for ljudet inte var framför lyssnaren, redan vid 30 grader märktes väldigt stor skillnad.

20 Mars

Wednesday, April 3rd, 2013 by Magnus

Idag satt jag (Magnus) Med lite unrealscript, enkel kod dock eftersom jag egentligen inte kan unrealscript, men vi behövde an klass som agerar som ljudkälla så att vi inte behöver programmera in alla dessa i max/msp. Optimalt vore att kunna instancera ljudkällor i max/msp beroende på information från UDK men det är inte säkert att Max/Msp’s ‘poly’ funktion är snabb nog eller kan instanceras på detta viiset, kanske med en java klass.

Jusst nu skickar klassen ut info om vart den befinner sig och vilket ljud den spelar upp, och så kollar den om det finns nåt mellan spelaren och ljudet, förhoppningsvis kan detta användas för att kontrollera volym och filtrering.

Jag implementerade även nya structs i Rob Hamiltons DLL binder för att kunna använda Unreal klassen med Max.

Jag och pontus skrev även en java klass för att tolka signalen från oscen beroende på nyckelord.

 

28 Mars

Thursday, March 28th, 2013 by Magnus

Idag har vi spelat in impulssvaren som vi skall basera FFT filtret på.

Inspelningarna gjordes med ett par speciella mikrofoner (Soundman OMK II) som placeras i öronen för att fånga upp det ljud som påverkats av ytterörat.

Vi gjorde inspelningarna med en speciell rigg där vi satte en högtalare, riggan höll högtalaren på ett jämt avstånd, vi valde 1 meter som mätavståndet vilket är något lågt för denna typen av inspelning, det vi sett i andra impulsmätninngar är 1 meter och uppåt, men brist på utrymme gjorde att vi inte kunde få ett jämt avstånd längre än 1 meter.

 

Högtalaren flyttades sedan runt en vår inspelningsperson, och vi spelade impulserna för varje vinkel.

Vi valde att göra 12 inspelningar per varv, och tre varv; ett under lyssnaren, ett över lyssnaren och ett i höjd med lyssnaren, vi mätte innan varje inspelning för att få ett jämt avstånd. Vi spelade även in ett impulssvar rakt ovanför och ett rakt under. Eftersom vi hade 2 OMK II mikrofoner kunde vi nöja oss med att spela in ett 7 (egentligen 6 men ändå) impulser för varje 360 grader och använda den andra mikrofonen som 180-n (n = mätvinkel).

Här är en bild på proceduren, han som sitter i stolen är Jakob Westberg.

21 Mars

Thursday, March 21st, 2013 by Magnus

Idag satt vi och funderade på hur vi kan lösa filtreringen.

FFT står för fast fourier transform och är en process med vilken man kan få fram en represantion av en vågform, bild, funktion, eller vad som helst.

En FFT transform, är en process med vilken man omvandlar data som existerar i tid till data som existerar i frekvensform, d.v.s. en samling frekvenser.

Varje frekvens har två dimensioner, reell och imaginär dessa namnen är helt godtyckliga och skulle kunnat heta t.e.x. X och Y.

I vilket fall som helst så betyder dessa Frekvens respektive fas.

När man plockat isär dessa kan man manipulera egenskaperna för vågformerna lite hur man vill.

I vårt skall vi göra ett filter, då multiplicerar vi den ena vågens  (impulsen) amplitud med den andra vågens, och sedan sätter man ihop vågen igen, från information i frekvens, till information i tid.

Detta ger dock hemska artefakter, dessa kan reduceras genom att öka antalet samples som ‘buffras’ till FFT filtret, men även vid 16284 samples så är ljudkvaliteten oacceptabel.

Dessutom så får man en fördröjning på filtret som är lika stor som buffern, eller som är genomsnittet av filtersignalen (impulsen) för buffern.

man kan lösa detta genom att använda ‘vectral’ noden i max/msp. Jag vet inte vad denna gör men den jämnar ut effekten över ett fixerat antal sampels, i detta fallet använder jag 256 sampels.

 

Torsdag 14/3

Monday, March 18th, 2013 by Magnus

Udkosc fungerar nu som den skall mycket tack vare Rob’s  (skaparen av UDKOSC) råd och instruktioner. Han hade nämnt i tidigare mail att han har tänkt implementera rotationsvektorer för spelaren, och det visade sig att han redan hade gjort det i den senaste uppdateringen, det var en trvlig överraskning och ljudmotorn kunde därför testas igår. Testet visade att max/msp patchen fungerade i stort sätt som den skulle. Nu skall bara fler Binaurala element implementeras. Om detta går någorlunda fort har jag tänkt att implementera ett någorlunda primitivt ‘Ambiosoniskt'(googla det) system för reverbet, bestående av en kollisionscheck mellan spelare och ljudkälla som kontrollerar ett filter samt volymjustering. Detta kommer att hjälpa avsevärt vid lokalisering av ljud i ljudmiljön, och skiljer sig från många moderna ljudmotorer (Exempelvis udk’s inbyggda skräp) och kommer att ge en mycket djupare inlevelse i ljudmiljön. Vi måste även tänka på redovisningen. Igår diskuterade vi lite om hur vi kommer att lägga upp den, och vi kommer att behöva börja skriva ner den imorgon. Det är tråkigt att det skall behöva ta så mycket tid när vi behöver så mycket som möjligt till spelet.

Robert hamilton

UDKOSC

Torsdag 7/3

Thursday, March 7th, 2013 by Magnus

Idag börjar jag arbetet på en binaural max/msp syntes.
Idag fokuserade jag på att skapa den delen av patchen som hanterar interaural timedifference. Jag har utgått ifrån den tidigare forskningen för att skapa patchen, exemppelvis för att använda de tider vi läst om, samt dubbelkolla resultaten.
Efter att ha programmerat en itd simulator, märker vi att att man med en överdriven itd effekt uppnår starkare lokaliseringskänsla i ljudet. Ett problem vi stöter på är att ljudet vid en neutral itd känns som att det befinner sig utanför huvudet. Vi märker i alla fall att en klar lokaliseringseffekt uppnås med hjälp av endast itd vilket glädjer oss. Vi börjar fundera på varför ljudet upplevs som inuti huvudet istället för en framför-eller bakom huvudet effekt. Vi tror att det kan ha att göra med att det vi använt för att testa effekten är en musikfil, och därför inte har några klara lokaliserings signaler som t.e.x. reverb som talar om för oss att ljdet befinner sig i en miljö. Därför testar vi även med ett ljudklipp av en internvju Pontus spelat in tidigare.
Vi stötte på problem eftersom delayet inte kunde återskapa den korta perioden som vi ville.
Vi löste detta genom att ställa ner programmets vektorstorlek eller tröskel så att vi kunde få fördröjningar så korta som 2 samples, eller 0,0004 sekunder. Det låter som väldigt lite, men när man lyssnar på ljudet hör man en klar skillnad i vart den uppfattade ljudkällan befinner sig. För att försäkra oss om att delayet fungerade som det skulle, spelade vi in klipp från max/msp och kollade resultatet i Audacity (se bild).
Att minska vectorstorleken gör att ljudkalkyleringarna blir mer komplicerade, det återstår att se hur mycket man kan pressa ner storleken när fler ljud och effekter skall beräknas samtidigt.

Tanken är att vi sedan skall applicera mer delay för båda öronen beroende på ljudkällans avstånd till spelaren för att på så sätt väga upp för ljudets hastighet.

BIld1Audacity

Bild2Audacity

Exempel

8/2 Fredag

Friday, February 8th, 2013 by Magnus

Vi hade en grupphandledning under torsdagen, vilket var bra eftersom vi inte haft många handledningar hittills, vi skulle behöva fler handledningar än vi har tillgång till. Jusst nu är det en handledning i veckan så det gäller att vi tänker ut i förväg om det är någonting vi har problem med.

Vi har skrivit mycket på arbetet under de senaste dagarna  eftersom vi kommer att få den granskad till nästa måndag och ville lämna in ett så färdigt resultat som möjligt så att vår handledning blir mer meningsfull, men det har varit svårt att få in källorna, i alla fall för mig (Magnus) då jag har spenderat mycket tid tidgare för att hämta information och nu sammanfattar det .Detta leder till att jag sitter mycket och läser om tidigare info för att veta exakt vilken sida i vilken bok jag läste det.

Vi ändrade åter igen våran frågeställning til Hur utvecklar man en ljudmotor som fungerar efter binaural princip. Vi tycker att denna passar bättre än vår tidigare frågeställning Hur skulle implementering av realtids genererat binauralt ljud i en spelproduktion fungera? Då den både är mer specifik i vad vi vill åstadkomma med arbetet och låter oss undersöka och skriva mer principerna för binauralt ljud snarare än hur de skall implementeras.

31/1 Torsdag

Friday, February 1st, 2013 by Magnus


Vi kände att vi var tvugna att börja undersöka tekniken vi kommer att använda för att konstruera vår ljudmotor.
Vi har valt att använda oss av max/msp som ljudmjukvara och låta ett annat program, Unreal Development Kit, skicka den viktiga informationen till max via nätverkskommunikation.
För att göra detta använder vi oss av en modifikation till udk so heter UDKOSC som är skriven av Robert Hamiltom på CCRMA, stanford university. Detta tillägg till UDK skickar så kallad OSC  (Open sound controller) data till vår maxpatch. Den vesäntliga datan i vårt fall är spelarens position och riktning, samt ljudkällornas position. för att skicka osc datan används specialskrivna Unreal Klasser, som ärver funktionalitet från standard Unreal Klasser, och utökar funktionaliteten att fungera med OSC tillägget.
Vi spenderade stor del av dagen att få detta tillägget att fungera, men lyckades trots detta inte installera tillägget till en installation av udk.
Vi lyckades däremot prova tekniken med en färdig demo av tillägget som fanns på UDKOSC’s wiki. Vi kopplade ihop variabler som spelarens position med variabler i max/msp och lyckades på detta sätt styra ljudet från udk.

UDKOSC-test

23/1 2013 Onsdag

Wednesday, January 23rd, 2013 by Magnus

Idag har vi fortsatt med arbetet med projektplanen. Vi har  filtrerat bland våra många tänkbara frågeställningar för att få fram två stycken som vi kan arbeta med, en huvudfrågeställning och en sekundär. Anledningen till att vi valt att göra detta är att det finns arbeten ute som hanterar våran huvudfrågeställning, vi är dock inte helt nöjda med hur dessa undersökningar är gjorda; vi tycker att den tidigare undersökningen som finns på detta ämne har gjort ett antal felaktiga beslut som gör att undersökningen inte är så bra som den kunde vara.
Vi har bestämt oss för att imorgon ha handledning om detta.

22/1 2013 Tisdag

Tuesday, January 22nd, 2013 by Magnus

Idag fortsatte vi att diskutera kring vår ide. Vi diskuterade gårdagens fynd, Rapture3d som vi hade som en tänkbar lösning på vårt dilemma med hur man skulle kunna tänka sig implementera binauralt ljud. Vi hittade idag dock en UDKOSC (Open Sound Controller), via vilken vi skulle kunna låta information skickas från udk till en extern mjukvara, exempelvis MAX/MSP.
Vi hoppas på att kunna använda denna tekniken då det skulle passa perfekt med vår ide om att göra ett konsument/målgruppstest på  Binauralt ljud i 3d miljö som en del i vår undersökning, på detta sättet skulle vi också kunna använda det vi utvecklat för att genomföra undersökningen som en del i produktionen.
Även tanken på att låta ett externt program som vi har total kontroll över sköta allt ljudet är en mycket lockande ide. Detta är roligt att diskutera och tänka på, trots att produktionen ligger långt i framtiden.
Vi är mycket hoppfulla.

Vi satte oss också ordentligt med planeringen dels för att vi inte har mycket tid att skriva den men även för att vi skall få en klar överblick över vad som faktiskt skall ingå i vår undersökning.
Vi har funderat på frågeställningar, vi har velat kombinera två frågeställningar som egentligen inte är totalt sammankopplade.
Vi ville dels undersöka binauralt ljud i spel; Vad kan spel tjäna om något på binaural ljudläggning, vilka spel skulle passa för denna, samt hur kan detta implementeras.
Våran andra frågeställning handlar om hur man kan påverka spelarens beslut med hjälp av ljudläggning, t.ex. vart han väljer att gå.
Det skulle även vara intressant att prova vad som händer när musiken får en plats i rummet, kan man få en effekt av att placera de olika instrumenten i rummet, eller till och med låta de individuealla tonerna få olika positioner runt spelaren, kanske helt dynamiskt.