MUS2830 - Høst 2014

FLOOT - En fløyteinspirert granular synth for iOS

I min semesteroppgave har jeg forsøkt å lage digitalt elektronisk instrument som skal være intuitivt og enkelt å bruke, og som oppfordrer til spontan lek og eksperimentasjon. Instrumentet er laget som en prototype-app til iPhone, og jeg har forsøkt å benytte meg av de ulike typene inndatametodene som dette verktøyet tilbyr på en lettfattelig og morsom måte.

NB! En rekke begrensninger og bugs i MobMuPlat har gjort at brukergrensesnittet fungerer mindre enn optimalt, og følgende er viktig å vite for å bruke appen:

  1. Man må ‘swipe’ horisontalt for å skifte mellom skjermbildene.
  2. ‘setPage’-funksjonen virker ikke i landscape-format, så når man trykker på kontrollgrafknappen i avspillingsmodus, eller en av de forhåndsprogrammerte grafvalgene vil man ende opp ‘mellom’ to skjermbilder. Man må derfor ‘swipe’ for å komme til og fra disse på side 3 i appen.
  3. Det går ikke ann å spesifisere et ‘utvalg’ i samplegrafen automatisk fra PD, og man må derfor manuelt markere et nytt utvalg hver gang man har tatt opp en ny lyd.
  4. Man må holde telefonen flatt med skjermen opp når man aktiverer blåsefunksjonen for å få ‘tørr’ lyd uten effekter (dette er manglende kalibrering fra min side).
  5. Dersom du må blåse uforholdsmessig hardt for å få effekt kan du prøve å laste inn patchen på nytt, helst i stille omgivelser.
  6. Undo-funksjonen er buggy og bruker ganske lang tid.

Bakgrunn

Den opprinnelige ideen til instrumentet kom fra en kombinasjon av Ocarina-appen fra smule og det grafiske programmeringsspråket PureData. Ocarina-appen er en digital okarina (leirefløyte) og ved å blåse inn i mikrofonen og holde over fire virtuelle hull med fingrene kan man spile melodier på en måte som ligger nært opptil en ekte okarina. Ocarina er på alle måter et svært vellykket digitalt instrument. På den ene side er det en av de 20 mest nedlastede appene noensinne (smule.com, 2014). På den annen side representerer appen en tilfredsstillende løsning på problemet med forholdet handling-lyd i konstruksjonen av digitale instrumenter. Handling-lyd-relasjoner er et begrep Jensenius utvikler i sin doktoravhandling for å beskrive instrumenter hvor forholdet mellom handling og resulterende lyd ikke styres av uunngåelige og forutsigbare fysiske lover, typisk for elektroniske og digitale instrumenter (Jensenius 2007: kapittel 3). Med bakgrunn i forskning på lydpersepsjon påstår Jensenius at gode handling-lyd-design er nødt til å ta i  betraktning vår «ecological knowledge of action-sound couplings» (Jensenius 2007: 32). Dette gjelder enten man velger å gå for et praktisk design, som bygger direkte på disse forventningene, eller et kreativt som utfordrer og spiller på det uforutsette. I utviklingen av Ocarina har smule valgt et i høyeste grad praktisk design som ser seg fore å være brukervennlig og gjenkjennelig, en tilnærming Jensenius kritiserer for ofte å føre til kjedelige og uinspirerende instrumenter (dog 1.8 millioner nedlastinger kan påstås å utfordre dette synet i tilfellet Ocarina [xyo.net 2014]).

Den andre kilden til inspirasjon var programmeringsspråket PureData, og nærmere bestemt et objekt kalt array. Dette er en grafisk representasjon av innholdet i en tabell, og kan brukes til å lagre lydfiler, tallrekker eller andre typer digital informasjon. I PureData kan man også bruke musepekeren til å tegne direkte i disse grafene. Kombinerer du disse to elementene har du både kjernen av og målet med min applikasjon. FLOOT er et forsøk på å lage et digitalt blåseinstrument som er like intuitivt å bruke som Ocarina, hvor man ikke spiller toner på toner, men manipulerte lydopptak. Det er, for å hente terminologi fra Jensenius, et forsøk på å skape et eksperimentelt og kreativt konsept med et praktisk design (Jensenius 2007: 30).

