Beskrivelse av semesteroppgave (Lydprogrammering 2)
Hovedidéen bak denne patchen er at den skal fungere som aktiv medspiller i en improvisasjon/komposisjon. For at dette skal fungere må max ikke bare kunne gi fra seg lyd, men også forstå lyd for å ha noe spesifikt å basere musikken på.
Patchen har fire viktige roller...:
1.Lydanalyse
Ved hjelp av analyzer~ får max informasjon ulike parametre fra audio. I denne patchen bruker jeg informasjon om frekvenser og anslag. Noe data lagres til senere bruk, annet brukes umiddelbart etter at informasjonen er tatt opp.
2.Opptak
Tar opp lyd og lagrer det til senere bruk.
3.Bearbeidelse
Den lagrede dataen blir brukt som basis for improvisasjon.
4.Forstå innhold i lyden og kunne reagere når den kjenner igjen begivenheter
....og fem «instrumenter»:
1.Opptak/avspill/lydarkiv
Tar opp audio og spiller det av enten automatisk eller manuelt. Lydarkivet tar opp lyd fra store deler av fremførelsen, mens opptak/avspill konsentrerer seg om bruddstykker.
2.Etterligning
Bruker informasjon om frekvenser til å etterligne det som blir spilt. Lagrer frekvenser i en musikalsk frase og spiller dem av automatisk etter at frasen er ferdigspilt. Hver tone trigges av enten tempo-objektet (første eller alle trinn), samtidig med utvalgte trommelyder eller via anslags-detektoren på anlyzer~ (som kan trigges både med et instrument og med opptak/avspill)
3.Autoimprovisator, melodi
Bruker informasjon om frekvenser for improvisasjon. Trigges på samme måte som etterligning.
4.Autoimprovisator, akkorder
Samme som punkt tre, men med flere stemmer. Trigges på samme måte som etterligning.
5.Frekvenstrommer
Tromme-etterligning ved hjelp av sinustoner og frekvensmodulasjon. Er tilkoblet tempo-objektet og et objekt som genererer tilfeldig rytme (ikke-metriske, multitemporale rytmer).
For punktene 2 til 6 har jeg også lagt inn mulighet for å «avbryte» all trigging som foregår fra tempo-objektet eller de tilfeldige rytmene. Denne triggingen vil opphøre så snart analyzer~ rapporterer anslag, og starter så snart det har gått 400 ms uten at noe mer skjer.
En av de store utfordringene ved byggingen av patchen var variasjon og musikalsk flyt i et nokså ikke-lineært programmeringsspråk som max er. Jeg forsøkte å løse dette ved å legge til to preset-objekter (neste identiske, men med en betydninsfull forskjell, som vi skal se) hvor det er lagret 13 programmerte settinger. Det nederste preset-objektet opereres manuelt, mens det øverste kan opereres automatisk. Den store forskjellen mellom de to er at det øverste preset-objektet i alle settinger er tillagt mulighet for deteksjon av siste tone i en tonerekke (subpatchen «sistetone») ved hjelp av Karlheinz Essls «last»-objekt. Nå er dette primitive scorefollowing-elementet kun på prøvestadiet, og jeg har lagt til mulighet for å forandre preset med forskjellige toner. Ulempen ved dette systemet er at det kan virke alt for følsomt når man ikke søker å forandre preset, og alt for ufølsomt ellers.
For å slippe for mange gate/switch/selector-objekter og med tanke på å forenkle brukergrensesnittet har jeg valgt å bruke matrixctrl/router/matrix~ for å route signalene. En mulighet ved routing av max-signalene ville vært å bruke én matrix, men jeg anså det for mer praktisk og brukervennlig å sette inn en matrix for signaler med samme rolle. For eksempel har jeg lagt til én matrix for å route midi-informasjon til «etterligning», «autoimprovisatør melodi» og «autoimprovisator akkorder», og én matrix for å route trigging til de samme boksene.
Problemer:
- Automatisk avspilling av «rec/avspilling» er pålitelig, men det kommer ikke alltid lyd.
- «Grooveduck» fungerer bare halvveis, og det resulterer enten i noe klikking eller forkorting av samplet.
- Får ikke gjemt objekter som kun skal vises i presantasjons-modus.
- Patchen bruker mye cpu.
- Lagring av midi-informasjon i de tre melodiske subpatchene kan være ustabil.