Jag bygger en musikstudio på Linux — del 1: planen börjar i kaos

Det här är inte en färdig studioguide

Det här är början på en serie om hur min nya musikstudio faktiskt växer fram. Jag kommer att skriva om vad jag planerar, installerar och testar — men också om sådant som inte fungerar, byts ut eller rivs upp när jag förstår mer.

Resan kommer inte att vara rak. Nya program och prylar dyker upp. En lösning som verkar självklar på morgonen kan vara borta på kvällen. Just därför tror jag att processen kan vara mer användbar än ännu en perfekt guide där alla misstag redan har redigerats bort.

Varför bygger jag studion?

Jag har redan Suno för musikskapandet, ChatGPT för text och idéarbete samt Audacity för enklare ljudredigering. Det har gjort det möjligt att skapa mycket, men jag vill kunna detaljstyra ljuden och beatsen så att låten blir som jag själv hör den i huvudet.

Målet är inte att sluta använda AI. Jag vill komplettera den. Ett AI-utkast kan ge riktning och energi, men jag vill själv kunna ändra en basgång, flytta ett slag, välja synthljud, bygga ett beat, bearbeta en stem och bestämma hur arrangemanget utvecklas.

• Skapa och redigera egna MIDI-beats.
• Bygga och förändra synthljud i stället för att bara välja ett färdigt resultat.
• Ta material mellan AI-verktyg och en DAW utan att förlora kontrollen över varje steg.

Varför lämna Windows för Linux?

Jag började i Windows. Problemet var inte att det saknades verktyg, utan nästan motsatsen. Äldre komponenter, launchers, separata bibliotek och flera program som gjorde ungefär samma sak började fylla diskarna. Studiomiljön växte, men blev inte nödvändigtvis tydligare.

Min förhoppning är att Linux ska låta fler delar återanvända samma grund: ljudsystem, paket, mappar och öppna verktyg. Om det verkligen blir renare och enklare återstår att se. Hoppas kan man ju. :D

Det här är alltså ett test, inte ett påstående om att Linux automatiskt är bättre. Vi ska följa hur mycket som kan delas, hur mycket handarbete som krävs och vilka nya problem som uppstår när gamla problem försvinner.

Den första verktygslådan

Ardour har fått rollen som studions nav. Där kan MIDI, audio, inspelning, routing, effekter och export samlas i samma projekt. Surge XT är ett av de första mjukvaruinstrumenten jag testar för synthbasar, cyberpunkljud och egna klanger. PipeWire sköter ljudflödet i Linux, medan en grafisk patchbay gör det möjligt att se hur program, MIDI och fysiska utgångar faktiskt är kopplade.

Andra verktyg kan tillkomma, men serien börjar med en liten grund. Jag vill undvika att återskapa samma verktygskaos som jag försöker lämna bakom mig.

När mätarna rör sig men inget hörs

Det tog inte lång tid innan den prydliga planen mötte verkligheten. MIDI-signalen nådde fram och flera ljudmätare reagerade, men ljudet kom inte alltid till hörlurarna. I routinggrafen fanns program, uppspelningsenheter och MIDI-portar som alla kunde kopplas på fler än ett sätt.

Sedan kom nästa överraskning: vissa synthljud hördes nästan inte alls, medan en enstaka ton plötsligt fungerade. Velocity låg lågt, nivåerna nådde bara ungefär minus 25 till minus 30 decibel och ett lågpassfilter tog bort större delen av det hörbara innehållet. När filtertypen ändrades kom ljudet tillbaka med sådan kraft att det gjorde ont i öronen. En ganska effektiv lektion i att sänka volymen innan man provar nästa knapp.

Det är precis de här ögonblicken serien ska behålla. Inte för att rekommendera slumpmässiga filterbyten, utan för att visa hur MIDI, anslag, synthmotor, filter, kanalnivå, routing och fysisk utgång tillsammans avgör om något hörs.

En studio som ska gå att återskapa

Linux ger oss också en annan möjlighet: installationen kan dokumenteras som text. Planen är att skapa en sanerad instruktion som kan ges till Codex CLI på en annan Linuxdator. Codex kan då kontrollera systemets förutsättningar, visa vad som redan finns och hjälpa till att sätta upp samma grund i en kontrollerad ordning.

OpenAI beskriver Codex CLI som ett terminalverktyg som kan inspektera filer, göra ändringar, köra lokala verktyg och användas i upprepningsbara arbetsflöden. Det betyder inte att en publik textfil ska få fria händer över en dator. Vår version ska först inventera, redovisa en plan och be om godkännande innan systempaket eller ljudkonfiguration ändras.

• Identifiera distribution och version utan att publicera datorns identitet.
• Kontrollera ledigt utrymme och befintliga ljudtjänster före installation.
• Visa planerade ändringar innan något installeras eller skrivs över.
• Testa ett lager i taget och dokumentera både resultat och återställning.

Vad händer i nästa del?

Nästa del går från planen till själva grunden: vad som installerades först, varför Ardour blev navet och hur den första signalen tog sig från MIDI till ett hörbart synthljud. Där börjar vi också rita den enkla signalväg som jag själv saknade när mätarna rörde sig men hörlurarna var tysta.

Längre fram följer egna EVX-beats, Surge XT, filter, MIDI-export, arbete med AI-stems och försöket att paketera studiogrunden så att en annan Linuxanvändare kan bygga samma startpunkt med hjälp av Codex CLI.