REW api + claude = sant

[Lakka]

Hei!
Usikker på om dette er riktig underforum, men legger ut her.

I det siste har meg og claude kost oss noe voldsomt, og har laget masse snacks for automatiske målinger. REW har et api som vi kan bruke til å trigge sveip.
Egentlig alt du kan gjøre i ui, kan gjøres via api'et også.

Her er hardwaren som har kjørt:

- **Mains**: DIY Multiple Entry Horns (Scott Hinson's design — DCX-464 coax + dual 10NW76 per side) on Hypex FA253 plate amps.
- **Chain**: Raspberry Pi 5 (Spotify Connect via librespot + CamillaDSP convolution) → toslink → WiiM Ultra → analog sub-out to the miniDSP (arrays) + line-out to the mains.

Altså, claude har lagd koden, kjører alt på raspi, tolker målinger, justerer og implementerer.
Den katalogiserer alle målinger, gir de fornuftige navn og fungerer som en kjempegod assistent.

Så, jeg har hatt litt forskjellige prosjekter som har gått over i hverandre. Her er de:
- DBA tuning. Sette delayer, eq, fasekorreksjoner osv med mål om å minimere ringing / decay.
- integrere mains med dba, finne optimale xo parametre.
- refleksjons jakting. Her flytter jeg på ting, henger opp absorbenter osv, så tolker den impuls responsen. Deretter har vi lagd en plan for rommet og paneler som skal opp.

Flere som har kost seg med rew apiet?

Bildet er min originale manuelle DBA tuning, vs hva meg og assistenten klarte nå.

 

[Lakka]

Her er DBA tuningen ifra claudes egen munn

Hvorfor etterklang som mål? Bassproblemer i små rom er lagret energi — rommodene synger videre etter at signalet stopper. En DBA-s eneste jobb er å fjerne bakveggsrefleksjonen, altså fjerne energien som blir igjen i rommet. Da må målefunksjonen måle nettopp det. Flat frekvensrespons er en bivirkning, ikke målet — en respons kan se pen ut og likevel ringe.

Måltallet vi brukte: Ta impulsresponsen, båndbegrens til 15–130 Hz, finn direktelyd-toppen, hopp over de første 120 ms (direktelyd og tidlige refleksjoner skal ikke telle), og summer energien i de neste 600 ms. Ett tall i dB — «haleenergien». Lavere = mindre ringing.

Fremgangsmåten, i fire steg:

1. Fang systemet, ikke innstillingen. Front-array alene og bak-array alene (med bakre DSP nullstilt), 4 mikrofonposisjoner, alle på felles akustisk tidsreferanse (chirp fra hovedhøyttaler) — da er impulsresponsene komplekse tall på samme klokke og kan adderes matematisk.
2. Simuler i stedet for å prøve. Totalresponsen for enhver innstilling er front + G·bak der G = gain × delay × polaritet. Tusenvis av kandidater regnes ut offline, hver scoret på haleenergi summert over alle posisjonene. Grovt rutenett først, så Nelder-Mead rundt vinneren.
3. Verifiser og poler. Vinneren pushes til miniDSP og verifiseres med ekte sveip, deretter ubemannet koordinatsøk på ekte maskinvare: små steg i delay/gain, mål på nytt, behold det som forbedrer.
4. EQ til slutt — kun kutt. Minimum-fase-dualiteten gjør at et kutt av en modal topp også dreper ringingen dens (EQ-en alene ga −1,8 til −3,2 dB haleenergi). Boost gjør det motsatte — vår +3 dB på 77 Hz eksploderte 60–90 Hz-halen med +14 dB, fordi boost pumper energi inn i moder DBA-en ikke kan nå (tverrmoder).

Hva vi bedømte med: haleenergien etter hvert steg (−34,7 → −36,9 → −38,6 dB i runde én; −9 dB kansellering mot kun-front i runde to, mot −5 før; ~12 dB samlet), per-bånd-haler (20–40/40–80/80–130) som sikkerhetsnett mot skjulte forverringer — det var slik boost-katastrofen ble oppdaget — og spektrogrammer som visuell fasit. Pluss én felle: absolutt haleenergi kan ikke sammenlignes på tvers av EQ-tilstander (dypere kutt gir alltid lavere tall fordi det også er mindre lyd totalt), så sammenlign likt mot likt.

Og fysikken kvitterte: optimal forsinkelse kom ut som romlengde/lydfart (14,5 ms ≈ 4,98 m mot rommets 4,9) — speilkildeteorien sier at kabinettavstanden faller bort, og målingene var enige. Din manuelle innstilling lå forresten 0,2 ms fra optimum — ørene dine var gode; de kunne bare aldri ha målt det.

 

[Armand]

Kult. Dette skal jeg gjøre en dag også!
Merket du stor forskjell, eller var det bare en finpuss?

Jeg har koblet AI til API'ene på måleinstrumentene mine på lab'en. Nå snakker jeg bare til AI, og så måler og dokumenterer den for meg. Det er helt utrolig hvor mye kult man kan gjøre i dag...

 

[H.R]

Har selv brukt Claude, men mer til å faktorisere egen kode.
Ulempen har vist seg at selv når man har gitt fra seg kontrollen på et sted så blir det ufattelig mange timer med å finne frem for bugfix. Så be Claude om å dokumentere godt i koden slik at du finner frem igjen og du kan eie prosjektet uten å måtte være tilknyttet ekstern AI.

Selv valgte jeg å lage en egen ML motor som har streng læring hvor jeg kun bruker REW sine hjelpefiler, bibliotekenes dokumentasjon samt noe annen etterrettelig dokumentasjon og lærer opp denne slik at den husker mønster fra samme rom om jeg bytter høyttalere eller deler av systemet.

 

[Lakka]

Kult. Dette skal jeg gjøre en dag også!
Merket du stor forskjell, eller var det bare en finpuss?

Jeg har koblet AI til API'ene på måleinstrumentene mine på lab'en. Nå snakker jeg bare til AI, og så måler og dokumenterer den for meg. Det er helt utrolig hvor mye kult man kan gjøre i dag...

Har ikke levd med det så lenge enda, men jeg synes det ble bedre. Vi endret jo og xo fra 90 til 120 hz, så nå jobber egentlig dba helt på grensen sin.
Men alt er ettertrykkelig dokumentert og testet, så lett å gjennomgå og eventuelt switche tilbake.

Har lagd et helt oppsett for å justere delefilterene i mains og, så blir spennende å få teste det. Da blir de satt opp helt fra scratch.
Blir spennende å se hva resultatet blir. Det blir ute-målinger, med spinorama vinkler osv. Alt er satt opp allerede, men her lagde jeg og et dashboard med alle stegene, målinger undervegs osv. Så da kan jeg bare trykke meg igjennom.
Hadde det bare kunne slutte å regne her på vestlandet....

Bruker claude på jobb, og det er ufattelig hvor kraftig det er blitt. Og fable-5, med ultracode effort, er fantastisk.

 

[Lakka]

Har selv brukt Claude, men mer til å faktorisere egen kode.
Ulempen har vist seg at selv når man har gitt fra seg kontrollen på et sted så blir det ufattelig mange timer med å finne frem for bugfix. Så be Claude om å dokumentere godt i koden slik at du finner frem igjen og du kan eie prosjektet uten å måtte være tilknyttet ekstern AI.

Selv valgte jeg å lage en egen ML motor som har streng læring hvor jeg kun bruker REW sine hjelpefiler, bibliotekenes dokumentasjon samt noe annen etterrettelig dokumentasjon og lærer opp denne slik at den husker mønster fra samme rom om jeg bytter høyttalere eller deler av systemet.

Ja, det er litt tveegget med tanke på kontroll over koden. Personlig er jeg så vant til det nå, og fable-5 gjør sjelden noen store feil lenger. Kjører en code review også, blir det rimelig sikkert. Men bruker alltid litt tid istarten i planleggings modus, der vi går gjennom og lager en plan før den starter å kode. For det er her den ofte kan misforstå hva intensjonen er. Dersom planen ser bra ut, pleier det å bli suksess for det meste.

 

[H.R]

Det er ikke de store feilene jeg bekymrer meg for, det er alle de små som er vanskelige å egentlig finne siden det er ikke kodefeil. Siden jeg i all hovedsak programmerer mot GPU via CuPy/PyTourch hvor REW kun har blitt en modul for å hente inn data til egen motor men basert på REW sin kunnskapsbase, dette for å introdusere flere filtervarianter en kun PEQ i DAW modulen jeg har laget. Så nå finner den delay med 0.001ms nøyaktighet og XO ut fra scoreverdier hvor forvrenging og robusthet i XO, fase, GD og LR konsistens blir regnet ut for så å teste.

EQ er også nesten på plass, men kun nesten siden seleksjonene av strategi trenger litt ekstra innsats, har kostet meg mange timer med dektektivarbeide nå for å finne avvik som dukket opp. Jeg er ikke helt vant til å slippe kontrollen så jeg sitter da fremdeles å hardkoder, men blitt flinkere til å få innspill fra Claude uten å la den få fritt spillerom.

Ingen tvil om at fremtidens programmering blir AI basert - det er fantastiske verktøy som enhver utvikler bør både elske og frykte på samme tid gitt hvordan en omfavner mulighetene.