Helvetes Forgård...

[Chalshus]

Hyggelig gjensyn.

 

[H.R]

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.

 

[Bergfinn]

Kommer snart innom med denne.
Ingen spiller på den.
Umotiverte sløfokker av noen kids jeg har.

Men fetter'n demses testa den litt da.

 

[H.R]

Gutta dine er neppe så interessert i dra damer.

 

[H.R]

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

I stedet for å prøve seg frem med hundrevis av målinger forsøker systemet først å bygge en modell av hvordan driverne oppfører seg og finne de mest sannsynlige løsningene før det gjør nye målinger.

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.

 

[ragwo]

Hvis du drar dette prosjektet i land stiller jeg meg i kø for å kjøpe et eksemplar hvis du velger å kommersialisere det. Imponerende ambisjoner!

 

[H.R]

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.

 

[H.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.

 

[H.R]

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.

 

[H.R]

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/

 

[gut_man]

Dette blir så sinnsykt bra! Gleder meg til å teste når tiden/Neuron er moden.

 

[Bergfinn]

Håvard, jeg tror du har kommet i en beyund AI modus som ikke kan reverseres.

.....og godt er det.

 

[H.R]

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.

 

[H.R]

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.

 

[Bergfinn]

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.

 

[H.R]

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.

 

[H.R]

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.

 

[H.R]

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.

 

[oks81]

2018? Er vel en 2014 macmini.

 

[H.R]

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

 

[H.R]

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å.

 

[H.R]

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.

 

[H.R]

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

Andre prosesser:
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

Konklusjon: DAW build 0.2 / 93 ser stabil ut så langt. Det viktigste er at underflows ikke øker, overflows er null, og DAW-minnet ikke vokser. Monitoren kjører fortsatt og logger videre her:

 

[Sorzy]

Veldig interessant software-prosjekt du har på gang her, følger nøye med videre

 

[H.R]

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.

 

[H.R]

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.

 

[H.R]

Når man rydder kan man like gjerne gjøre det ordentlig så jeg fant ut at jeg kunne forenkle grensesnittet ytterligere og dermed redusere feilkilder til et minimum.

Fjernet muligheten fullstendig fra å kunne justere noe i daw direkte og har heller flyttet ut i logiske grupper til wizard.
Alle wizards er låst med selvvalgt pin slik at det ikke lar seg konfigurere uten.

Når man har gjennomført dette er rew klar til å måle men man må også gå gjennom oppsettet for høyttalere selvsagt. Samme logikk for å sette opp. Et spørsmål, et svar.
Når dette er gjennomført så vil alle kanaler være mutet siden det ikke finnes noen safe route så man vil i dawfå varsel om at lyd ut er blokkert.

Det er helt korrekt adferd da man har ikke målt og dermed satt opp systemet som helhet.

Etter gjennomført måling og dermed også gitt alle utgangene data nok til å fungere så fylles data inn og systemet kan brukes til å spille musikk.

 

[H.R]

Brukt litt tid for å trekke skjermkortet inn slik at man får evaluert lenger og ta bedre beslutninger i ML modulen. Så da var det på sin plass å lære den hele rew manualen på nytt, forstå alle API kommandoer og til slutt kunne danne et grunnlag på flere parametere samtidig. Så det medførte at jeg kunne allokere datakraft på en mer rasjonell måte og ta i bruk asynkron tjenester. Det starter med en serie målinger og hver måling blir lagret eller forkastet avhengig av kvalitet på målingene. Deretter så begynner jo den nitidige nåla i høystakken. Hva er rett, hva er lurt. Hvor er det best egnet å gjøre noe og hva er kostnaden med nettopp dette valget.

Optimaliseringsalgoritmen skal ikke kun optimalisere mot frekvensrespons eller lokal summering. Den skal være en flerobjektiv optimalisering hvor amplituderespons, fase, gruppedelay, impulsrespons og stereointegritet vurderes samtidig.

Følgende tekniske prinsipper skal ligge til grunn:

* Maksimal fasekoherens mellom venstre og høyre kanal skal bevares gjennom hele signalveien.
* Differensielt gruppedelay mellom kanalene skal minimeres over hele arbeidsområdet.
* Impulsresponsen skal bevares med minst mulig tidsmessig smøring.
* Filtervalg skal gi lavest mulig faseforvrengning samtidig som ønsket amplituderespons oppnås.
* Asymmetrisk EQ, delay eller filtrering mellom kanalene skal kun benyttes når det er dokumentert nødvendig og gir en målbar forbedring.
* Små forbedringer i amplituderespons skal ikke prioriteres dersom de medfører større degradering av fasekoherens, gruppedelay eller impulsrespons.
* Ved flere løsninger med tilnærmet lik amplituderespons skal løsningen med høyest fasekoherens, lavest differensielt gruppedelay og best bevart impulsrespons velges.
* Optimalisering skal utføres på den totale systemresponsen, ikke kun på enkeltparametere isolert.
* Alle optimaliseringstrinn skal evalueres mot en samlet kostnadsfunksjon hvor amplitudefeil, fasefeil, gruppedelay, impulsrespons og kanalkoherens inngår med eksplisitte vekter.
* Ingen enkeltparameter skal kunne forbedres vesentlig dersom dette gir en større samlet degradering av systemets totale ytelse.
* Dersom en endring forbedrer én parameter, men forringer flere andre, skal den totale kostnadsfunksjonen avgjøre om endringen aksepteres.
* Algoritmen skal søke den løsningen som gir høyest samlet teknisk kvalitet fremfor best resultat på én enkelt måleparameter.


Etter en lang dag med opplæring så kan det være at jeg får et resultat basert på disse linjene i løpet av natten. Forrige runde endte i katastrofe mens den før var svært oppløftende. Jeg vet hvorfor den forrige ble så dårlig så da er det greit nok selv om skuffelsen var stor når jeg så rapporten og ikke minst hørte på resultater.

 

[H.R]

Jaja. Blitt en del ML optimalisering som ikke har gitt ønsket resultat. Så da er det bare å utvide med bedre verktøy, så hentet inn NumPy og SciPy. Forholdsvis kjedelige ting men egner seg godt når en skal få beregnet ting fort i gpu og ta kontroll over utregninger. Datakraften tåler uansett ufattelig mye mer å gjøre for at man skal kunne se at den jobber i oppgavebehandlerem. Det ville være enklere å tvinge frem en forhåndsdefinert xo og tvinge frem delinger med de ulemper som dette gir men dersom dette var målet måtte jeg også akseptere at det er den raskeste måten å oppnå resultat på men neppe den mest optimale.

Mye tekst, men om noen skulle gidde å lese hvordan beslutninger tas pr nå, selv om jeg vet det helt sikkert kommer revisjoner, så er der bare å lese videre. Anser det som et metodedokument som er tungt og kjedelig lesestoff dog og helt uten bilder eller grafer med fjonge fossefall eller annet som bryter med en eviglang tekst.


En deterministisk ML/DSP-motor for høyttaleroptimalisering basert på råmålinger fra REW og beregninger i NumPy/SciPy. Motoren skal finne og verifisere optimalt delepunkt, XO-slope, delay, gain, polaritet/fase, EQ, venstre/høyre-symmetri, romhåndtering, stereosenter og origojustering. ML kan foreslå søkeområder, vekting og strategier, men alle beslutninger skal verifiseres matematisk fra måledata. Motoren skal ikke være en “smart kurveutjevner”; den skal være en etterprøvbar akustisk beregningsmotor.



Grunnregel: Ingen endring skal godkjennes bare fordi frekvenskurven ser penere ut. En kandidat må forbedre eller bevare kompleks summering, fase, invertert null, group delay, headroom, driverstress, forvrengning, powerrespons, L/R-symmetri, stereosenter og origo-konsistens.

1. Obligatorisk målegrunnlag

Start alltid med råmålinger uten EQ, uten delay og uten delefilter dersom mulig. Hver driver må måles separat i REW med samme mikrofonposisjon, samme sample rate, samme timing reference og samme gainstruktur. Rådata skal aldri overskrives.



For hver måling skal følgende metadata lagres:



measurement_id, session_id, timestamp, sample_rate, bit_depth, REW_export_type, mic_id, mic_calibration_file, mic_position_id, mic_x, mic_y, mic_z, speaker_side, driver_id, physical_channel, DSP_channel, amp_channel, polarity_state, gain_state_db, delay_state_ms, filter_state, EQ_state, sweep_level_db, estimated_SPL, timing_reference_type, timing_reference_channel, gate_start_ms, gate_end_ms, window_type, smoothing_state, valid_from_hz, valid_to_hz, noise_floor_db, SNR_by_band, clipping_detected, routing_verified, polarity_verified og confidence_score.



Dersom nødvendig metadata mangler, skal motoren redusere confidence eller stoppe automatisk optimalisering.

1. Kompleks respons som kjerneformat

Alle beregninger skal baseres på kompleks frekvensrespons:



magnitude_linear(f) = 10^(magnitude_db(f) / 20)



phase_rad(f) = unwrap(deg2rad(phase_deg(f)))



H(f) = magnitude_linear(f) * exp(j * phase_rad(f))



Dersom impulsrespons brukes:



H(f) = FFT{h(t)}



Alle drivere skal interpoleres til felles frekvensakse. Interpolasjon skal gjøres på kompleks respons eller separat på log-magnitude og unwrapped fase. Wrapped fase skal aldri brukes direkte til delay, group delay eller summering.

1. Parametre som alltid skal beregnes

For hver driver, hver side og hver fullrange-sum skal motoren beregne:



magnitude_db(f), unwrapped phase, excess phase hvis mulig, group delay, minimum-phase-estimat, excess group delay, impulse peak time, band-limited arrival time, energy time curve, step response, RMS level by band, peak level by band, crest factor, SNR by band, noise floor by band, valid frequency range, direct sound confidence, room dominance confidence, headroom margin, driver stress index og measurement quality score.



Motoren skal ikke anta at impulspeak alene er korrekt akustisk ankomsttid. For hver driver skal det beregnes band-limited arrival time i driverens faktiske arbeidsområde.

1. Målekvalitet og forkastingsregler

Før optimalisering skal motoren kontrollere:



routing, kanal-ID, polaritet, sample rate, timing reference, SNR, clipping, impulsstart, fasekontinuitet, gyldig frekvensområde, støy, målevindu/gating og om målingen dekker nødvendig overlapp.



Målingen skal forkastes eller gis lav confidence dersom:



SNR er for lav i overlappet, fase hopper unaturlig, impulsresponsen er trunkert, routing er ukjent, polaritet er ukjent, REW-export er ufullstendig, målingen har clipping, eller frekvensresponsen har hull som ikke kan forklares akustisk.

1. Gyldig overlapp og kandidatfelt

For driverpar A/B skal motoren finne gyldig overlapp basert på:



målt respons, SNR, driverens trygge arbeidsområde, forvrengning, direktivitet, powerrespons, membranoppbrytning, horn/waveguide-loading, termisk/mekanisk margin, romdominans og ønsket systemmål.



Kandidatområdet skal ikke bare være der kurvene krysser hverandre. For hver mulig delefrekvens skal motoren analysere et vindu rundt delefrekvensen, typisk ±0.5 til ±1 oktav.

1. XO-kandidater

Motoren skal teste:



delefrekvens, filtertype, slope, delay, gain og polaritet.



Minimum filterkandidater:



LR2, LR4, LR8, Butterworth 2/4/8 og asymmetrisk slope der det er akustisk begrunnet.



LR4 er standard startkandidat, men motoren skal velge ut fra målt akustisk resultat, ikke forhåndsvalg.



Filterrespons beregnes som kompleks respons:



H_driver_filtered(f) = H_driver_measured(f) * H_filter(f)



Normal sum:



H_sum(f) = H_A(f) + H_B(f)



Invertert test:



H_null(f) = H_A(f) - H_B(f)

1. Delay-beregning

Delay skal beregnes med flere metoder:



impulsbasert ankomst, bandbegrenset impuls, fasehelling, group delay, cross-correlation og sum-/null-optimalisering.



Delay i frekvensdomenet implementeres som:



H_delayed(f) = H(f) * exp(-j * 2π * f * delay_seconds)



Søket skal først være grovt og deretter fint. Typisk:



sub/mid: bredt søk, for eksempel ±20 ms

mid/horn/diskant: smalere søk, for eksempel ±5 ms

grov oppløsning: 0.05–0.1 ms

fin oppløsning: 0.005–0.02 ms



Ingen enkeltmetode er fasit. Motoren skal beregne delay_confidence fra samsvar mellom impuls, fase, group delay, normal sum og invertert null.



Praktisk DSP-delay kan ikke være negativ. Etter relativ delayoptimalisering skal alle kanaler normaliseres slik at tidligste akustiske kanal får 0 ms praktisk delay, og andre kanaler får positiv delay. Den relative origo-modellen skal likevel beholdes.

1. Fasekrav i deleområdet

Relativ fase beregnes som:



phase_diff(f) = unwrap(angle(H_A(f))) - unwrap(angle(H_B(f)))



Fase skal vurderes over et bånd rundt delefrekvensen, ikke bare i ett punkt.



Veiledende akseptgrenser:



ideelt: nær 0° relativ fasefeil ved Linkwitz-Riley akustisk mål

meget godt: innen ±15° rundt delefrekvens

akseptabelt: innen ±30° dersom normal sum, invertert null og robusthet er gode

betinget: ±30–45° bare dersom sum og null fortsatt er gode

ikke godkjent: over ±45° dersom dette gir dip, lobing, dårlig null eller ustabil sum



Motoren skal beregne:



phase_error_at_fx, mean_phase_error_around_fx, max_phase_error_around_fx, phase_slope_error, group_delay_difference og phase_robustness_score.



Fase kan aldri godkjennes alene. Den må stemme med normal sum og invertert null.

1. Invertert null

Invertert null brukes som verifikasjon, ikke som eneste mål.



Motoren skal beregne:



null_depth_at_fx, mean_null_depth_around_fx, null_width_octaves, null_center_frequency, null_symmetry og null_robustness.



En god null skal være dyp nok, bred nok, sentrert nok og samsvare med god normal sum. En smal tilfeldig null skal ikke overbelønnes.

1. Gain-styring

Driver-gain justeres før EQ. Gain er grov energibalanse, ikke et verktøy for å skjule lokale feil.



For driver D:



level_D = weighted_mean_db(|H_D(f)|, valid_band_D)



gain_needed_db = target_level_db - level_D



Gain skal beregnes over gyldig arbeidsområde, ikke fra én frekvens. Vekt lavere nær delefilterflanker, romdipper, lav SNR og utenfor trygt arbeidsområde.



Etter gainendring skal motoren alltid re-sjekke:



normal sum, invertert null, fase, headroom, driverstress, L/R-balanse og origo-tid.



Hvis gainendringen er stor, skal delay re-sjekkes lokalt rundt eksisterende verdi.

1. EQ-strategi

EQ skal bare brukes etter at gain, delefilter, delay, polaritet og origo er stabile.



Målet er kontrollert respons etter target-kurve, ikke matematisk flathet. Target kan være brukerdefinert eller Harman-inspirert med romtilpasset bass og lett fallende energi mot toppen.



EQ-feil beregnes som:



error_db(f) = target_db(f) - measured_db(f)



Før EQ skal avvik klassifiseres som:



bred tonal ubalanse, minimum-phase peak, minimum-phase resonans, rommode, romnull, refleksjonskamfilter, driveroppbrytning, direktivitetsproblem, målefeil, L/R-asymmetri eller XO/fasefeil.



Kun egnede avvik skal EQ-korrigeres. Dype romnuller, ikke-minimum-phase dipper, kamfilter og direktivitetsfall skal ikke boostes.

1. EQ-filtertyper og filtermodell

EQ-modulen skal støtte Pro-Q-lignende parametriske metoder:



bell, low shelf, high shelf, tilt shelf, notch, bandpass, highpass, lowpass, allpass, per-driver EQ, per-side EQ, global voicing EQ og senere eventuell dynamisk EQ.



Hvert filterobjekt skal inneholde:



filter_id, filter_type, frequency_hz, gain_db, Q, slope hvis relevant, channel_scope, driver_scope, phase_mode, enabled, reason, confidence, pre_score, post_score, headroom_cost, phase_cost, group_delay_cost, distortion_cost, power_response_cost, room_likelihood og minimum_phase_likelihood.



Total EQ:



H_EQ_total(f) = Π H_EQ_i(f)



Simulert respons etter EQ:



H_after(f) = H_before(f) * H_EQ_total(f)

1. Q-håndtering

Q skal velges etter årsak, ikke for å pynte kurven.



Veiledende:



bred tonal justering: Q 0.3–1.0

vanlig bred PEQ: Q 0.7–2.0

lokal peak/resonans: Q 2–6

smal notch: Q 6–12 bare ved stabil resonans

Q over 12 krever høy confidence og validering

høy-Q boost skal normalt forbys

smal boost i dip skal forbys uten minimum-phase-bevis og flerposisjonsstabilitet



Q kan beregnes fra båndbredde:



Q = f_center / bandwidth_hz



Hvert filter skal vurderes for ringing, group delay impact, time-domain smearing og phase rotation.

1. Minimum-phase-test

Før presis EQ eller boost skal motoren vurdere om avviket er minimum-phase.



Sammenlign:



målt fase, minimum-phase-estimat fra magnitude og excess phase.



Hvis avviket ikke er minimum-phase, skal EQ begrenses til kutt eller bred voicing, ikke full korreksjon.

1. Powerrespons og direktivitet

Motoren skal ikke optimalisere on-axis alene dersom det gir feil total energirespons.



Hvis off-axis-data finnes, beregn:



on-axis response, off-axis response, listening window, early reflection estimate, sound power estimate og directivity index.



Hvis full polar-data ikke finnes, bruk proxyer:



driverdiameter, hornspredning, delefrekvens, bølgelengde, driveravstand, on/off-axis-data hvis tilgjengelig og romrespons.



Bølgelengde:



wavelength_m = speed_of_sound_m_s / frequency_hz



Driveravstand relativt til bølgelengde:



spacing_ratio = acoustic_center_distance_m / wavelength_m



Høy spacing_ratio i deleområdet skal øke lobing_risk_score.



DSP skal ikke kreve mer akustisk energi fra en driver enn driveren naturlig kan levere kontrollert. Ikke boost for å kompensere for direktivitetstap, powerrespons, oppbrytning, romnull eller naturlig avrulling utenfor trygt arbeidsområde.

1. Forvrengning

Hvis REW-data inneholder harmonisk forvrengning, skal motoren bruke:



THD(f), H2(f), H3(f), H4(f), H5(f), IMD hvis tilgjengelig, noise floor og distortion_vs_SPL hvis flere nivåmålinger finnes.



H3 og høyere skal normalt straffes mer enn H2. Økende forvrengning nær delefrekvens kan flytte delepunktet.



Regler:



Hvis forvrengning stiger under en frekvens, skal driveren ikke deles for lavt.

Hvis diskant/horn viser økende H3/H5 nær nedre område, flytt delepunkt opp eller bruk brattere slope.

Hvis bass/mellombass viser økt forvrengning i øvre område, flytt delepunkt ned eller bratt filter.

EQ-boost som øker forventet forvrengning i risikobånd skal forkastes.

Kutt som reduserer energi i forvrengningsområde uten å skade sum/fase kan belønnes.



Motoren skal rapportere:



distortion_safe_band, distortion_warning_band og distortion_reject_band.

1. Headroom og driverstress

For hver kanal skal motoren beregne:



digital_peak_margin_db, RMS_margin_db, cumulative_boost_db(f), max_boost_db, expected_excursion_risk, thermal_risk, low_frequency_risk, horn_low_cutoff_risk, tweeter_low_cutoff_risk og breakup_region_risk.



Boost under tuning, i romnuller, nær diskantens nedre grense eller under hornets trygge område skal forbys som standard eller gis svært høy straff.

1. Romanalyse

Under ca. 200–300 Hz skal motoren anta at rommet dominerer mer. Bruk flere måleposisjoner, L/R separat og L+R. Finn rommoder, brede topper og posisjonsavhengige nuller. Kutt brede/modale topper forsiktig. Ikke boost smale nuller. Foreslå plassering, subintegrasjon eller delay før EQ.



Over ca. 300 Hz skal gated/direct sound brukes til driverrespons, mens rominkludert måling brukes til tonal balanse. Ikke korriger smale kamfilterdipper aggressivt. Bruk bred EQ bare ved stabile avvik.



For hvert avvik skal motoren beregne room_likelihood_score. Høy room_likelihood_score skal redusere EQ-aggressivitet.

1. Venstre/høyre og stereosenter

Motoren skal beregne:



L_mag(f), R_mag(f), LR_error_db(f), L_phase(f), R_phase(f), LR_phase_diff(f), L_arrival_time, R_arrival_time, LR_delay_offset_ms, cross_correlation_offset_ms, center_band_level_difference_db, center_band_phase_difference og stereo_symmetry_score.



Sentrert lydbilde skal vurderes fra:



L/R delay match, L/R gain match, L/R phase match i stemmeområdet, L/R tonal match, mono sum stability, fravær av sterke asymmetriske refleksjoner og origo consistency.



Senter skal korrigeres i denne rekkefølgen:



routing/polaritet, L/R delay, L/R bred gain, bred tonal EQ, romtiltak/plassering.



Smal EQ skal ikke brukes som første løsning for å fikse senter.

1. Origojustering

Systemet skal ha eksplisitt origo-modell:



SystemOrigin {

x

y

z

t_ms

reference_measurement_id

confidence

}



DriverNode {

side

driver_id

x

y

z

acoustic_t_ms

DSP_delay_ms

gain_db

polarity

valid_band

confidence

}



Alle delayverdier skal rapporteres som:



relativ akustisk tid mot origo

praktisk DSP-delay

fysisk ekvivalent avstand



distance_cm = delay_ms * 34.3



Origojustering er godkjent bare dersom:



driveroverganger summerer riktig, invertert null er god, L/R ankomst er symmetrisk, senterbildet er stabilt, subintegrasjon ikke trekker tidsreferansen feil, ingen kanal krever ufysisk delay og valideringsmåling stemmer med simulering.

1. Robusthet

Hver kandidat skal testes med perturbasjoner:



delay ±0.05 ms, ±0.10 ms og ±0.20 ms

gain ±0.25 dB og ±0.50 dB

delefrekvens ±5 % og ±10 %

mikrofonposisjon hvis flere målinger finnes



En kandidat skal bare score høyt dersom den ikke kollapser ved små realistiske avvik.

1. Scoremodell

Hver kandidat skal ha delscore:



measurement_quality_score, normal_sum_score, invert_null_score, phase_alignment_score, group_delay_score, magnitude_target_score, robustness_score, driver_stress_score, distortion_score, headroom_score, power_response_score, room_handling_score, LR_symmetry_score, center_image_score, origo_consistency_score og physical_plausibility_score.



Total score kan brukes til rangering, men må aldri skjule kritiske feil. Hvis én kritisk delscore feiler, skal kandidaten forkastes selv om total score er høy.



Kritiske fail-kriterier:



lav målekvalitet, ukjent routing, ukjent polaritet, dårlig normal sum rundt delepunkt, manglende invertert null der den forventes, stor L/R-delayfeil, stor headroom-reduksjon, boost i romnull, boost under trygg drivergrense, tydelig powerrespons-degradering, økt forvrengningsrisiko, origo-inkonsistens eller simulering som ikke stemmer med valideringsmåling.

1. Non-degradation gate

Etter hver endring i XO, delay, gain, polaritet, EQ eller target skal motoren sammenligne mot forrige godkjente baseline.



Endringen godkjennes bare hvis:



target error forbedres, normal sum ikke degraderes, invertert null ikke degraderes vesentlig, fase ikke degraderes, group delay ikke får nye store avvik, headroom holder seg innen krav, driverstress ikke øker uakseptabelt, forvrengningsrisiko ikke øker uakseptabelt, powerrespons ikke blir åpenbart dårligere, L/R-symmetri ikke forverres, senter ikke flytter seg, origo fortsatt er konsistent og simulert effekt er realistisk.



Hvis testen feiler, skal motoren rollback’e og logge årsak.

1. Validering med REW

Etter valgt kandidat skal motoren produsere testplan:



mål hver driver med ny gain/EQ/filter alene

mål parvise summer normal

mål parvise summer invertert

mål venstre fullrange

mål høyre fullrange

mål L+R mono for bass og senterkontroll

mål flere posisjoner i bassområdet

sammenlign målt respons mot simulert respons



Avvik beregnes som:



simulation_error_db(f) = measured_after_db(f) - predicted_after_db(f)



Hvis simulering og måling ikke stemmer, sjekk først:



filterimplementasjon, delay-fortegn, gain, routing, polaritet, REW timing reference, sample rate, latency, kanalbytte, plugin latency og målevindu/gate.

1. Når systemet kan kalles optimalisert

Motoren kan bare rapportere “optimalisert” når:



målinger er gyldige, routing er verifisert, polaritet er verifisert, alle driveroverganger har god normal sum, relevante overganger har god invertert null, fase er innen akseptabelt område, delay er konsistent mellom impuls/fase/sum/origo, gain er balansert uten ekstrem kompensasjon, EQ er konservativ og årsaksbasert, Q passer problemet, powerrespons ikke er åpenbart degradert, forvrengning og driverstress er innenfor krav, headroom er bevart, romrelaterte avvik er korrekt klassifisert, L/R er tilstrekkelig symmetrisk, senterbildet er stabilt, sluttmåling stemmer med simulering og ingen non-degradation gate feiler.



Hvis dette ikke kan bevises, skal motoren rapportere “ikke optimalisert ennå” og forklare hva som mangler.

1. Sluttrapport

Motoren skal alltid skrive:



hva som ble målt, hvilke data som ble brukt, hvilke data som ble forkastet, målekvalitet, valgt origo, delay per driver relativt til origo, praktisk DSP-delay per kanal, fysisk avstandsekvivalent, gain per driver, XO per overgang, slope per overgang, polaritet, EQ per driver/side, Q-begrunnelse, hvilke avvik som ikke ble korrigert og hvorfor, romrelaterte funn, powerresponsvurdering, forvrengningsvurdering, L/R-symmetri før/etter, center_image_score før/etter, headroom før/etter, driverstress før/etter, simulert vs målt avvik, pass/fail for regresjonstester, beste alternative kandidater og hva som eventuelt må måles på nytt.

1. Hovedregel

ML motoren skal ikke optimalisere én graf. Det skal optimalisere et fysisk høyttalersystem i et faktisk rom. Alle valg skal være små, målbare, reversible og begrunnet i kompleks respons, fase, tid, gain, powerrespons, forvrengning, romklassifisering, robusthet, headroom, driverstress, L/R-symmetri og origojustering.

 

[H.R]

For å gjøre en lang historie kort.
ml begynner å fungere. Etter 8 råmålimger, en av hver driver, et ekstra eksternt kall mot api for å hente de data som ligger under for distortion så startet ml og beregne totalt 120.000 varianter. Estimert tid er 3 timer med utregninger for å finne best egnet xo for distortion og fase. Den regner ut delay, gains lager invertert sum og generer 5 kandidater som skal tas med videre for nye målinger. Når målinger er fullført så skal ml motoren vurdere kvaliteten på disse ut fra beregnet modell, men et avvik skal lære opp metode for bedre prediksjoner til neste gang.
Tre timer utregning er lenge men om en slipper unna med å få et godt utgangspunkt så skal en teste omliggende frekvenser samt justere gain. Matematisk modell er dermed premissgivende men målinger er avgjørende og kan følge med på distortion, fase of om timingen er korrek før neste runde som sender disse nå låste målinger til ny analyse for å vurdere beste eq strategi for færrest mulig punkter og korrigeringer. Metoden blir +-3 db som mål men dersom det medfører vesentlig mer eq for å nå dette så skal en begrunne årsaken til målet ikke er nådd.

 

[H.R]

Om noen skulle være interessert i å lage en egen daw så ligger en ny foreløpig beskrivelse av prosjektet nå sommålemodulem begynner å få endelig form.

Dette er nest punkt etter å ha fått flyttet hele måle ml motoren til å kunne uføre flere milioner med utregninger i sekundet. Første test kalkulerte 5.4 millioner operasjoner på 0.17 sekunder. CPU brukte 233 sekunder på samme oppgave selv med et råskinn av en pc med 64 kjerner og 128 threads og mer ram en jeg trodde jeg skulle få brukt for. Skjermkortet er et helt vanlig middels godt kort.


Felles kravspesifikasjon for NeuronDAW
1. Dokumentets status
Dette dokumentet er den samlede og autoritative kravspesifikasjonen for utvikling av NeuronDAW.
For hver vurdering og implementering må
• lese hele dokumentet før implementasjon,
• lage en eksplisitt implementasjonsplan,
• identifisere alle eksisterende moduler før ny kode opprettes,
• gjenbruke eksisterende fungerende komponenter,
• ikke erstatte fungerende arbeidsflyter med forenklede alternativer,
• implementere kravene som sammenhengende systemarkitektur,
• fullføre hver modul med tester og integrasjon før oppgaven anses som ferdig.
Ved konflikt mellom eldre kode, eldre spesifikasjoner og dette dokumentet gjelder dette dokumentet.
________________________________________
2. Produktmål
NeuronDAW skal være en spesialisert flerkanals DAW og avspillingsmotor for aktive høyttalersystemer.
Systemet skal:
1. Motta lyd fra virtuelle og fysiske innganger.
2. Sikre at bare én normal avspillingskilde er aktiv om gangen.
3. Sende valgt kilde gjennom en felles Baseline Bus.
4. Kunne bruke eksterne plugins, inkludert ARC X, på Baseline Bus.
5. Fordele signalet til dynamisk opprettede driverkanaler.
6. Styre opptil 12 fysiske høyttalerutganger.
7. Integrere eksisterende Neuron Runtime-plugin.
8. Bruke eksisterende Neuron ML- og REW-baserte måle- og beregningsflyt.
9. Konfigurere hele systemet gjennom Blazor-baserte Wizards.
10. Følge lydkortets faktiske klokke og samplerate.
11. Kjøre kontinuerlig som bakgrunnstjeneste på macOS og Windows.
12. Kunne styres fra flere Blazor-flater mot én autoritativ DAW-instans.
13. Være sikker for aktive flerkanals høyttalersystemer.
________________________________________
3. Eksisterende komponenter som ikke skal bygges på nytt
Følgende komponenter finnes allerede og skal behandles som fungerende, autoritative komponenter.
3.1 Neuron Runtime
Det finnes et plugin med navn:
Neuron Runtime
Neuron Runtime programmeres med data som er beregnet av:
• Neuron ML,
• eksisterende REW-målinger,
• eksisterende måle- og korreksjonsarbeidsflyt.
Neuron Runtime er den autoritative runtime-komponenten for de beregnede outputkanalene.
DAW skal ikke:
• bygge en ny konkurrerende runtime-DSP,
• duplisere Neuron Runtime,
• skrive om den fungerende målemetoden,
• erstatte den med generisk EQ,
• forenkle dataene til bare gain og delay dersom Runtime støtter mer,
• anta DSP-parametere uten data fra eksisterende arbeidsflyt.
DAW skal integrere Neuron Runtime i NeuronDAWs:
• kanalstruktur,
• outputstyring,
• målemodus,
• profilmodell,
• Wizard-konfigurasjon,
• state management,
• plugin-host,
• sikkerhetsmodell.
3.2 Neuron ML
Neuron ML behandler måledata og produserer nødvendige beregnede data til Neuron Runtime.
Denne prosessen er eksisterende og fungerende.
NeuronDAW skal kunne:
• sende riktig Wizard-definert systembeskrivelse til måle- og ML-flyten,
• knytte målinger til korrekt driverkanal,
• motta beregnede Runtime-data,
• validere at dataene tilhører riktig profil og samplerate,
• laste resultatet inn i Neuron Runtime,
• styre hvilke outputkanaler Runtime skal kontrollere.
3.3 REW-måleflyt
Eksisterende REW-målinger og arbeidsflyt er ferdig og fungerende.
NeuronDAW skal ikke utvikle en ny målemotor.
NeuronDAW skal:
• åpne korrekt inputkanal for måling,
• åpne korrekt outputkanal eller kanalgruppe,
• deaktivere uforenlig prosessering,
• sende system- og kanalmetadata til eksisterende måleflyt,
• motta måleresultater,
• knytte målinger til aktiv Wizard-konfigurasjon,
• sende resultatene videre til eksisterende Neuron ML-flyt.
3.4 Virtuelle drivere
Virtuelle drivere som brukes for avspillingskilder er allerede konfigurert.
Dette gjelder blant annet:
• Roon,
• Spotify,
• Qobuz,
• Tidal,
• Bluetooth,
• LMS.
DAW skal ikke:
• bygge nye virtuelle drivere,
• installere virtuelle drivere,
• forsøke å konfigurere dem på nytt,
• endre deres interne implementasjon.
NeuronDAW skal oppdage, validere og mappe dem gjennom Wizards.
________________________________________
4. Overordnet arkitektur
Systemet skal deles i følgende hovedlag:
Blazor User Interface
↓
Application API and Command Layer
↓
NeuronDAW Service and State Management
↓
Audio Engine and Plugin Host
↓
Neuron Runtime
↓
Output Matrix
↓
Physical Audio Interface
Måleflyten skal være:
Blazor Measurement Wizard
↓
Measurement Mode Controller
↓
Input and Output Routing
↓
Existing REW Measurement Workflow
↓
Neuron ML
↓
Neuron Runtime Data
↓
Runtime Validation
↓
Neuron Runtime
↓
Validated Output Channels
________________________________________
5. Kanalstruktur
5.1 Baseline Bus
Systemet skal ha én intern Baseline Bus.
Baseline Bus:
• er ikke en fysisk lydkortutgang,
• mottar valgt avspillingskilde,
• har felles plugin-rack,
• kan laste ARC X,
• kan ha felles gain og metering,
• sender videre til aktive driverkanaler.
5.2 Driverkanaler
Følgende driverseksjoner skal kunne velges:
1. Sub eller basstårn
2. Bass
3. Midbass
4. Midrange
5. Upper midrange
6. Tweeter
Hver seksjon skal kunne settes som:
• stereo L/R,
• dual mono,
• summert mono,
• kun venstre,
• kun høyre,
• deaktivert.
Full konfigurasjon:
Sub/Basstårn L
Sub/Basstårn R
Bass L
Bass R
Midbass L
Midbass R
Midrange L
Midrange R
Upper Midrange L
Upper Midrange R
Tweeter L
Tweeter R
Dette gir maksimalt:
12 fysiske outputkanaler
1 intern Baseline Bus
Supertweeter skal ikke finnes som standardvalg.
5.3 Dynamisk opprettelse
Kanalene skal ikke hardkodes.
Speaker Configuration Wizard skal definere:
• hvilke driverseksjoner som finnes,
• kanalmodus,
• kanalnavn,
• side,
• kanalgruppe,
• outputmapping,
• Runtime-tilordning,
• sikkerhetsklasse.
Hver kanal skal ha en stabil intern ID som ikke endres når visningsnavnet endres.
________________________________________
6. Inputarkitektur
6.1 Normale avspillingskilder
Følgende skal kunne opprettes som egne input-busser:
• Roon
• Spotify
• Qobuz
• Tidal
• Bluetooth
• LMS
• andre ferdig konfigurerte virtuelle kilder
Signalvei:
Virtuell kilde
↓
Kildespesifikk Input Bus
↓
Input Selector
↓
Baseline Bus
6.2 Fysiske lydkortinnganger
Fysiske innganger skal kunne:
• mappes som mono eller stereo,
• navngis,
• tilordnes en inngangstype,
• brukes som platespillerinngang,
• brukes som måleinngang,
• brukes som generell line-in.
6.3 Eksklusivt kildevalg
Bare én normal avspillingskilde skal være aktiv om gangen.
Ved kildebytte skal systemet:
1. fade ut gammel kilde,
2. pause gammel kilde dersom adapteren støtter dette,
3. mute og koble fra gammel input-buss,
4. koble inn ny input-buss,
5. validere signalformat,
6. fade inn ny kilde,
7. starte eller gjenoppta kilden etter brukerens transportregel.
Kilder som ikke støtter pause/play skal mutes og frakobles.
________________________________________
7. Neuron Runtime-integrasjon
7.1 Runtime som outputprosessor
Neuron Runtime skal knyttes til outputkanalene som er definert av Wizard.
Runtime skal vite:
• hvilke driverkanaler som finnes,
• hvilken kanal-ID hver kanal har,
• fysisk outputmapping,
• kanalgruppe,
• kanaltype,
• side,
• dual mono-status,
• aktiv samplerate,
• aktiv profil,
• gjeldende måle- og kalibreringsversjon.
7.2 Runtime-data
Data som lastes inn i Neuron Runtime skal minst ha metadata for:
System Profile ID
Speaker Configuration ID
Calibration ID
Measurement Set ID
Sample Rate
Audio Interface ID
Output Mapping Version
Runtime Data Version
Creation Timestamp
Algorithm Version
Runtime-data skal avvises dersom de ikke samsvarer med aktiv systemtilstand.
7.3 Kanaltilordning
Det skal aldri brukes kanalnummer alene som identitet.
Runtime-data skal knyttes til stabile kanal-ID-er.
Eksempel:
driver-sub-left
driver-sub-right
driver-midbass-left
driver-midbass-right
driver-midrange-left
driver-midrange-right
Fysisk output kan endres gjennom Wizard, men må da utløse:
• ny validering,
• oppdatert mapping,
• eventuell ny måling,
• ny kalibreringsstatus.
7.4 Atomisk aktivering
Nye Runtime-data skal aktiveres atomisk.
Prosedyre:
1. Valider metadata.
2. Valider alle kanal-ID-er.
3. Valider samplerate.
4. Valider filter- og delaydata.
5. Last data i en inaktiv Runtime-instans eller staging state.
6. Kontroller at alle kanaler kan initialiseres.
7. Global mute eller kontrollert crossfade.
8. Bytt til ny Runtime-konfigurasjon.
9. Bekreft aktiv versjon.
10. Lagre aktiv Runtime-referanse.
Systemet skal aldri delvis oppdatere bare noen outputkanaler dersom datasettet er ment som ett samlet system.
________________________________________
8. Målemodus og eksisterende måleflyt
8.1 Measurement Bus
Systemet skal ha en egen Measurement Bus.
Measurement Bus skal:
• være separat fra normal avspilling,
• bruke eksisterende målemodul,
• åpne riktig måleinput,
• sende målesignal til valgt outputkanal,
• kontrollere sikkerhetsfiltre,
• registrere hva som var aktivt under målingen.
8.2 Measurement Wizard
Measurement Wizard skal bruke høyttaleroppsettet fra Speaker Configuration Wizard.
Wizard skal vite:
• hvilke drivere som finnes,
• hvilke outputkanaler de bruker,
• hvilke som er stereo,
• hvilke som er dual mono,
• hvilken mikrofoninngang som skal brukes,
• hvilke sikkerhetsfiltre som kreves,
• hvilken samplerate lydkortet faktisk bruker.
Wizard skal ikke spørre brukeren om informasjon som allerede finnes i aktiv systemprofil.
8.3 Måleprosedyre
Ved start av måling skal NeuronDAW:
1. Fade ut normal avspilling.
2. Pause eller mute alle normale kilder.
3. Aktivere global sikkerhetsmute.
4. Deaktivere ARC X.
5. Deaktivere Realtime Voicing EQ.
6. Deaktivere uforenlig baseline-prosessering.
7. Aktivere Measurement Bus.
8. Åpne Wizard-definert måleinput.
9. Åpne kun valgt outputkanal eller kanalgruppe.
10. Aktivere nødvendige sikkerhetsfiltre.
11. Starte eksisterende REW-arbeidsflyt.
12. Registrere kanal-ID, profil, samplerate og måletype.
13. Motta og lagre måleresultatet.
14. Sende resultatet videre til Neuron ML.
15. Motta beregnede Neuron Runtime-data.
16. Validere resultatet.
17. Programmere Neuron Runtime.
18. Utføre valideringsmåling dersom arbeidsflyten krever det.
19. Lukke Measurement Bus.
20. Gjenopprette forrige avspillingsstatus kontrollert.
8.4 ARC X
ARC X skal være bypasset ved:
• råmåling,
• driverkorreksjon,
• XO-beregning,
• delayberegning,
• gainberegning,
• faseanalyse,
• målinger som sendes til Neuron ML.
ARC X kan brukes ved sluttmåling av ferdig avspillingssystem, men en slik måling skal merkes som:
Post ARC X / Final Playback Validation
Den skal ikke blandes med råmålinger.
8.5 Realtime Voicing EQ
Realtime Voicing EQ skal være flat eller bypasset ved målinger som brukes til beregning.
________________________________________
9. Wizard-basert konfigurering
All strukturell konfigurering skal gjøres gjennom Blazor-Wizards.
Det skal ikke finnes fri strukturell konfigurasjon i vanlig DAW-visning.
Følgende Wizards skal finnes:
Initial System Wizard
Audio Interface Wizard
Speaker Configuration Wizard
Input Mapping Wizard
Output Mapping Wizard
Baseline Plugin Wizard
Phono Input Wizard
Pickup Profile Wizard
Measurement Wizard
Calibration Wizard
Service and Autostart Wizard
Remote Access Wizard
Profile Migration Wizard
Wizards skal:
• lese aktiv maskinvaretilstand,
• bruke eksisterende data der de finnes,
• validere hvert trinn,
• vise konsekvensene av valgene,
• opprette komplett ny konfigurasjon,
• lagre konfigurasjonen atomisk,
• aktivere den i mute,
• kreve måling der endringen påvirker kalibrering.
________________________________________
10. Blazor som eneste GUI
Alt brukergrensesnitt skal være Blazor-basert.
Dette gjelder:
• Wizards,
• dashboard,
• kildevalg,
• volum,
• kanalstatus,
• pluginstatus,
• målevisning,
• pickupadministrasjon,
• runtime-telling,
• EQ-kurve,
• systemstatus,
• serviceadministrasjon,
• diagnostikk.
Det skal ikke bygges separate GUI-er i:
• SwiftUI,
• AppKit,
• WinUI,
• WPF,
• Windows Forms,
• native plugin-kontrollpaneler.
Native komponenter skal bare håndtere:
• mikrofontillatelse,
• autostart,
• prosesslivssyklus,
• meny- eller tray-ikon,
• åpning av Blazor,
• lokal hardwarekontroll.
________________________________________
11. Flere Blazor-flater
NeuronDAW skal kjøre på én autoritativ vertsmaskin.
Blazor skal kunne vises på:
• vertsmaskinen,
• annen PC,
• Mac,
• nettbrett,
• mobil,
• fast kontrollskjerm.
Alle klientene skal kontrollere samme:
• NeuronDAW Service,
• Audio Engine,
• Neuron Runtime,
• lydkort,
• systemprofil.
Det skal bare finnes én aktiv lydmotor.
Flere klienter skal få synkronisert tilstand gjennom SignalR eller tilsvarende.
________________________________________
12. Lydkort, klokke og samplerate
12.1 Lydkortet er autoritativt
NeuronDAW skal konsekvent arbeide mot lydkortets faktiske:
• klokke,
• clock source,
• samplerate,
• kanalantall,
• kanalrekkefølge,
• buffer,
• tilgjengelighet.
Samplerate skal ikke kunne velges manuelt i DAW-en.
12.2 Automatisk tilpasning
Dersom lydkortet endres fra eksempelvis:
44,1 kHz → 48 kHz
skal systemet:
1. oppdage endringen,
2. mute alle utganger,
3. stoppe aktiv behandling kontrollert,
4. rekonfigurere Audio Engine,
5. rekonfigurere plugins,
6. rekonfigurere metering,
7. rekonfigurere Runtime,
8. rekonfigurere convolver,
9. beregne IIR-koeffisienter på nytt,
10. konvertere tidsbaserte delayverdier til korrekt sampleantall,
11. markere eksisterende kalibrering ugyldig,
12. kreve Calibration Wizard og nye målinger.
12.3 Måling etter samplerateendring
Selv om motoren teknisk kan tilpasses ny samplerate, skal tidligere kalibrering markeres som ugyldig.
Systemet skal skille mellom:
Engine Compatible
Calibration Valid
Eksempel:
Engine Compatible: Yes
Calibration Valid: No
Normal avspilling gjennom høyttalersystemet skal ikke åpnes før ny måling og validering er utført.
________________________________________
13. Baseline Bus og plugins
Baseline Bus skal kunne ha et plugin-rack.
Plugin-racket skal støtte:
• VST3 eller valgt pluginformat,
• ARC X,
• pluginrekkefølge,
• bypass,
• preset,
• latencyrapportering,
• plugin delay compensation,
• pluginfeil,
• sikker bypass.
Baseline Bus skal ligge før driverfordelingen med mindre et plugins kanalformat eksplisitt krever en annen arkitektur.
ARC X-integrasjonen skal valideres mot pluginens faktiske kanalformat.
________________________________________
14. Realtime Voicing EQ
Systemet skal ha en egen global sanntids-EQ for små brukerjusteringer.
Den skal:
• være separat fra Neuron Runtime,
• være separat fra driver-EQ,
• være separat fra XO,
• være separat fra ARC X,
• kunne justeres som en kurve,
• oppdateres i sanntid,
• være klikkfri,
• ikke endre Runtime-data.
Formål:
• små tonale endringer,
• target tilt,
• små bass- eller diskantjusteringer,
• lyttebasert voicing.
Standardgrenser:
Normalområde: ±3 dB
Maks boost: +3 dB
Maks kutt: -6 dB
Større endringer skal kreve avansert modus.
EQ-en skal normalt være lik for L og R.
________________________________________
15. RIAA-convolver
Valgfrie platespillerinnganger skal kunne bruke en ren convolver til RIAA-korreksjon.
Convolveren skal kunne tilordnes valgte input-busser.
Den skal støtte:
• mono eller stereo impuls,
• separate L/R-impulser,
• gain før og etter,
• latencyrapportering,
• sampleratevalidering,
• bypass,
• profilhåndtering.
Signalvei:
Physical Phono Input
↓
Runtime Meter
↓
RIAA Convolver
↓
Optional Subsonic Processor
↓
Input Selector
↓
Baseline Bus
RIAA skal bare aktiveres på eksplisitt valgte phono-innganger.
________________________________________
16. Valgfritt subsonisk filter
Phono-innganger bør kunne få et valgfritt subsonisk filter.
Grunnversjonen skal støtte:
• DC blocker,
• fast høypassfilter,
• valgfri frekvens,
• valgfri orden,
• klikkfri bypass,
• profil,
• headroom-kontroll.
Utvidet versjon kan støtte:
• Mid/Side-analyse,
• reduksjon av subsonisk Side-signal,
• plateslaganalyse,
• armresonansanalyse,
• adaptiv behandling.
Funksjonen er ønskelig, men ikke et krav for første fungerende versjon.
________________________________________
17. Pickup Runtime Counter
Valgfrie phono-innganger skal kunne telle faktisk spilletid for en pickup.
17.1 Målepunkt
Runtime-data skal hentes fra inputbussens eksisterende meter:
Etter analog input gain
Før RIAA
Før subsonisk filter
Før Baseline Bus
17.2 Telling
Telling skal bare skje når gyldig signal registreres.
Systemet skal skille mellom:
• faktisk avspilling,
• inngangsstøy,
• 50/100 Hz-brum,
• korte transienter,
• stillhet mellom spor.
Runtime skal knyttes til en pickup-profil, ikke bare en lydkortkanal.
17.3 Pickup-profil
Profilen skal kunne inneholde:
Pickup ID
Produsent
Modell
Serienummer
Monteringsdato
Starttid
Automatisk målt tid
Total tid
Siste avspilling
Servicegrenser
Notater
Tid skal lagres som heltallssekunder eller samples.
Manuelle endringer skal logges.
________________________________________
18. Surface Dial
Surface Dial skal styre mastervolum lokalt.
Funksjoner:
Roter med klokken: volum opp
Roter mot klokken: volum ned
Kort trykk: mute/unmute
Surface Dial skal:
• fungere uten åpen Blazor-klient,
• sende kommando til Audio Engine,
• oppdatere alle Blazor-klienter,
• bruke jevn gain-ramping,
• ikke endre relative drivernivåer.
________________________________________
19. macOS-arkitektur
Mac-versjonen skal genereres som:
NeuronDAW.app
NeuronDAW.app skal:
• være stabilt signert,
• eie mikrofontillatelsen,
• eie brukerøktens lydtilgang,
• starte og overvåke tjenesten,
• ha menyikon,
• håndtere autostart,
• åpne Blazor-grensesnittet.
NeuronDAW.app skal ikke ha eget konfigurasjons-GUI.
Menyikonet kan ha begrensede kommandoer:
Open NeuronDAW
Open System Status
Mute
Restart Audio Engine
Start at Login
Quit
Alle innstillinger skal åpnes i Blazor.
Mikrofontillatelsen skal forespørres av NeuronDAW.app når Measurement Wizard ber om det.
________________________________________
20. Windows-arkitektur
Windows-versjonen skal deles i:
NeuronDAW Service
NeuronDAW User Audio Host
NeuronDAW Blazor Host
NeuronDAW Tray Controller
Windows Service skal håndtere:
• prosessovervåkning,
• autostart,
• recovery,
• logging.
User Audio Host skal håndtere:
• lydkort,
• ASIO,
• virtuelle drivere,
• mikrofon,
• DSP,
• Neuron Runtime,
• Surface Dial.
Tray Controller skal bare åpne Blazor og tilby begrensede servicekommandoer.
Det skal ikke finnes et separat Windows-GUI.
________________________________________
21. Autostart og lagret tilstand
Systemet skal kunne starte automatisk ved innlogging.
NeuronDAW skal huske:
• valgt kilde,
• valgt systemprofil,
• valgt avspillingsprofil,
• valgt Voicing-profil,
• volum,
• mute,
• ARC X-status,
• RIAA-profil,
• subsonisk profil,
• aktiv pickup,
• autostartinnstilling.
Systemet skal skille mellom:
Desired State
Effective State
Eksempel:
Desired:
Mute = Off
Source = Roon

Effective:
Mute = On
Reason = Calibration required
Lagret tilstand skal aldri overstyre sikkerhetsregler.
________________________________________
22. Sikkerhetsmodell
Safety Manager skal kunne overstyre alle andre moduler.
Global mute skal aktiveres ved:
• oppstart,
• lydkorttap,
• clock loss,
• samplerateendring,
• pluginfeil,
• Runtime-feil,
• ugyldig kalibrering,
• endret outputmapping,
• manglende kanal,
• motorstopp,
• målemodusbytte.
Output skal ikke åpnes dersom:
• Runtime-data ikke matcher aktiv profil,
• måling ikke er gyldig,
• samplerate er endret,
• outputmapping ikke er validert,
• lydkortidentiteten ikke samsvarer,
• en beskyttet driver mangler sikkerhetsfilter.
________________________________________
23. Tilstandsmaskiner
23.1 Audio Engine
Stopped
Starting
Muted
Validating
Ready
Playing
Measuring
Reconfiguring
CalibrationRequired
Faulted
23.2 Measurement Mode
Idle
Preparing
SourcesMuted
ArcBypassed
InputOpened
OutputArmed
Measuring
ProcessingResults
ProgrammingRuntime
ValidatingRuntime
Restoring
Completed
Failed
23.3 Runtime
NoData
Loading
Validating
Staged
Active
Invalid
SamplerateMismatch
MappingMismatch
Faulted
23.4 Wizard
NotStarted
InProgress
AwaitingValidation
ReadyToCommit
Committing
Completed
Failed
Cancelled
________________________________________
24. Profilmodell
Systemet skal minst ha:
System Profile
Audio Interface Profile
Speaker Configuration Profile
Input Mapping Profile
Output Mapping Profile
Playback Profile
Measurement Profile
Calibration Profile
Runtime Profile
Phono Profile
Pickup Profile
Voicing Profile
Service Profile
Profiler skal:
• ha stabile ID-er,
• være versjonerte,
• ha opprettelsesdato,
• ha schema-versjon,
• kunne migreres,
• valideres før bruk,
• lagres transaksjonssikkert.
________________________________________
25. API og kommandomodell
Blazor skal sende kommandoer, ikke endre interne objekter direkte.
Eksempel:
SelectSource
SetMasterVolume
SetMute
StartMeasurementWizard
EnterMeasurementMode
OpenMeasurementInput
ArmMeasurementOutput
ApplyRuntimeDataset
ActivatePlaybackProfile
ConfigureAutostart
Serveren skal:
1. autentisere bruker,
2. kontrollere rolle,
3. kontrollere systemstatus,
4. kontrollere sikkerhet,
5. utføre kommando,
6. lagre tilstand,
7. publisere resultatet til alle klienter.
Blazor skal ikke ha direkte tilgang til:
• lydkort,
• Runtime,
• konfigurasjonsfiler,
• databaser,
• REW,
• Neuron ML,
• pluginfiler.
________________________________________
26. Revisjon og logging
Følgende skal logges:
• Wizard-endringer,
• profilaktivering,
• outputmapping,
• samplerateendringer,
• clock-endringer,
• målinger,
• Runtime-programmering,
• Runtime-validering,
• pluginfeil,
• global mute,
• manuelle runtime-korreksjoner,
• service restart,
• brukerkommandoer som påvirker fysisk output.
Loggen skal inneholde:
Timestamp
User
Client
Action
Previous State
New State
Result
Reason
Correlation ID
________________________________________
27. Ikke-funksjonelle krav
27.1 Sanntid
Audio callback skal:
• aldri vente på Blazor,
• aldri vente på database,
• aldri vente på nettverk,
• aldri vente synkront på plugin-GUI,
• unngå allokeringer i realtime-path,
• unngå låser som kan blokkere lydtråden.
27.2 Stabilitet
Systemet skal:
• håndtere UI-frakobling uten lydstopp,
• håndtere restart av Blazor-host uten lydstopp,
• kunne restarte Audio Engine kontrollert,
• unngå doble motorinstanser,
• unngå doble Runtime-installasjoner,
• lagre pickup-runtime regelmessig.
27.3 Plattformlikhet
Mac og Windows skal bruke samme:
• domeneobjekter,
• profiler,
• Wizard-logikk,
• Blazor-frontend,
• API-kontrakter,
• Runtime-integrasjon,
• måleflyt.
________________________________________
28. Foreslått prosjektstruktur
NeuronDAW.Domain
NeuronDAW.Contracts
NeuronDAW.Application
NeuronDAW.Infrastructure
NeuronDAW.AudioEngine
NeuronDAW.PluginHost
NeuronDAW.RuntimeIntegration
NeuronDAW.MeasurementIntegration
NeuronDAW.MlIntegration
NeuronDAW.ProfileManagement
NeuronDAW.Safety
NeuronDAW.Service
NeuronDAW.Api
NeuronDAW.Blazor

NeuronDAW.Platform.Mac
NeuronDAW.Platform.Windows

NeuronDAW.Tests.Unit
NeuronDAW.Tests.Integration
NeuronDAW.Tests.Audio
NeuronDAW.Tests.EndToEnd
________________________________________
29. Påkrevde integrasjonsmoduler
DAW skal implementere eller identifisere følgende moduler:
NeuronRuntimeHost
NeuronRuntimeConfigurationMapper
NeuronRuntimeDatasetValidator
NeuronRuntimeActivationManager

MeasurementModeController
MeasurementRoutingManager
ExistingRewWorkflowAdapter
MeasurementResultRepository

NeuronMlWorkflowAdapter
MlResultValidator
RuntimeDatasetBuilder

WizardCoordinator
SpeakerConfigurationWizard
InputMappingWizard
OutputMappingWizard
MeasurementWizard
CalibrationWizard

AudioDeviceStateMonitor
ClockStateMonitor
SampleRateChangeController
CalibrationValidityManager

InputSelector
BaselineBusController
OutputMatrix
SafetyManager
Dersom tilsvarende moduler allerede finnes, skal de utvides i stedet for å dupliseres.
________________________________________
30. Implementasjonsrekkefølge
Neuron skal arbeide i denne rekkefølgen.
Fase 1 – analyse av eksisterende system
1. Kartlegg eksisterende prosjekter.
2. Finn Neuron Runtime-integrasjonen.
3. Finn eksisterende REW-adapter.
4. Finn Neuron ML-integrasjonen.
5. Finn eksisterende målemodul.
6. Finn eksisterende virtuelle driverdefinisjoner.
7. Dokumenter manglende koblinger.
8. Ikke skriv ny arkitektur før denne analysen er ferdig.
Fase 2 – domenemodell og profiler
1. Stabile kanal-ID-er.
2. Systemprofil.
3. Speaker Configuration.
4. Input- og outputmapping.
5. Calibration Profile.
6. Runtime Profile.
7. Samplerate- og hardwarebinding.
Fase 3 – Wizard-flyt
1. Initial Wizard.
2. Speaker Configuration Wizard.
3. Input Mapping Wizard.
4. Output Mapping Wizard.
5. Measurement Wizard.
6. Calibration Wizard.
Fase 4 – Runtime-integrasjon
1. Mapping fra Wizard-kanaler til Neuron Runtime.
2. Runtime-datasetvalidering.
3. Staging.
4. Atomisk aktivering.
5. Feilhåndtering.
6. Profilbinding.
Fase 5 – måleflyt
1. Measurement Mode.
2. Inputkanal.
3. Outputkanal.
4. ARC X-bypass.
5. REW-adapter.
6. ML-adapter.
7. Runtime-programmering.
8. Valideringsmåling.
Fase 6 – avspillingsarkitektur
1. Input Selector.
2. Baseline Bus.
3. Plugin-host.
4. Output Matrix.
5. Surface Dial.
6. Realtime Voicing EQ.
Fase 7 – plattformverter
1. macOS NeuronDAW.app.
2. Mikrofontillatelse.
3. macOS autostart og menyikon.
4. Windows Service.
5. Windows User Audio Host.
6. Windows tray.
Fase 8 – phono
1. RIAA-convolver.
2. Pickup-profiler.
3. Runtime Counter.
4. Valgfritt subsonisk filter.
________________________________________
31. Påkrevde tester
31.1 Kanaloppsett
1. Full profil oppretter 12 outputkanaler.
2. Profil uten bass oppretter bare valgte kanaler.
3. Dual mono oppretter korrekt logisk gruppe.
4. Ingen to aktive kanaler kan bruke samme output.
5. Kanal-ID beholdes ved navneendring.
31.2 Måling
1. Measurement Wizard åpner riktig input.
2. Kun valgt outputkanal aktiveres.
3. ARC X bypasses.
4. Realtime Voicing EQ bypasses.
5. Normal avspilling mutes.
6. REW-resultat knyttes til riktig kanal-ID.
7. ML-resultat knyttes til riktig målesett.
8. Runtime-data lastes til korrekt kanal.
31.3 Runtime
1. Runtime-data med feil samplerate avvises.
2. Runtime-data med feil mapping avvises.
3. Ufullstendig datasett aktiveres ikke.
4. Aktiv Runtime-versjon rapporteres.
5. Atomisk bytte fungerer uten delvis oppdatering.
6. Runtime-feil gir global mute.
31.4 Clock og samplerate
1. 44,1 til 48 kHz oppdages.
2. Audio Engine rekonfigureres.
3. Kalibrering ugyldiggjøres.
4. Runtime-data ugyldiggjøres eller rekonfigureres etter definert regel.
5. Ny måling kreves.
6. Output forblir mutet frem til validering.
31.5 Flere klienter
1. To Blazor-klienter viser samme tilstand.
2. Volumendring synkroniseres.
3. Bare én kritisk Wizard kan kjøres.
4. Frakobling av klient stopper ikke lyd.
5. Ny klient får autoritativ tilstand ved tilkobling.
________________________________________
32. Samlede akseptansekriterier
NeuronDAW er ikke ferdig før følgende er oppfylt:
1. Blazor er eneste konfigurasjons-GUI.
2. Alle strukturelle endringer utføres gjennom Wizards.
3. Maksimalt 12 fysiske driverutganger støttes.
4. Supertweeter finnes ikke som standardvalg.
5. Baseline Bus finnes som intern buss.
6. Eksisterende virtuelle drivere brukes.
7. Bare én avspillingskilde er aktiv.
8. ARC X kan brukes på Baseline Bus.
9. Measurement Mode har egen buss.
10. ARC X bypasses ved beregningsmåling.
11. Realtime Voicing EQ bypasses ved beregningsmåling.
12. Eksisterende REW-arbeidsflyt brukes.
13. Eksisterende Neuron ML-flyt brukes.
14. Neuron Runtime brukes som autoritativ runtime-komponent.
15. Runtime-data knyttes til Wizard-definerte kanaler.
16. Riktig måleinput åpnes automatisk.
17. Riktig outputkanal åpnes automatisk.
18. Måleresultater knyttes til stabile kanal-ID-er.
19. ML-resultater programmerer Neuron Runtime.
20. Runtime-datasett valideres mot maskinvare og samplerate.
21. Lydkortets klokke er autoritativ.
22. DAW har ingen manuell samplerateinnstilling.
23. Samplerateendring oppdages automatisk.
24. Samplerateendring krever nye målinger.
25. Mac-versjonen genereres som NeuronDAW.app.
26. NeuronDAW.app eier mikrofontillatelsen.
27. Mac-versjonen har menyikon.
28. Windows-versjonen kan kjøre som tjeneste.
29. Begge plattformer bruker samme Blazor-frontend.
30. Autostart kan konfigureres.
31. Sist brukte driftsstatus huskes.
32. Surface Dial styrer mastervolum.
33. RIAA-convolver kan tilordnes phono-innganger.
34. Pickup-runtime kan telles fra meterdata.
35. Global Safety Manager kan mute alle utganger.
36. Ingen uvalidert Runtime-konfigurasjon kan åpne output.
37. Ingen uvalidert kalibrering kan åpne normal avspilling.
38. Alle kritiske endringer har revisjonslogg.
39. Audio callback er uavhengig av Blazor og nettverk.
40. Systemet fungerer med flere samtidige kontrollflater.
________________________________________
33. Absolutte implementasjonsregler for DAW
DAW skal ikke:
• bygge en ny målemotor,
• bygge en ny ML-motor,
• bygge en ny Runtime-plugin,
• bygge nye virtuelle drivere,
• erstatte Neuron Runtime med en forenklet DSP,
• hardkode 12 kanaler uten Wizard,
• bruke fysisk kanalnummer som eneste identitet,
• la Blazor skrive direkte til lydmotoren,
• la native GUI overta Wizard-funksjoner,
• fortsette avspilling etter samplerateendring uten ny validering,
• aktivere gamle Runtime-data mot ny hardwaretilstand,
• foreta tilfeldig automatisk outputmapping,
• omgå Safety Manager for å få lyd.
DAW skal:
• integrere eksisterende komponenter,
• bruke stabile kanal-ID-er,
• følge Wizard-konfigurasjonen,
• følge lydkortets virkelige klokke,
• åpne nøyaktig riktig input og output ved måling,
• programmere Neuron Runtime med data fra eksisterende Neuron ML- og REW-flyt,
• validere hele systemet før output åpnes,
• levere tester for hver kritisk arbeidsflyt.
________________________________________
34. Endelig autoritativ arbeidsflyt
Brukeren konfigurerer høyttalersystemet i Blazor Wizard
↓
Wizard oppretter stabile driverkanaler og outputmapping
↓
NeuronDAW leser lydkortets faktiske clock og samplerate
↓
Measurement Wizard bruker den ferdige systembeskrivelsen
↓
NeuronDAW muter normal avspilling
↓
ARC X og Realtime Voicing EQ bypasses
↓
Korrekt mikrofon- eller måleinput åpnes
↓
Korrekt driveroutput åpnes
↓
Eksisterende REW-måleflyt utføres
↓
Måledata sendes til eksisterende Neuron ML
↓
Neuron ML beregner data for kanalen eller systemet
↓
Data valideres mot kanal-ID, profil, hardware og samplerate
↓
Neuron Runtime programmeres
↓
Runtime aktiveres atomisk
↓
Resultatet valideres gjennom eksisterende måleflyt
↓
Kalibreringen markeres som gyldig
↓
Measurement Bus lukkes
↓
Normal avspillingsprofil gjenopprettes
↓
Output åpnes kontrollert
Dette er NeuronDAWs sentrale arbeidsflyt og skal implementeres uten å omskrive eller forenkle den eksisterende fungerende Neuron Runtime-, Neuron ML- og REW-metoden.

 

[H.R]

Endelig er første gjennomkjøring unnagjort fra start til mål
Startet dagen med følgende:

Første versjon av ML var lite effektiv, rett og slett trøttsom.
den gamle råmåleflyten brukte 4,3 timer og 892 forsøk uten faseoverlevering men viktig proof of concept.

Den nye er litt mer effektiv og kommer til samme resultat etter i underkant av 2 sekunder.
selve baselineberegningen behandlet 4,7 millioner frekvenspunkter på 1,63 sekunder totalt.
Med måling og CPUtid så ville dette likevel ta 90 minutter. Automatikken ga meg dette. Det er en god start for det viser at en del mekanismer brukes rett men ikke alle noe også det lave antallet med utregninger viste og de siste tillagte for kandidatutvelgelse var ikke med.

Etter en tids søken fant jeg feilen - jeg hadde kommentert ut slik at den ikke regnet slik den skulle og ML modulen har blitt utvidet med alle tiltenkte funksjoner.
Denne kurven vil bli brukt som referanse - ikke fordi den er spesielt god, men fordi det er det dårligste resultatet som nå skal kunne være og ny referanse vil være neste om den er bedre - og motorer må skrives om dersom dårligere da implementeringen ikke har vært god.

Et par biblioteker senere så var det nye tall
1 026 komplette kjeder og 6,3 millioner GPU-operasjoner tok 0,04 s, mens fem uavhengige CPU-refineringer tok 1 118,6 s.
CPU er fremdeles en flaskehals så etter å ha fordelt jobber slik at CPU jobber vesentlig mindre og skjermkortet merbegynner endelig hastigheten å bli akseptabel
Dette løste fremdeles ikke tidsbruken med mer en 1,59 sekunder

Målt på Radeon gfx1032: 50 000 kandidater med 24 EQ-bånd og 768 frekvenspunkter tok 0,19 sekunder, tilsvarende 921,6 millioner biquad/frekvensberegninger
og CPU bruker under et minutt på jobben.

Under optimale forhold ville da prosessen ta ca 43.3 minutter, men optimale forhold finnes ikke. Man skal justere inn for korrekt SNR fra sveip ved å gradvis øke dbfs til nødvendig nivå så jeg antar en hel konfigurering vil ta 1 time fra en starter til daw er ferdig programmert hvor summering, faser, idelt delingspunkt er gjort.

Jeg trenger nok noen dager på å fintune analysemodellene men jeg er svært sikker på at neste runde vil gi et bedre resultat.
Men før det så må deler av DAW skrives om slik at den kan ta i mot endringene som er gjort i systemet for å slippe å ha to instanser av tilsvarende funksjoner. Det var dårlig planlegging av meg og glemte det store bildet en stund..