Problemstilling

FLOOT baserer seg på såkalt granular syntese, en relativt avansert lydgenereingsmetode som tar utgangspunkt i et digitalt lydopptak. Det opprinnelige opptaket deles opp i ørsmå enheter – såkalte ‘grains’ – som videre manipuleres og avspilles på ulike måter for å skape lyder som kan ligge svært langt fra det opprinnelige opptaket. Denne formen for lydsyntese tar utgangspunkt i teknikker som for de fleste kan virke svært uforståelige, og mange instrumenter som baserer seg på denne typen lydsyntese krever mye spesialisert kunnskap og øvelse for å anvende. Derfor har en av de største utfordringene ved utviklingen av min app vært nettopp brukervennligheten, og å gjøre det mulig å anvende den på givende måter uten noen form for kunnskap. I arbeidet med å balansere det avanserte og kreative med det intuitive og tilfredsstillende har jeg fokusert på tre hovedaspekter. Jeg ville lage et instrument som lager spennende lyder samtidig som det låter bra; som er uforutsigbart, samtidig som det reagerer på forståelige og delvis kontrollerbare måter; og sist men ikke minst, som er selvforklarende. Prototypeappen er programmert i PureData og brukergrensesnittet er laget i MobMuPlat. Begge disse programmene har en del begrensninger som har fått konsekvenser for FLOOT, og noen av disse har jeg ikke klart å finne en tilfredsstillende løsning på. I løpet av denne oppgaven vil jeg derfor beskrive både hva jeg har gjort, hva jeg ikke har fått til, og hva som eventuelt gjenstår å gjøre.



Utforming og interaktivitet

Ettersom koden først og fremst kun er en måte å realisere ideen på vil jeg presentere brukergrensesnittet og selve instrumentet først. Modellen over brukes i Jensenius (2007) for å illustrere kjeden fra utøver til lyd i et akustisk instrument, men vil her fungere som et utgangspunkt for min beskrivelse av FLOOT. Lydproduksjonen i instrumentet består i to enkle stadier som reflekteres i skjermbildene under; lydopptak og avspilling, og det er grafene som utgjør kjernen i begge funksjonene.



Lydopptaket utgjør basisen for lydproduksjonen, og appen starter derfor i opptaksmodus. Her har man tilgang til tre funksjoner illustrert ved hver sin knapp; opptak av sample (runding), avspilling (trekant) og angre (sirkel-pil). I tillegg er man nødt til å dra fingeren over grafen for å markere utvalget av samplet som skal brukes. I den endelige appen skal dette illustreres tydeligere ved å ha synlige start og stop-markører i grafen, i tillegg til at utvalget automatisk skal settes til hele opptaket etter endt opptak. Dette har jeg ikke klart å finne en løsning på i MobMuPlat. I opptaksmodus har man følgende typer interaksjon.

Utøver-handling:

Feedback fra kontroller:

Feedback i form av lyd:

Som illustrert med pilene på høyre side er tanken at man skal kunne ‘dra’ hele brukergrensesnittet ned eller opp for å få tilgang til henholdsvis avspillings- og opptaksmodus, noe som heller ikke lar seg gjøre i MobMuPlat. Tanken er at den samme lyseblå ‘skjermen’ skal inneholde både lydopptaket og det jeg kaller ‘kontrollgrafen’, med den ene i forgrunnen avhengig av hvilket modus man befinner seg i. Istedet må man nå ‘dra’ sidelengs for å komme til avspillingsmodus på et eget skjermbilde.



