Helvetes Forgård...
- Trådstarter H.R
- Startdato
Diskusjonstråd Se tråd i gallerivisning
-
Takker for det.
dette er første runde av ventehøyttalere. De krever sub men det har man heldigvis. Disse skal beholdes for å brukes igjen i et riktig rom.
Gutta dine er neppe så interessert i dra damer.
Jeg hater å måle - virkelig - dette er noe av det kjedeligste jeg vet. Så begynte å rote meg inn i hva en kan gjøre med API tilgang. Rew har et slikt. Motu har et slikt, og de fleste DAW har et slikt. Det begynte som det alltid gjør - man starter og ser på mulighetene, kommer til en blindvei og må over noen gjerder. Det er mange blindveier og gjerder..... Så nå har ting endret seg fra å bare måle til å lage et system som kan måle, analysere og optimalisere et aktivt høyttalersystem ved hjelp av REW, DSP-kontroll og AI-assistert analyse. Tanken er ikke at AI-en skal gjette seg frem til løsninger, men at den skal analysere faktiske målinger opp mot kjent akustisk teori og dokumentasjon fra blant annet REW.
I stedet for å bruke en tradisjonell DSP-enhet programmeres signalbehandlingen direkte i VST-plugins. Etter å ha møtt veggen utallige ganger fant jeg ut det var enklere å lage et VST plugin som har alt jeg trenger. Gain, delay, mute, fase, XO og EQ. Et felles tilgangspunkt som jobber med meg og ikke mot meg. Filtere, delay, gain, polaritet og annen signalbehandling styres automatisk og skrives direkte til pluginene. På den måten kan man bygge svært avanserte aktive delefiltre og DSP-løsninger uten å være bundet til spesifikk maskinvare. Siden jeg virkelig hater lukkede systemer så kan jeg eksportere data fra plugin til bla Pro-Q, få ut alle verdier som plugin holder og bruke de som jeg vil. Dette er nyttig siden jeg liker å se hva som skjer.
Parallelt jobber jeg med en egen lydmotor som på sikt skal fungere mer som en integrert del av Windows enn som en tradisjonell DAW. Tanken er at den skal kjøre som en tjeneste i bakgrunnen, omtrent som en driver eller systemtjeneste, slik at hele DSP-kjeden alltid er tilgjengelig uten at man må ha et DAW-program åpent. Målet er å kombinere fleksibiliteten fra studioverdenen med brukervennligheten til en dedikert DSP-prosessor.
Systemet måler driverne separat og analyserer blant annet:
- frekvensrespons
- fase
- impulsrespons
- group delay
- summering
- invert-null
- kanalbalanse
- timing og delay
En ting jeg synes mangler i mange automatiske løsninger er at de prøver å løse alt med EQ. Derfor er det også bygget inn logikk som vurderer om et problem faktisk skyldes høyttalerplassering eller rommet. Dersom systemet ser tydelige avvik mellom høyre og venstre side kan det foreslå å flytte en høyttaler, ta nye målinger og sammenligne resultatene før det begynner å korrigere med DSP.
I tillegg forklarer systemet hva det gjør underveis på et språk som er forståelig uten at man trenger å være REW-ekspert. Målet er at brukeren skal forstå hvorfor en løsning ble valgt, ikke bare få et resultat fra en svart boks.
Romkorreksjon er heller ikke tenkt løst av systemet alene. DSP-optimalisering av drivere og delefiltre skjer først, mens romkorreksjon kan legges på som et eget lag etterpå. Her fungerer ARC X svært godt og er derfor tenkt som en integrert del av løsningen for den siste finpussen mot lytteposisjon.
Det som kanskje er mest interessant er at systemet bygger opp historikk over tid. Jo flere målinger som gjøres i det samme rommet og på det samme anlegget, desto mer datagrunnlag får analysen. Da kan den etter hvert kombinere generell akustisk teori med erfaringer fra akkurat det rommet og det oppsettet. Målet er at analysene skal bli mer treffsikre over tid og at man skal trenge færre målinger for å komme frem til gode løsninger.
Prosjektet kommer i havn. Det bekymrer meg egentlig ikke. Da jeg startet var AI-modulen helt tom. Den er fortsatt laget med én oppgave: å analysere data og forklare resultatene på en menneskelig måte. Den bygger ikke på generell kunnskap eller ferdige fasitsvar, men på erfaringene den selv samler gjennom systemet den brukes i.
De siste dagene har jeg kjørt rundt 2000 målinger i døgnet for å lære opp systemet. Målet har vært å forstå hva REW faktisk måler, hvordan parameterne henger sammen, og hvordan de bør tolkes opp mot det som beskrives i dokumentasjonen. Samtidig lærer systemet mer om rommet det brukes i. God plassering av høyttalere kan ofte redusere behovet for DSP, og siden mer DSP gir lavere score i modellen, er dette en viktig del av optimaliseringen.
Mens maskinen har jobbet har jeg fått gjort helt andre ting. Jeg har klippet plenen, vasket kjøkkenet og kjørt flere lass til gjenvinningsstasjonen. Systemet står i praksis og lærer mens jeg gjør noe annet.
Nå begynner det å bli mye data, og jeg har fått på plass gode skript for å analysere de fleste parameterne. Selv om det fortsatt er langt igjen, har prosjektet passert proof-of-concept. Utfordringen er ikke lenger å få systemet til å fungere, men å få det til å måle smart. De fleste målingene så langt har egentlig handlet om å finne ut hvilke parametere som betyr noe, hvilke som betyr lite, og hvordan de bør vektes mot hverandre.
Grunnideen er enkel: parameterbasert scoring. Brukeren skal selv kunne velge hva som er viktig og hvordan ulike kriterier skal vektes. I stedet for å sitte og tolke et stort antall grafer, får man presentert de fem beste kandidatene sammen med en forklaring på hvorfor akkurat disse løsningene scorer høyest.
Om dette noen gang blir et produkt som kan distribueres, handler det først og fremst om investeringsvilje. Flere av bibliotekene som brukes i dag er gratis så lenge prosjektet er privat, men krever kommersielle lisenser dersom det skal selges. Som en som lever på statlig apanasje er ikke det nødvendigvis et naturlig neste steg.
Prosjektet har også tvunget fram noen tekniske valg. Erfaringen med plugins og komponenter som ikke lenger vedlikeholdes gjorde at jeg til slutt skrev en helt ny kontroller for lydkortet. I dag benyttes kun offisielle eller åpne grensesnitt: Roon sitt API mot Roon, REW sitt API mot målesystemet, OSC mot DAW-en og JSON-baserte grensesnitt mot lydkortet.
Frontend bygges med Blazor, noe som gjør det enkelt å lage dynamiske løsninger for mobil og nettbrett. Det åpner for at brukere kan få tilgang til egne soner og funksjoner uten å få tilgang til selve kjernesystemet. Målerutiner og avanserte funksjoner kan beskyttes med PIN-koder.
Et langsiktig mål er full plattformuavhengighet. I dag kjører DSP-delen på en Mac i et lukket system, men for å kunne bygge og distribuere installasjonspakker på en god måte trengs det etter hvert en nyere Mac Mini.
Når alt kommer til alt er prosjektet drevet av to ganske enkle behov. Det ene er å gjøre DSP-løsninger enklere og mer intuitive i daglig bruk. Det andre er at jeg egentlig ikke er spesielt interessert i å bruke tiden min på å måle. Derfor prøver jeg å bygge et system som kan gjøre mest mulig av den jobben selv, og samtidig forklare hvorfor det velger løsningene det gjør.
Det er kun kolonnene som er på høyre side som er i drift. Programmet her viser hva som skjer, hva man gjør og prosessen da det ikke er meningen å måtte forholde seg til alt som skjer, men få hovedtrekkene forklart. Målet her er at AI banken skal fylle seg opp og bruke rew sin online manual for å forklare enkelt hva som egentlig skjer.
En ting jeg har begynt å tenke mer og mer på er at det ikke nødvendigvis er så viktig å beskrive hele rommet i detalj for å forstå hvordan anlegget oppfører seg i et logisk rektangel/triangel En vanlig stue er sjelden firkantet. Det er møbler, bord, åpninger, vinkler og andre ting som gjør at det fort blir veldig komplisert dersom man skal forsøke å modellere alt.
I stedet prøver jeg å ta utgangspunkt i det som faktisk betyr noe for lyttingen, nemlig forholdet mellom høyttalerne og lytteposisjonen. Disse tre punktene danner et lyttriangel, og rundt dette etableres et logisk rektangel som systemet bruker som analyseområde.
Tanken er å måle i hjørnene av dette rektangelet, langs sidene og i punkter knyttet til lyttriangelet. På den måten får systemet et sett med referansepunkter som er enkle å gjenta og sammenligne over tid. Målet er ikke å kartlegge hver eneste detalj i rommet, men å bygge opp en forståelse av hvordan rommet oppfører seg der det faktisk har betydning for lyttingen.
Særlig under Schrøder-frekvensen er rommet ofte den dominerende faktoren. Ved å måle på disse faste punktene kan systemet gradvis danne seg et bilde av hvordan energi fordeler seg i rommet, hvor rommodene påvirker mest, og hvordan høyttalerplassering og lytteposisjon samhandler med rommet.
Etter hvert som det samles flere målinger fra det samme rommet kan systemet begynne å se mønstre. Kanskje en bestemt plassering alltid gir bedre symmetri mellom kanalene. Kanskje et område konsekvent gir en dip eller topp ved en bestemt frekvens. Kanskje en liten flytting av høyttalerne gir større gevinst enn omfattende EQ.
Grunnen til at jeg ønsker å gjøre det på denne måten er at mange løsninger hopper rett til korrigering. Jeg er mer interessert i å forstå hvorfor et problem oppstår før jeg prøver å rette det. Hvis årsaken er plassering eller romgeometri er det ofte bedre å løse det der først, og bruke DSP og romkorreksjon til finjustering etterpå.
Målet er derfor ikke å lære hvordan rommet ser ut i detalj, men å lære hvordan rommet oppfører seg sammen med akkurat dette anlegget. Jo flere målinger systemet får over tid, desto bedre blir forståelsen av hva som faktisk fungerer i akkurat det rommet. Da kan systemet etter hvert bruke både generell akustisk teori og erfaringer fra tidligere målinger til å gi mer presise forslag enn det en enkelt måling i lytteposisjon kan gjøre alene.
fant ut at det er for snevert å basere ai modellen til kun rew sin hjelp
Så nå er det implementert oppslag mot.
REW Help
Engineering Acoustics
Understanding Acoustics
Ai modellen er også kategorisk til å støtte seg til faktisk måling og oppslag til kjent teori. Siden modellen kjører lokalt så er det også lett å sette den til å bruke kildebasert kunnskap fremfor å klø meg på ryggen og si dette er bra når målingene sier annerledes.
Målet er å forstå hvorfor ting måleravvikende mellom kanaler, om det skjer, støtte seg til kjent teori og deretter informasjon om mulige veier. Man kan selvsagt ignorere alle råd og kjøre på, men igjen, dersom man kan plassere seg ut av uføret så er det å foretrekke fremfor å kjøre hard dsp bruk uten å egentlig gjøre annet en å flytte et problem. Dersom romnoder gjør at det alltid vil være problemer i et gitt område så skal dette området ikke korrigeres.
for å løse det under schrøder så vil systemet måle om man har to subwoofere som auto. Dvs først som stereo høyre og venstre, men også som dual mono og gå videre med det som summerer best i rommet fremfor å velge en løsning man har lyst på men som ikke virker like godt. Følelser har lett for å komme i veien for fornuften tross alt.
Hvor langt har jeg egentlig kommet?
Lenger enn jeg hadde trodd da jeg startet, og samtidig ikke i nærheten av ferdig, for programmet i seg selv samler data, historikk, forsøk. Kanskje fra disse høyttalerene, kanskje fra andre. Men systemet samler, strukturerer og ser på tvers av oppsettene som er innom rommet.
Det som kanskje har overrasket meg mest er hvor mange antakelser som har blitt utfordret underveis.
For en stund siden mente systemet at 429 Hz var det beste delingspunktet mellom mellombass og mellomtonehorn. Det så fornuftig ut på papiret og scoret bra på flere av parameterne som ble vurdert. Jeg ble selvsagt imponert over valget, for det virket svært presist. Med en sannsynlighet på hele 79.1% over er godt resultat tenkte jeg alt var i boks.
Problemet var bare at etter hvert som flere målinger, analyser og verifiseringer kom til, begynte bildet å endre seg. Selv om 429 Hz så bra ut isolert, viste det seg at integrasjonen mellom driverne faktisk ble bedre rundt 454 Hz. Ikke dramatisk bedre på én enkelt måling, men konsekvent bedre når hele beslutningsgrunnlaget ble vurdert.
Det samme har skjedd i toppen. Der har systemet etter mye testing og verifisering landet på 6757 Hz ,jeg ba den finne i et område mellom 7 og 12000. Likevel så kom 6757 frem med som det mest fornuftige delingspunktet mellom horn og diskant. Ikke fordi det er et pent tall, men fordi det ser ut til å gi den beste kombinasjonen av faseforhold, summering og integrasjon.
Hadde jeg satt meg ned med REW og gjort dette manuelt? Neppe.
Hadde jeg hatt tålmodighet til å teste hundrevis eller tusenvis av kombinasjoner rundt disse områdene, analysere dem opp mot hverandre og deretter gå tilbake og verifisere funnene flere ganger? - ikke en snøballs sjanse i helvete.
Og det er egentlig her jeg begynner å se verdien av prosjektet.
Maskinlæringsdelen erstatter ikke ørene mine, den erstatter ikke teorien og den erstatter ikke målingene. Men den har en arbeidskapasitet som er fullstendig urimelig sammenlignet med et menneske, og en egenutviklet ai modul passer på. Den tar ikke valg basert på følelser men basert på kilder og historikk.
Den blir ikke lei. Den blir ikke utålmodig. Den bestemmer seg ikke for at “430 Hz er sikkert nærme nok” fordi klokka er blitt halv ett om natta, ikke skal den se vi på fotball heller, blir ikke full og er lydig som en godt trent sauehund. , den jobber, tar ingen snarveier, tester analyserer og samler data for å finne en kombinasjon som henger sammen på en måte jeg aldri hadde giddet, og blir flinkere over tid når datagrunnlaget øker.
Den bare fortsetter å teste hypoteser til den finner ut hva dataene faktisk peker mot.
Det mest interessante er kanskje ikke at den finner svarene. Det mest interessante er at den av og til motbeviser ting jeg selv var ganske sikker på.
Det begynner å bli vanskelig å argumentere med en maskin som har sett flere målinger av anlegget mitt på en uke enn jeg har sett til sammen i mitt liv.
Jeg har fått første måling basert på denne metoden. Jeg holder nå på med å teste alle beslutninger opp mot rew, sjekke alle felter at den regner likt i pluginet og i dsp modulen. For arsenalet består ikke lenger av masse peq punkter, men implementerer alle metoder som er beskrevet her. https://www.w3.org/TR/audio-eq-cookbook/
Det er ok dessverre er godt stykke igjen før det kan skje gutman. Mye må verifiseres og det står på investering og der har jeg ikke så stort armslage etter jeg ble tatt ut av arbeidslivet. Er på stadie hvor jeg er fornøyd om jeg fremdeles har mat på bordet etter at alle regninger er betalt. Men det er fascinerende å se hva som er mulig å få til for en utdatert systemutvikler og at det går an å strukturere prosesser med moderne teknologi.
Da er en ny full test gjennomført.
Et av de mer interessante resultatene så langt er at fase, delay og kanalintegrasjon ser ut til å være godt under kontroll. Til tross for et rom med ganske kraftig asymmetri opprettholder systemet et presist og stabilt stereobilde, noe som tyder på at de største utfordringene ved lytteposisjon i stor grad er håndtert og det vesentlig bedre en jeg ville fått til.
så da kan jeg endelig begynne å jobbe med rapporteringsfunsjoner, visuell som tekst. Eksport av alle data over oppsettet til tekstfiler slik at ting er transparent og teste at apiet sender samme data til en dumpfil slik at man kan sende data direkte til andre løsninger om jeg skulle få brukt for det. Greit å teste når det faktisk er noe å teste før en utvikler resten av prosjektet.
Håvard har en hjerne som på enkelte områder ligger flere plan over gjennomsnittet her på sentralen.
Hva det sier eller betyr for oss andre her, har ikke jeg noe lyst å utdype, heller ikke mene noe om.
Var en kjapp tur innom casa Jessheim i kveld ifm. øvelseskjøring med kjerringa.
Her er en slem setup, med hjemmelaget DSP løsning som ikke finnes noe annet sted.
Det låter bedre nå enn da jeg sist var her.
Dette må du gå videre på Håvard, og jeg håper du kan få laget til noe som flere av oss her kan få glede av ta i bruk etterhvert.
Herfra til sluttbruker og kostnad er vel en vei videre i ukjent terreng foreløpig
Men jeg gir tommel opp så langt.
Hva gjør man når ting ikke virker som man selv mener det bør virke? Man lager det selv.
Siden jeg generelt liker at ting bare fungerer, er lett å vedlikeholde og ønsker at ting skal være lett å sette opp så bestemte jeg meg for å lage en egen DAW med matix. Dette som en egen service med et micro applikasjon som tillater en å få tilgang til mikrofonen i sikkerhetsinstillingene på maskinen. Det er flere grunner til det. Ene er at den kunne utvikles som en bakgrunnsservice til en gammel mac mini fra 2014 som har en eneste oppgave. Å kontrollere lydkortets DSP, lett bruk mao. Foreløpig har jeg ikke inkludert romkorreksjon pluginet da jeg må ta dette stegvis uten å miste kontrollen.
Jeg hadde jo allerede kontroll på komunikasjonen mot REW for å sette alle variabler til et VST plugin, så fremfor å bruke plugin så styres dette nå direkte i en service på mac'n
Så da får man input, men en irritasjon er jo at jeg ønsker ikke nødvendigvis å bare binde meg til en input, mer om det
Ved å kunne ha forskjellig input og output device åpner det seg for nye muligheter.
Siden Blackhole testen fungerer fint så blir det å lage virtuelle drivere til
Roon, Spotify og evt andre. Navnet skjemmer ingen og eneste forskjellen er navnet. Disse kan routes direkte til daw sin bus og de trenger lenger ikke inn i lydkortet siden jeg kan ta de via egne drivere.
Volumkontroll blir også like gjerne satt her - noe som sparer meg for mye arbeide ved å vedlikeholde Motu koblingen - men siden jeg vil sjekke med motu hvordan de har implementert volumkontrolleren, jeg mistenker digitalt, men skulle det være analogst så vil jo en link til dette være lett å sette opp.
Routingen er også enkel. Siden jeg allerede har konfigurert rew til å faktisk måle, så henter jeg innstillingene fra rew og setter dette i lydkortet, og jeg husker enda 3 minutter så jeg kan være klok å sette disse til det samme som i Arc X.
Inputs - jeg tester med 4 og outputs har jeg jo ikke mer en 8 av er rimelig enkelt å sette opp, for dette gjør jeg samtidig som jeg setter opp måleoppsettet i rew.
For ekstra input fra lydkortet så vil det komme flere - basert på inputs som er mulig å forholde seg til + roon og spotify.
Roon koblingen lager et plugin som holdes av daw slik at aktiverer man roon så aktiverer man plugin. Enkelt og greit.
Spotify krever nok litt mer arbeide siden der kan man ikke sette 48khz som egen output så der får en resample i selve core audio virtual driveren basert på hva output er satt til i lydkortet.
Selve navigeringen mellom alle flater gjøres via blazor apps som deler de data de trenger å dele.
Selve hjernen er core som passer på backup av alle seksjoner som er i bruk slik at man kan restore de der man skal bruke de senere. For har man først lært opp systemet i ML modulen så er det jo litt kjedelig å starte på scrach på opplæringsfronten da den vil fortsatt benytte vesentlig mer tid en runde 2 eller 3.
Jeg spiller på dette nå - og ting virker tilsynelatende som jeg forventer.Sist redigert:
volumkontrolleren i daw .
funksjonen er enkel - man måler alle kanaler i matrixen og dersom en av de når problematisk område så justeres max volum basert på det som faktisk spiller dynamisk fremfor å sitte med hjerte i halsen når det er fest.
Selve volumkontrollen vil bli en surface dial siden jeg har en slik. Den vil ha vanlig funksjon som volum, kildebytte og play pause i roon.
Fått koblet til Surface dial til macen og linket den opp til DAW via en service jeg laget for å omdanne dataen som dial sender.
Nå kan en endre volum fra dial selv uten å ha vinduet oppe - det er noe befriende når ting ikke er supportert i OS og en kan forbigå alt som står i veien.
Nitidig arbeide, bare det å få responsen til å bytte for så å holde flere ticks når den er i et kanalskifte krever at en faktisk sier at den skal gjøre det. Men det fine er at nå virker det mot roon, Nytt roon plugin er laget som genereres fra DAW, laget ny core audio virtual driver for å la Roon sende direkte til daw fremfor at en går gjennom lydkortet først.
neste ut er å lage en Spotify core audio, som jeg kan linke spotify til - da vil den kunne sende signaler til daw og en får dette opp som egen kilde.Dette er en funksjon jeg egentlig har savnet i eksisterende daw, siden routing av signaler inn fra kilder som forventer å sende alle til kanal 0 og 1 skaper alltid problemer for instans nummer to. Nå lager jeg bare en egen service til hver instans og kan paralellkjøre de inn i løsningen.
Så nå står surface dial, daw, lydkort, målesystem med rew på en og samme mac mini fra 2018 og den spiser ikke opp ressurser.
Siden visningen kan spittes opp er det ingen problem å ha surface dial nå på macen, vise ting på en pc, ipad eller annen webleser og en får frem menyene der man vil med kontroll fra et sted.
Gutman har lyst på en egen variant av visningen, jeg gjetter på intens AI bruk for generering av denne visningen men hva vet vel jeg? Paint kan jo være oppdatert siden sist jeg brukte det.
noe som faktisk er mulig selv om knapper og brytere egentlig bare er en skjer og om man finner seg en slik skjerm og bruker litt tid på å få den til å vise ting som vi ønsker, skjermer er tross alt hyllevare og de må jo ikke være i en utforming som selges på elkjøp tross alt.
ja - krever ikke mye ressurser i bruk så det holder i massevis når en ikke trenger å utvilke på den. Da går timene fort i ventetid
Laget en enkel oversikt over de servicer som faktisk brukes.
Siden spesielt spotify spiller til default så har jeg laget et endpoint som kan benyttes og sender via virtuelle drivere rett inn til daw.
Qobuz er enklere for den kan velge hvilke kilde man skal sende til så der velger man bare rett source. Roon er allerede under kontroll så der slipper jeg å gjøre annet en å fintune pakken til å spille feilfritt, men for det så har jeg satt på en del logger som faktisk viser alt det som skjer i driveren. Har man ikke roon, så har jeg laget en driver også for LMS som er et gratis godt alternativ.
Hver av disse går inn i daw bus og om de er aktivert som kilde så vil man kunne bruke disse. Siden man ikke skal bryte noen regler så vil webplayer fra Qobuz være ganske grei siden den tillater at man tar hele grensesnittet inn i egen frame på en nettleser, men for spotify er ikke dette tilfellet. Da må man bygge opp at man får visuelle flater over hva som spilles som cover, artist, sang og det som har relevans. Alle disse visningene er visninger - man må fremdeles velge hva man spiller i qobuz, spotify, roon og LMS i deres grensesnitt, men vi kan tillate å faktisk vise hva som skjer uten å bryte noen regler.
Håpet er at at Spotify skal kunne eksponere JAM på en måte at man kan ha en fast klient men jam funksjonen kan aktiveres der. Slik er det ikke nå.
Etter å ha brukt timer på å lage gode prober for å overvåke under runs, dvs pakke tap så fant jeg et buffer som pakket seg opp. Normalt skal ikke slikt skje men feilkoding skjer og det er lett å overse ting. Nuvel. Nå er det endelig på tid å sjekke stabilitet og det gjøres flere steder. En i core audio, en i daw input og en i daw output. Her skal det ikke være feil. La også opp en probe som sjekker cpu, minne og disk og skriver en log for hver 60 sekund for å se at ting ikke bygger seg opp over en langtidstest. Er det ikke stabilt i 12 timer så må det løses. Jeg har allerede laget en rutine som restarter services automatisk om det ikke er signal inn på daw over en periode på 30 minutter fra et intervall 4 ganger i timen. En service stopp og start er under 1 sekund og jeg mener det er en svært begrenset ulempe fremfor å måtte ta omstarter. Det siste en vil er at minne eller cpu skal øke over tid.
DAW ser stabil ut. Det er logget 500 målepunkter fra ca. 00:02 til 08:35, uten feilprøver.
Viktigste tall:
- NeuronDAW minne: startet ca. 261 MB, nå ca. 133 MB
- DAW minneområde: 108-261 MB
- Ingen tegn til minnelekkasje i DAW så langt
- DAW CPU snitt: ca. 4.4 %, maks 10.2 %
- Underflows: startet på 2, står fortsatt på 2
- Overflows: 0
- Audio engine: running
- Input og output har signal
coreaudiod: minne stabilt rundt 38 MB, men CPU rapporteres høyt i MacAgent, snitt ca. 81 %. Dette må vi følge, men det er ikke en minnelekkasje.
- RoonBridge: helt stabilt rundt 90.7 MB
- RAATServer: stabilt, ca. 57.1 -> 58.2 MB
- Surface Dial: lavt forbruk, ca. 4.5 -> 9.6 MB
- Node-tjenestene: ingen klar lekkasje; den største gikk ned fra ca. 211 MB til 128 MB
Etter litt polering så ser daw sitt vindu ganske så ryddig ut.
Om man ønsker å kilde rett fra daw så trykker man på den knappen som måtte være her. For volum så kan man ha og lagre hvordan man vil vise det.
Manuell slider og hva som har skjedd i controlleren. Følsomheten til surface dial velges også her og man får en visuell oversikt over følsomheten på hjulet
Man setter opp lydkkortet gjerne en gang og binder det opp til daw. Ingen grunn til å vise dette mer en nødvendig.
I profil finnes kun to profiler. En for måling og en for avspilling.
Når man setter måleprofil så vil en sette hvor mikrofonen er koblet til på lydkortet samt hvilke kanaler man skal lytte til for måling. I tillegg settes loopback kilden som brukes i rew. Når en skal måle skrus alle steder man man endre data av, slik at systemet jobber med et "låst" system uten påvirkning fra surface dial eller annet.
Kilder sorteres etter hva som er aktivt, rekkefølge på navigeringen og tilgjenglige kanaler som er valgt som input.
Disse er default lukket for enklere sortering men her setter man hvilke input kanaler disse skal ha.
Hver går automatisk til en bus, som er en kanal som selve DAW lytter til. Der muter eller unmuter man bus slik at man ikke får lyd fra flere kilder. Kun en bus kan være åpen av gangen.
I Output mapping setter man hvilke fysiske kanaler som er i bruk og viser hvilke xo som er i bruk.
Alle felter vil bli hentet opp fra når en måler og satt automatisk slik at man ikke trenger å sette dette mer en en gang.
Nå jobbes med backup av instillinger, at man får et sett med data som kan aktiveres på en annen datamaskin dersom DAW blir flyttet til en annen datamaskin.
Målet er å ha et flytende oppsett for alle instanser slik at man ikke blir bundet til at man bruker nettopp den maskinen senere. Hardware byttes og da må man enkelt kunne sette ting opp med de instillinger som kan resiruleres.
Etter backup blir det å lage en service for hver inputkanal som står aktiv. Dette øker stabilitet - koster lite i form av minne og cpu men reduserer komplikasjoner dersom man skal legge til en ny kildemulighet senere. Da dupliseres kun en hel sti og man får tilgang til denne uten å måtte huske hvordan man laget dette.
Backup vil bli som dette og er komplett.Man skal kunne låse en fil for reclycle slik at man kan gå tilbake til et kjent oppsett. Kanskje man har testet en annen Target og vil kunne sette dette frem og tilbake.
Foreløpig er hele programvaren på engelsk, ikke fordi det er så kult og internasjonalt, men det er lettere å lage en xml fil med norske navn senere en å styre med æøå som tar uforholdsmessig mye tid å holde på med. -
Laster inn…
Diskusjonstråd Se tråd i gallerivisning
-
Laster inn…