Det er i avspillingsmodus de interessante lydskapende prosessene skjer. Som nevnt tidligere baserer FLOOT seg på en form for granular syntese, hvor det opprinnelige lydopptaket deles opp i mange bittesmå deler, såkalte ‘grains’ eller korn. Grafen i avspillingsmodus vil avgjøre i hvilken rekkefølge disse kornene avspilles, der posisjon på X-aksen vil representere tid og posisjon på Y-aksen avgjør hvilket korn som skal spilles av. Ved oppstart går grafen lineært fra nederst til venstre til øverst til høyre, og ved å trykke på ‘one-shot’ knappen øverst til høyre vil man høre utvalget avspilt normalt, og ved å endre på grafen vil man kunne ‘stokke om’ på rekkefølgen av kornene og ende opp med helt andre lyder. Ved å trykke på den graf-knappen (nummer to fra venstre) vil man komme til skjermbildet nedenfor, hvor man kan velge mellom fire forhåndsprogrammerte kontrollgrafer; forlengs, baklengs, fram-og-tilbake eller tilfeldig (Nok en gang er hensikten at dette skal foregå på ett og samme skjermbilde, noe jeg ikke fant en løsning på i MobMuPlat. Jeg ser også nå alt for sent at jeg her har brukt en tidligere versjon av appen i bakgrunnen). Det morsomste er likevel å tegne inn en kontrollgraf manuelt med fingeren.

Den tredje knappen, illustrert med et avspillingssymbol, aktiverer hovedfunksjonen til instrumentet, nemlig ‘blåse’funksjonen. Ved å aktivere denne vil applikasjonen begynne å tolke signalet fra mikrofonen som et kontrollsignal, og kontrollgrafen vil leses av i loop, i et tempo som avhenger av hvor hardt du blåser i mikrofonen. Den siste knappen har jeg kalt hold, og vil bli tilgjengelig når du aktiverer blåsefunksjonen. Denne knappen fungerer ved å innføre en ‘treghet’ eller ‘friksjon’ i avspillingen. I stedet for at hastigheten bestemmes direkte av intensiteten på inputen vil blåsemekanismen fungere som et fysisk kraft-system. Dette kan sammenliknes med gasspedalen i en bil; når du tråkker pedalen i bånn vil bilen bevege seg fortere og fortere fram til den når terminalfarten, og tilsvarende, når gassen slippes vil det ta en god stund før bilen stanser helt. På samme måte vil et konstant blåsetrykk i hold-modus akselerere avspillingen fram til den når sin ‘terminalfrekvens’, mens farten i fravær av blåsing vil falle sakte mot null.

I tillegg til å blåse og endre på grafen kan man forme lyden ved hjelp av fire enkle lydeffekter; klang og ekko, samt høypass- og lavpassfilter. Disse får man tilgang til ved å ‘tilte’ telefonen, og ved implementeringen av illustrerer en problemstilling jeg har nevnt tidligere, nemlig at instrumentdesign er nødt til å forholde seg til våre iboende forventninger angående lydproduserende handling. Hans T. Zeiner-Henriksen viser i sin doktoravhandling hvordan lyttere kan sies å forbinde høyfrekvente og lavfrekvente lyder med henholdsvis oppadgående og nedadgående bevegelser (2010). Dette merket jeg tydelig validiteten av da jeg i en tidligere versjon av appen ved en feiltakelse mappet ‘nedadgående’ tilting av telefonen til et høypassfilter – en oppadgående bevegelse i det resulterende frekvensspekteret. Dette opplevdes av både meg selv og de som testet applikasjonen som helt ‘feil’ og illustrerer en indirekte effekt av vår tidligere nevnte «ecological knowledge of action-sound couplings» (Jensenius 2007: 32).

I avspillingsmodus har man følgende interaksjonsmuligheter:

Utøver-handling:

Feedback fra kontroller:

Feeback i form av lyd:

Programmering

I det følgende vil jeg gå nærmere inn på programmeringen som ligger bak applikasjonen. Også her vil jeg bruke modellen fra tidligere som utgangspunkt for gjennomgangen, og påpeke hva som utgjør ‘mappingen’ mellom handling og kontrollsignal, kontrollsignal og lydproduksjon, samt de ulike feedbacktypene. Gjennomgangen vil bestå i skjermbilder av koden i PureData, samt korte kommentarer. Jeg vil påpeke at jeg har tenkt ut og laget all koden fra bunn av, kun med utgangspunkt i generelle beskrivelser av hvordan de ulike objektene fungerer. I noen enkelte tilfeller som vil understrekes har jeg også blitt inspirert av bestemte metoder for å løse problemer. Med unntak av reverb-modulen er ingenting kopiert fra andre steder. Dette har gjort hele prosessen svært omstendelig, og enkelte løsninger kan nok kritiseres for å være for kompliserte, men jeg har til gjengjeld lært enormt mye mer enn jeg ville gjort ved å kopiere andres løsninger. Under har jeg delt opp koden i opptaksmekanisme, lydproduksjon og feedback/brukergrensesnitt.

Opptaksmekanisme

Hovedopptak



Bufferopptak/angrefunksjon

 

Avspillingsmekanismer/lydproduserende kode

Oversikt

 

Her genereres en såkalt hanningkurve, som jeg bruker til å unngå klikkelyder og resulterende støy i avspillingen. Dette er en vanlig metode innenfor granular syntese, og min implementasjon er inspirert av Johannes Kreidler (2009).

Blåsemekanismen



Dette er den viktigste delen av koden, og også den som har tatt desidert lengst tid. Før jeg kom fram til den nåværende løsningen med inndeling og avspilling av korn, altså mindre grupper av samples, brukte jeg kontrollgrafen til å lese direkte fra samplefila. Dette gikk OK dersom fila ble lest i normalt tempo forlengs eller baklengs, men ble støyende ved brå eller trege endringer, og ubrukelig dersom man forsøkte å få en konstant tone ved å tegne en horisontal rett kontrollgraf. Løsningen ble altså å dele opp avlesningen i grupper av samples, slik at én verdi motatt fra kontrollgrafen utløser en avlesning av tilsvarende samt en viss mengde etterfølgende samples fra lydfila. Som man ser i koden brukes hastighetsvariabelen fra innblåsingen til å styre avlesningen av kontrollgrafen som feeder inn i to parallelle sampholdobjekter. Disse objektene sender ut den aktuelle verdien annenhver gang, med mellomrom avgjort av et phasorobjekt, som også styres av hastighetsvariabelen. I stedet for at kontrollgrafen leser av sampelet direkte vil det nevnte phasorobjekte starte avlesningen ved den aktuelle verdien angitt av kontrollgrafen, og så fortsette et visst stykke i et tempo avgjort av hastighetsvariabelen, før det begynner på nytt fra den neste verdien som mottas fra kontrollgrafen. Direkte vil dette medføre i mye klikk og støy, men ettersom disse hoppene alltid skjer i motsatt fase kan man modulere amplituden ved hjelp av førnevnte hanningkurve, og på den måten vil summen av de to kjedene bli et jevnt signal uten klikkelyder.

OneShot



Dette er en enklere utgave av den forrige patchen, ettersom tempoet er fast avhengig av lengden på utvalget, og avspillingen trigget av et tastetrykk.

Forhondslytting på sampleutvalg



Dette er den enkleste avspillingsmekanismen, og er en direkte avspilling av det markerte området i opptaket.

Lydeffekter



Dette er koden til lydeffektene som styres ved å tilte telefonen i blåsemodus. Reverbpatchen er kopiert fra Scott Nordlund (2011), med enkelte modifikasjoner for å tilpasse den til Pd-0.45-4-vanillaForMobMuPlat. Dette gjelder først og fremst erstatting av avanserte filtere og enkelte sin~ objekter. Denne har også stereo output, noe jeg har valgt å benytte meg av i tilfelle man bruker appen med hodetelefoner.

Feedback/brukergrensesnitt

Her har jeg også valgt å dele inn koden i opptak og avspilling. Alle knappene ligger for enkelhets skyld under avspilling

Opptak



I MobMuPlat mottas informasjonen fra Meter-patchene av et LCD-objekt som ligger bak en maskering med et mikrofon- og ‘blåseformet’ hull, slik at ikonet endrer farge i takt med volumet på input.

Avspilling



Jeg har forsøkt å lage et UZI-objekt tilsvarende det som finnes i Pd-Extended, men har kun klart å lage et som er begrenset til samplehastigheten.



Alle knappene er tegnet direkte inn på bakgrunnen i MobMuPlat. Over hver knapp har jeg lagt inn et bildepanel, og over det har jeg lagt inn usynlige trykkeknapper. Hver gang en knapp trykkes inn vil det lastes inn en hvit og delvis gjennomsiktig .png fil i det respektive panelet, slik at det oppleves som om knappen reagerer på berøring. Videre har jeg som nevnt valgt å skyggelegge hold og play-knappene når de ikke er i bruk for å tydeliggjøre hvordan de skal brukes for sluttbrukeren



Brukertester

Ettersom jeg har satt meg fore å lage et brukervennlig og intuitivt forståelig instrument har jeg også benyttet meg av uformelle brukertester i utviklingen. Testpanelet har bestått av min ti år gamle bror og en 23 år gammel person uten musikalsk bakgrunn, og observasjon og deres kommentarer kom jeg fram til følgende liste med problemer:

Noen av disse problemene mener jeg å ha løst, noen lar seg som nevnt ikke løse med de verktøyene jeg har tilgjengelig, og andre igjen vil jeg foreslå mulige løsninger på helt til slutt.

Iverksatte løsninger

Et av problemene som ble nevnt var forvirrende ikoner. Det gikk først og fremst på at jeg tidligere brukte et Play-ikon for OneShot-funksjonen, mens jeg hadde en typisk av/på- knapp for å aktivere blåsefunksjonen. I tillegg var hold-knappen alltid grønn, uten at den hadde noen funksjon når blåsefunksjonen var av. Alt dette ble oppfattet som forvirrende av brukerne, som brukte svært lang tid før de i det hele tatt prøvde å trykke på On/Off- knappen. Forhåpentligvis vil play-knappen være mer fristende, i tillegg til at den visuelle feedbacken ved å skyggelegge hold-knappen vil tydeliggjøre når den har en funksjon. Å flytte play fra oneshot til av/på tydeliggjør også hvilken av disse som ansees som viktigst. I tillegg til dette har jeg en rekke andre ideer som går på feedback som vil gjøre alle slike funksjoner langt mer forståelige, noe jeg kommer tilbake til snart.

Framtidige endringer

Mesteparten av problemene føler jeg likevel at best lar seg løse med mekanismer jeg ikke har klart å realisere innenfor MobMuPlat sine rammer. Disse går hovedsaklig på visuell feedback og tydeliggjøring av hva som til enhver tid skjer. Den viktigste løsningen i så måte vil være playhead og markering av avspilling. Slik jeg har gjort det nå har jeg brukt sliders som synes såvidt over og under og på siden av grafene, ettersom disse ble altfor dominerende og stygge å ha foran. For det første ville jeg ha lagt til smale og vertikale spillehoder som visualiserer avspillingen av utvalget, både i opptak og avspillingsmodus. Dernest ville jeg ha gjort slik at det som syntes i bakgrunnen av kontrollgrafen var en innzoomet versjon av markeringen, slik at spillehodet kunne bevege seg over hele grafen. Det aller viktigste ville likevel være å snu kontrollgrafen 90 grader, slik at en horisontal verdi på kontrollgrafen faktisk tilsvarte en horisontal posisjon i bølgeformen. Dette kunne markeres ved å ha en prikk eller liknende markør som beveget seg vertikalt igjennom kontrollgrafen og dermed fulgte avspillingshodets bevegelser i bølgeformen. Dette har jeg illustrert under.

 

Videre ville jeg ha implementert flyttbare start og slutt-markører i opptaksvinduet. Disse skulle automatisk bli satt til å omfatte hele sampelet ved nytt opptak, noe som ikke er mulig i denne versjonen av mobmuplat.



Effektbruken har jeg ikke funnet en tilfredsstillende løsning på, men jeg kan tenke meg at man kan implementere en slags steg-for-steg gjennomgang slik man ofte ser i internettspill ved første gangs bruk av applikasjonen. Her kunne man blitt guidet gjennom prosessen,  og ting som at telefonen må beveges for å skru av og på effekter kunne blitt påpekt. Andre ting som krever finpuss er feedbackkontroll, ettersom det fortsatt hender at volumet fra høyttalern tolkes som blåsing i mikrofonen, spesielt ved bruk av hold-knappen og effekter. I tillegg må designet finpusses og feedbacken gjøres enda penere og mer inspirerende.

Til slutt vil jeg nevne muligheten for å ha to ulike versjoner av appen, hvor man eksempelvis kan kreve ekstra penger for å gi brukeren tilgang til konfigurasjon av effekter, minnefunksjon og presets, kvantifiserbar hastighet som kan brukes til å spille toner, eventuell midi implementering m.m.

Patcher