Archive for the ‘Mac’ Category

Datorarkeologi 2026

02/04/2026

Jag har lekt med en Clockwork PicoCalc som man kan köpa som en enkel byggsats. PicoCalc är egentligen ett tangentbord och en skärm med 320×320 pixlar d.v.s. en skärm som motsvarar en typisk hemdator från 1980-talets början t.ex. en Commodore 64. Byggsatsen görs till en fungerande dator genom att lägga till något av processorkorten Rasapberry Pi Pico, Pico2 eller Pico W. Hobbyister har också kört andra processorer och lyckats köra Linux utan större problem. Användning av andra processorer än Pico kräver dock i allmänhet att man hackar hårdvaran d.v.s. löder om själva PicoCalc. Jag tycker av princip illa om att gå in och löda i fungerande hårdvara vilket är orsaken till att jag kör en normal PicoCalc och inte Linux.

Bilden visar att Turbo pascal d.v.s. turbo har startat och programmet frågar efter den fil vi vill editera och kompilera. I vårt fall TEST.PAS. Vi ser en CP/M mikroskärm med radlängden 40 tecken. En speciell font har skapats för att få möjligast mycket text att rymmas på en rad.

PicoCalc ser ut som en normalstor kalkylator från 1980-talet i vilken man kan programmera och köra Basic, Python och Lua. Under Basic och Python fungerar den förvånande bra som en programmerbar kalkylator. Det visade sig snabbt att processorn är tillräckligt snabb och det finns tillräckligt minne för att köra operativsystemet CP/M som var dominerande från mitten av 1970-talet till mitten av 1980-talet. CP/M trängdes ut av IBM:s PC kring mitten av 1980-talet. IBM PC körde ett mycket liknande operativsystemsom CP/M kallat Ms-DOS.

https://en.wikipedia.org/wiki/IBM_Personal_Computer

https://en.wikipedia.org/wiki/CP/M

ARM processorn i en RPi Pico klarar av att emulera en Intel 8080 eller en Zilog Z80 i realtid. Pico:ns lilla minne räcker till för att ge CP/M ett fullt arbetsminne trots att en stor del av Pico kapaciteten går åt till att emulera en främmande processor.

Storleken på en Raspberry Pi Pico är ungefär två normalstora frimärken i bredd. Bildens Pico har storleken 20×50 mm.

Ett mycket vanligt programmeringsspråk på 1980-talet både under CP/M och PC-DOS var Turbo Pascal som erbjöd en enligt dåtida mått mycket trevlig programmeringsomgivning för programspråket Pascal. Pascal är ett i många avseenden mycket klarare och ”renare” programspråk än t.ex. programspråket C som användes då Unix och senare Linux skapades. Med hjälp av Turbo Pascal kunde man i akademiska sammanhang enkelt t.ex. göra statistiska analyser på en liten bordsmaskin, analyser som tidigare krävde tillgång till en stordator med all den byrokrati och kostnad detta medförde. Med hjälp av Turbo Pascal kunde man också med hjälp av diverse instickskort använda en PC för förvånande avancerade automatiska mätningar. Turbo Pascal fanns tillgängligt både för CP/M baserade datorer och för Ms-DOS maskiner d.v.s. IBM-PC samt mängder av liknande kloner.

Att köra program i 64 kilo Byte minne

Dagens datorer t.ex. en PC tenderar att ha ett centralminne på 4-32 GigaByte ibland mera. Min personliga PC som kör Linux har 32 GigaByte minne som är 500 000 gånger större än än det totala minnet i forntidens CP/M dator.

Jag kompilerade på skoj ett program TEST.PAS som ger ett nytt kommando till CP/M systemet som enligt Unix tradition kallas cat d.v.s. catenate eller skriv ut/kombinera ihop. Programmet kan läsa en eller flera textfiler och skriva ut dem till skärmen eller skicka resultatet till en annan fil. Under Linux skulle jag kunna skicka filen utan förändringar till t.ex. LPR dvs skriva ut till skrivare allt det som annars skulle gå till skärmen. Jag antar att jag inte kommer riktigt så enkelt undan under CP/M. Länken nedan diskuterar hur man kommer åt en skrivare, stans för hålremsa etc. under CP/M.

https://www.mark-ogden.uk/mirrors/www.cirsovius.de/CPM/Projekte/Artikel/Grundlagen/IOByte/IOByte-de.html

Då jag kompilerar programmet under Turbo Pascal under CP/M på PicoCalc får jag ett körbart program med storleken 635 bytes vilket motsvarar en vanlig text utskriven med 80 tecken par rad som då blir ungefär åtta rader lång. Jag testade programmet under CP/M så att jag använde det kompilerade programmet till att lista ut sig själv på PicoCalc skärmen. Texten är väldigt liten och ganska svårläst men programmet fungerade OK.

En intressant fråga blir då: Om jag tar samma program och kompilerar det under Linux (eller Windows eller Mac) hur stort blir då programmet på en modern dator? Notera att jag kompilerar för användning på kommandoraden helt utan GUI (grafiskt användargränssnitt). Om jag skulle skapa ett GUI för programmet gissar jag att det skulle växa ytterligare med kanske en faktor tio.

För kompileringen under Linux använde jag fpc d.v.s. Free Pascal Compiler som är basen i bl.a. Lazarus som idag är en trevlig omgivning för att generera program med grafiskt användargränssnitt GUI. Lazarus är mycket nära besläktad med Delphi (tidigare Borland Delphi). Lazarus är trevligt eftersom program enkelt kan skrivas för Linux, Windows, Mac, Android och FreeBSD och det finns funktionalitet som i hög grad förenklar designen av ett program med GUI. Fpc är således funktionsmässigt nära släkt med Borlands Pascal d.v.s. Turbo Pascal.

Jag kompilerade om programmet TEST.PAS under fpc med:

fpc -gl TEST.PAS

Kompileringen gick igenom utan problem men jag putsade bort en del onödiga fyllnadstecken i slutet av filen, tecken som i sig inte störde kompileringen. Då jag körde programmet:

./TEST TEST.PAS

Skrevs texten till TEST.PAS ut korrekt men jag fick ett felmeddelande på den nästsista raden (se programlistningen nedan) där programmet försöker stänga filen wrf d.v.s. en fil som används om man skulle vilja att resultatet går till en annan fil och inte på skärmen. Om jag skriver till skärmen behövs inte wrf och om jag försöker stänga wrf som aldrig har öppnats uppstår det ett fel. Felet är enkelt att åtgärda genom att kontrollera om vi har alternativet redirect innan vi försöker stänga filen. Längden på det körbara programmet blev nu under 64-bitars linux med kompilatorswitchen -gl som jag använde för att komma åt vilken rad i programmet som gav felet 420968 Byte d.v.s. ungefär 663 gånger större än under CP/M.

Om jag kompilerar om programmet efter rättning utan flaggan -gl blir resultatet 188304 Byte d.v.s. ungeför 297 ggr större än under CP/M.

Vad beror storleksskillnaderna på? En självklar orsak är naturligtvis att datorns s.k. ordlängd d.v.s. hur lång en typisk instruktion är har vuxit från 8-bitar till 64-bitar. Om vi antar att vårt program fortfarande behöver ungefär samma maskinspråksinstruktioner så kan vi få en vettigare jämförelse genom att dividera Linux-varianten med åtta d.v.s. ungefär 23538 instruktioner vilket är 37 ggr större än antalet instruktioner i CP/M varianten. Jag gissar att man genom väl genomtänkta optimeringar vid kompileringen kan krympa Linuxvarianten ytterligare. En stor orsak till att programmet har blivit större är antagligen kontroll av olika fel d.v.s. debuggning som utvecklats mycket under åren. De bibliotek vi länkar mot under Linux har bättre funktionalitet men de har också vuxit betydligt och innehåller sannolikt kod vi inte behöver. Vid kompileringen kan vi ange olika nivåer av optimering som påverkar snabbhet , minnesåtgång samt stöd för olika typer av felsökning. Körning av programmet ger:

./TEST TEST.PAS
ParamCnt=1/home/lasi/Prog/Pascal/TEST
Testing for file redirection
Got last par=TEST.PAS
TEST.PAS
program cat(input,output);
(* Make a new CP/M command cat
cat xxx yyy zzz … List all files to screen
cat xxx yyy >zzz List files xxx, yyy to the file zzz
*)
var i,nfiles:integer;
red:Boolean;
rdf: Text;
wrf: Text;
line: String[255];
destF: String[10];
function CkRedirect: boolean;
(* Is the destination a file or stdout?
The last file is assumed to be the redirection file if it exists.
Write all non redirection files to a temporary file and then
dump that to stdout or rename it to the destination file.
*)
var line:String[80];
begin
writeln('Testing for file redirection');
line := ParamStr(ParamCount);
writeln('Got last par=',line);
if (line[1] = '>') then
begin
writeln('Found redirect');
CkRedirect := True;
end;
end;
begin
writeln('ParamCnt=',ParamCount,ParamStr(0));
nfiles := ParamCount;
red := False;
if CkRedirect then
begin
writeln('Redirect');
nfiles := ParamCount - 1;
red := True;
destF := ParamStr(ParamCount);
Delete(destF,1,1); (* Remove '>') ) writeln('Redirect to:', destF); end; for i:=1 to nfiles do begin ( Type one file ) writeln(ParamStr(i)); Assign(rdf,ParamStr(i)); Reset(rdf); if red=True then begin Assign(wrf,destF); Rewrite(wrf); end; while not Eof(rdf) do begin Readln(rdf,line); if red=True then begin Write(wrf,line); end else Writeln(line); end; close(rdf); Writeln(' '); end; ( Caused error on the fpc compiler *)
if CkRedirect then close(wrf);
Writeln('Done …');
end.

Testing for file redirection
Got last par=TEST.PAS
Done …

Konklusion

Den här lilla programmeringsövningen visar egentligen hur ofattbart mycket tekniken har utvecklats under en livstid. Generellt kan man antagligen säga att alla intressanta parametrar har förbättrats med en faktor tusen eller mera. Några exempel:

  • Processons klockfrekvens 1 MHz –> 4 GHz (dagen datorer är ungefär 4000 ggr snabbare sett till processorns klockfrekvens.
  • Maskinens centralminne RAM 64 kByte –> 64 GByte (1 000 000 gånger större minne i dagens persondatorer av topp klass).
  • Skivminne/Lagringsminne 100 kByte –> 4 TByte (4 000 000 ggr större idag).
  • Maskinens pris $5000 –> $100 (50 ggr dyrare än idag). Notera att jämförelsen är felaktig eftersom penningvärdet har försämrats kraftigt på 40 år. Jag gissar att en korrekt jämförelse kunde vara åtminstone 100 ggr.

Om vi glömmer dagens AI boom där AI av vanliga användare körs över nätet och således inte belastrar den egna maskinen i någon större utsträckning så används datorerna fortfarande till liknande uppgifter som i ”forntiden” d.v.s. textbehandling, skicka brev och hantera kalkylark av olika typer. Gårdagens datorer kändes responsmässigt ungefär lika som dagens datorer. Vart har en prestandaökning på mellan 1000 och 1 000 000 ggr. försvunnit? Min uppfattning är att vi har fått en ofantlig mängd ”bling” som egentligen endast gör skärmen trevligare att titta på. Vi har halvtransparenta fönster som uppdateras hela tiden medan vi flyttar dem. En gammal dator skulle ha storknat genast. I våra datorer körs mängder av program i bakgrunden hela tiden. Program som meddelar oss att vi har fått meddelanden, program som skickar information om var vi gör till Microsoft etc. Det är lätt att bränna datorkapacitet och minneskapacitet i en värld där maskinen jag använder egentligen redan länge har varit tillräckligt kraftfull för det den skapades för.

Min laptop som också kör Linux fungerar helt OK trots att den är strax över tio år gammal. En bekant fick problem d.v.s. den heliga röken som datorn antagligen kör på slapp ut och maskinen slutade fungera. Jag hjälpte personen att rädda foton och dokument från datorn och fick sedan överta skrotet. Efter egen reparation har maskinen fungerat klanderfritt i många år. Jag kör en linuxvariant där allt onödigt ”bling” är bortplockat och maskinen fungerar bra som den är.

Ett annat intressant exempel på datorns ofantliga utveckling är ”mini”-datorn PDP-11 som operativsystemet Unix utvecklades på. Maskinen skulle ha kostat en privatperson tiotals tusen dollar att köpa. Jag har idag en replica av en PDP-11/70 d.v.s. den sista PDP:n som hade en frontpanel som tillåter mig att knappa in maskinkod bit för bit. Min replika kör, liksom CP/M på PicoCalc, en emulator men i detta fall på en Raspberry Pi 4. Den emulerade minidatorn från 1970-talet kör engefär tio gånger snabbare än orginalet trots att varje maskininstruktion emuleras av ett emulatorprogram på Raspberry Pi. En raspberry pi kostar idag beroende på variant kring 100 Euro.

Världens första egentliga superdator var Cray-1. Maskinen användes för mängder av vetenskapliga beräkningar. Man har uppskattat att en Raspberry Pi 5 (100 Euro), då man använder display hårdvaran (GPU) som en vektorprocessor är snabbare än en Cray-1 superdator. En Cray-1 behövde ungefär 115 kW eleffekt. En Raspberry Pi behöver ungefär 7W. Även på effektområdet ser vi alltså en förbättring på ungefär sextontusen gånger.

https://en.wikipedia.org/wiki/Cray-1

Om stämning av en fiolstråke (del 1)

11/12/2020

Jag har beskrivit stämning av en fiolkropp, stämning av ett fiolstall etc. i olika artiklar. Jag har inte tidigare skrivit om stämning av en fiolstråke. Detta är den första artiken i en serie artiklar kring stämning av stråkar.

Det verkar självklart att fiolstråken har stor betydelse för hur ljud produceras i en fiol. Ljudet uppstår så att stråkens tagel som är hartzade och något ”klibbiga” kommer, beroende av strängens rörelser, att ha en friktion som ibland är dynamisk (låg) och ibland statisk (hög). Stråken kommer således att fastna/frigöras vilket överför energi från stråkens rörelse till de strängar stråken stryker mot. Processen är mycket komplicerad eftersom man kan vänta sig att det förutom vågrörelser i strängarna (många olika toner samtidigt i form av grundton+övertoner) med säkerhet också uppstår vågrörelser i taglens riktning i den spända stråken. Stråkens egna vibrationer blandas med vibrationerna i de spelade strängarna.

Jag ser som fysiker inga möjligheter att övertygande matematiskt hantera stråkens egenskaper och dess samverkan med det spelade instrumentet. Min utgångspunkt blir att se hur jag kan mäta vissa egenskaper hos stråken och koppla detta till ett specifikt instrument. Jag är intresserad av att se om jag via modifikationer av stråken kan åstadkomma hörbara förändringar i mitt referensinstrument som jag kallar min Kletzmerfiol.

Vilka egenskaper hos stråken kan förväntas ge hörbar effekt

Jag gör en lista över de egenskaper jag ”tror” kan ha betydelse och anger samtidigt varför.

  • Stråkstången kommer då man spelar att bidra med någon typ av egenljud.
  • Stråkstångens styvhet påverkar stångens egensvängningar som sannolikt syns som lågfrekventa resonanser i taglen.
  • Spänningen man justerar med spännskruven påverkar stråkens resonanser då spänningen i taglen förändras.
  • Stråkens spets utgör en styv fjäder som ger högfrekventa longitudinella resonaser i taglen.
  • Mängden tagel avgör hur hög spänning vi får i de enskilda taglen. Ju mera tagel stråken har desto lägre spänning per tagelstrå om alla övriga egenskaper hålls oförändrade.
  • Froschen utgör också en styv fjäder som kommer att ge högfrekventa longitudinella resonanser i taglen.

Ovanstående lista kan säkert kompletteras med ytterligare parametrar.

Vad kan jag mäta

Jag hittade en intressant länk till en engelskspråkig sida av David Langsather som beskriver ett sätt att justera en fiolstråke. Min utgångspunkt är att titta på vad han har att erbjuda och därefter se vad som går att verifiera via mätningar. Det kan också vara intressant att se om jag noterar några spelmässiga förändringar i en stråke jag stämmer. Notera att jag är amatörviolinist och jag har aldrig använt teknik såsom spel med hoppande stråke etc. vilket betyder att jag knappast kan uttala mig om dessa egenskaper. Min son är Sebastian är yrkesviolinist och doktorand som har studerat fiolspel lokalt i Finland, i Sverige samt i Schweitz. Sebastian kan garanterat ge kommentarer gällande hur trimning påverkar stråkens funktion.

Jag mäter stråkens knacktoner i specifika punkter och använder dessa mätningar till att avgöra om jag behöver göra Langsathers modifikationer på stråken samt var stråken skall modifieras.

Mätning av knackspektra

Följande utrustning används vid mätningarna.

  • En Røde NT1 mikrofon med stort membran.
  • Behringer UMC404HD USB ljudkort med fyra mikrofoningångar med Phantom spänningsmatning.
  • Ljudet mäts och processas med programmet Audacity på en iMac dator. Notera att det går att sätta upp samma mätomgivning på en Windows PC eller på en PC som kör Linux.
  • Fourierspektrum mäts för knackspektra med ett fönster med storleken 16834 mätpunkter. Fönstret måste använda många punkter för att vi skall få fram de detaljer i spektret vi studerar. Om vi har ett fönster med t.ex. 1024 punkter så kan vi inte stämma stråken till en specifik frekvens med precisionen +/- någon Hz.
  • Som hammare använder jag skaftet av en kökskniv helt i metall. Jag vill mäta knacktonen från stråken inte hammaren, därför vill jag att hammaren har helt annan täthet och hårdhet än stråken.

Knackspektra är intressanta genom att det mänskliga örat uppfattar att en knackning har en ”tonhöjd” trots att ett spektrum beräknat på knackljudet kan uppfattas som mest brus. Det visar sig dock att det i allmänhet i spektret finns en eller flera toppar inom det område det mänskliga örat är mest känsligt (300-3000Hz). Örat är mindre känsligt för lägre och högre frekvenser. Notera dock att det mänskliga örat hör över ett betydligt bredare spektrum (20-20000Hz) men att den största känsligheten är den ovan angivna. Det mänskliga örat kommer alltså att fungera som ett bandpassfilter.

Min uppfattning är att hjärnan ganska fritt kan välja frekvenstoppar från knackspektrets låga frekvenser och sätta stämpeln ”grundton” på den frekvensen. Lyssnaren uppfattar då att knacktonen har en tonhöjd som motsvarar ifrågavarande frekvenstopp. Ett problem är dock att hjärnan kan ha flera lämpliga toppar att välja mellan vilket leder till att olika personer kan uppfatta tonhöjden i samma knackning olika!

Som avslutning på den här artikeln visar jag ett knackspektrum för den kinesiska stråke jag använder som experimentmaterial. Notera att jag knackade endast tre gånger då jag mätte utgångsläget. Det visar sig att det lönar sig att knacka 10-20 ggr och beräkna spektret för hela knacksekvensen. Många knackningar ger ett mera lättläst spektrum.

Pilen visar på den obestämda topp vi vill förstärka genom slipning/sickling runt knackstället. Vi vill få fram en distinkt frekvenstopp nära 252 Hz så att samma topp återfinns längs hela stråken.

I nästa artikel i serien tittar vi på hur stämningsprocessen i praktiken kan ske. Jag är intresserad av kommentarer från läsare som använder en liknande teknik samt också av beskrivningar av andra metoder för justering av en stråke.

Att hacka GarageBand (del 3)

15/04/2020

Landet är nedstängt till följd av Coronaepodemin. Vårt spelmanslag har inte spelat ihop på flera veckor … vi är naturligtvis laglydiga medborgare men det må vara tillåtet att som finnens säger ”purna” eller på svenska svära över situationen.

Jag har i tidigare artiklar skrivit om hur vi försöker hålla igång verksamheten trots att det inte går att samlas för att spela. Vi försöker spela in låtar på distans så att någon startar projektet genom att skapa ett bottenspår till vilket var och en hemma kan utarbeta ett eget spår som sedan kan mixas ihop med bottenspåret … bottenspåret kan naturligtvis falla bort under processen då det inte längre behövs.

Patrik Harald vår basist gjorde ett trevligt basspår med bakomliggande rytmtrack. Vi har i olika sammanhang improviserat kring motsvarande spår (ofta då gitarrackord). Här är mitt försök till improvisation på Patriks spår.
Arbetsgången var följande:
  • Jag försökte sjunga till spåret d.v.s. hitta vettig tonhöjd som inte skär sig med bakgrunden. Bluesskalan är relativt enkel vilket gör att det finns ganska få toner att välja mellan.
  • Började lägga till lite text … helt ur fantasin d.v.s. ”sjöng vad spottet förde i min mun”.
  • Tog fasta på någon textrad och skrev så småningom ner ett antal verser. Det är oftast lättare att utveckla en melodi om verserna har en fast form och textens rytm från vers till vers någorlunda passar ihop.
  • Började försöka sjunga texten till spåret med många förändringar på vägen. Gissar att det spår som finns på videon kanske är version 20, eller mer,  och det innehåller fortfarande många fel som kunde slipas bort och förbättras.
  • När sången fanns på plats gjorde jag detsamma på hardangerfiol men följde naturligtvis sången. GarageBand var här till god hjälp eftersom det gick att följa ljudspåret grafiskt vilket gjorde att jag kunde se hur mycket tid jag hade i luckorna mellan sångdelarna att lägga till fiolgnissel.
  • När ljudet någorlunda låg på plats så att man inte behöve skämmas allt för mycket körde jag ut resultatet som MP3 och använde gratisprogrammet OpenShot på PC (Linux) till att göra en video. Jag grävde igenom mitt bildarkiv och sökte möjligast mörka hotande bilder för att matcha musiken. Jag tog en serie bilder av hus ritade av arkitekten/vissångaren Bosse Österberg mitt på natten i fullmåne.  Bilden för nästsista versen med löv av guld är tagen vid samma tillfälle på natten i gul gatubelysning (natriumljus) som matchar bra mot det naturliga månskenet. Det videospår man ser är kanske version fem eller något åt det hållet.

Låten nedan (som fanns också i den föregående artikeln) har alltså skapats utan att personerna som har gjort låten över huvudtaget har träffats fysiskt. Det skulle naturligtvis ha varit trevligare att träffas för att jamma i grupp men eventuellt är Coronametoden mera produktiv då det blir kvar ett hörbart resultat.

 

 

Att ”hacka” GarageBand (del 2)

02/04/2020

I den första delen av den här artikelserien diskuterade olika inspelningsprogram för Windows, Mac och Linux. Eftersom det finns Mac-användare i spelmanslaget så verkar GarageBand vara ett möjligt relativt enkelt program som kunde användas för utspridd inspelning av olika låtar så att de olika medlemmarna i spelmanslaget spelar in olika spår som sedan kombineras.

En känd begränsning som GarageBand har är att det är möjligt att importera MIDI till GarageBand men programmet tillåter inte export av MIDI. Ett problem är då att det kan vara besvärligare att modifiera existerande bas- och andra slingor i programmet än om man använde ett annat program bättre lämpat för just detta ändamål.

Programmet GbConverter, ett enkelt övningsarbete

Programmet GarageBand hanterar internt MIDI men exporterar inte spår eller delar av spår som midi. Detta är sannolikt ett medvetet marknadsföringsval.

GarageBand är ett gratisprogram som kan laddas ner från Apple store. Till programmet kan dessutom laddas ner ett rätt stort paket med ljud för Midi-instrument och låtslingor. Totalt bortåt 15GB färdiga ljud och slingor finns tillgängliga utan kostnad.  Trots att det finns mängder av slingor så hör en stor del till kategorin ”pop” vilket inte är speciellt intressant för ett spelmanslag som spelar traditionell, främst nordisk, folkmusik. Nya slingor, som passar bättre till folkmusik, borde alltså skapas. GarageBands oförmåga att exportera slingor som MIDI-filer gör att det är svårare att ”stjäla” och modifiera existerande slingor. Modifikation av en MIDI-fil  kan rätt enkelt göras i MuseScore som är ett notskriftsprogram med öppen källkod d.v.s. ”gratis”.  Orsaken till att export av MIDI saknas är sannolikt att GarageBand har en storebror med i princip samma användargränssnitt men med utökad funktionalitet bl.a. export av MIDI. Storebror heter Logic Pro som naturligtvis klarar av att exportera MIDI-filer.

Skärmavbild 2020-04-01 kl. 11.30.35

Bilden visar utt urklipp från GarageBand där jag har importerat en sekvens grundackord från MuseScore i form av en MIDI-fil. Jag har i GarageBand klippt spåret i fyra delar (ackorden C, F, G och slutackord C). Antag nu t.ex. att jag vill ha tillgång till motsvarande eventuellt något modifierade slingor också i tretakt (vanligt i nordisk folkmusik) och i de vanligaste tonarterna C-, G-, D-, A-dur … I MuseScore har jag bra kontroll över transponering och kan enkelt lägga till rytmfigurer. Att modifiera melodislingor eller MIDI track i GarageBand kan göras men det är jobbigare än att använda en noteditor.

MIDI-export kan trots begränsningen i GarageBand göras rätt enkelt genom att utgå från GarageBands melodislingor (loop) som är lagrade i filer av typen .aif . Då man Googlar på detta filformat så hittar man t.ex. följande information:

Data format

En AIFF fil är uppdelad på ett antal block (chunk). Varje block idetifieras genom ett block ID (chunk ID) som som kallas FourCC. FourCC har sina rötter i Amiga datorns (i saligt minne) filformat. FourCC är en unik serie på fyra tecken som identifierar innehållet i ett block. Det MIDI-block vi plockar ut ur .aif filen börjar med teckensekvensen ‘MHdr’.

En AIFF fil kan innehålla följande blocktyper:

  • Ett allmänt block (måste finnas). Common Chunk
  • Ljuddatablock (måste finnas). Sound Data Chunk
  • Utmärkning. Marker Chunk
  • Instrumentblock. Instrument Chunk
  • Kommentarblock. Comment Chunk
  • Namnblock. Name Chunk
  • Författare block. Author Chunk
  • Copyright block. Copyright Chunk
  • Annoteringsblock. Annotation Chunk
  • Audio inspelningsblock. Audio Recording Chunk
  • MIDI datablock. MIDI Data Chunk
  • Applikationsblock. Application Chunk
  • ID3-block. ID3 Chunk

Vi ser att filen innehåller ljuddata (okomprimerad i princip .WAV) samt en hel del annan information. Det vi är intresserade av ligger nära slutet d.v.s. vi hittar ett MIDI-datablock.

Vi googlar vidare och hittar en beskrivning på hur en MIDI-fil är uppbyggd. MIDI-blocket börjar med rubriken ‘MHdr’ och MIDI-blocket avslutas med  ‘CHS’. För att en MIDI-fil skall kunna läsas in i ett program behövs ytterligare kodsekvensen ’00’, ‘FF’, ‘2F’ och ’00’ som hexadecimala tal. Sekvensen anger att MIDI-filen är slut.

För att plocka ut MIDI ur en GarageBand .aif fil behöver vi alltså skriva ett program som läser .aif-filen och söker efter ‘MHdr’ samt ‘CHS’. Om dessa markörer hittas så skrivs hela området mellan makörerna (inklusive markörerna) till en fil som avslutas med kodsekvensen ’00’, ‘FF’, ‘2F’ och ’00’ (notera att sekvensen bestå av en Amiga fourCC kod). Ett enkelt program i t.ex. programmeringsspråket Python med denna funktionalitet kan hackas ihop mycket snabbt men det måste då köras i en terminal från kommandoraden. För att programmet skall se ut som en normal Mac applikation så måste det ha ett matchande grafiskt användargränssnitt.

Skärmavbild 2020-04-01 kl. 12.43.19

Konversionsverktyget GbConverter skrivet i Lazarus (Pascal).

Att skriva i Lazarus (Pascal)

Programmeringsprojektet inleds genom att projektet namnges i vårt fall GbConverter. Då projektet skapas så väljer man samtidigt vilket bibliotek som används vid bygge av användargränssnittet. Jag använder det nyare Cocoa eftersom nyare versioner av macOs kommer att använda Cocoa vilket bör ge längre livslängd på programmet eftersom den gamla varianten långsamt fasas ut då nyare versioner av operativsystemet lanseras.

Jag startar Lazarus (Version 2.0.6) som jag tidigare hade installerat, installationen hör inte till denna artikelserie. Projektet är GbConverter.

Jag börjar med att fundera ut vilka grundkomponenter, fönster och fönsterkomponenter, jag behöver. Jag identifierar följande komponenter:

  • Ett huvudfönster som heter GbConverter och som är det användaren normalt kommer att se.
  • På huvudfönstret lägger jag en kortfattad instruktion.
  • Jag behöver ett katalognamn för den plats dit den extraherade midifilen skall skrivas.
  • Jag behöver ett filnamn för den extraherade midifilen.
  • Jag behöver ett fönster som visar konversionsprocessen och som ger information om eventuella fel.
  • En knapp öppnar en väljare för destinationskatalog.
  • En knapp väljer filen som skall konverteras.

Jag behöver ett fönster som beskriver programmet. Detta fönster kopplas till den standardmenu som skall finnas på varje programs Menurad överst på skärmen då programmet kör och är aktivt.

I den här versionen av programmet öppnar jag ett separat fönster för val av fil som skall konverteras. Detta görs som ett experiment för att se hur kommunikation mellan fönster kan göras. I en senare version av programmet plockar jag antagligen bort detta fönster eftersom en filvalsdialog lika väl kan anropas direkt från huvudfönstret.

Skärmavbild 2020-04-01 kl. 23.19.45

Lazarus programmeringsomgivning där de tre fönstren har ritats upp med hjälp av en fönstereditor.  Dessa fönster och komponenterna i fönstren kommer att generera tre pascal källkodsfiler  unit1_GbConverter, Unit1 samt Unit2. Då fönstren + komponenterna skapas så skapas samtidigt skelettkod i ovanstående moduler (unit1_GbConverter, Unit1 samt Unit2). Det är nu programmerarens uppgift att skriva kod inne i de färdiga tomma procedurer som skapats. Ett enkelt exempel:

Knappen <Set up ‘mid’ destination> skall hämta namnet på den katalog till vilken den utplockade MIDI-filen skall skrivas. Detta hanteras så att då man klickar  <Set up ‘mid’ destination> så förstår programmet automatiskt att det skall anropa proceduren (skelettet):

procedure TForm1.Button3Click(Sender: TObject);
Begin
end;

Jag öppnar då ett annat fönster som öppnar en fildialog som ger stigen till den katalog jag vill skriva till. Jag behöver lägga till följande:

procedure TForm1.Button3Click(Sender: TObject);
Begin
  Form2.ShowModal;
  LabeledEdit1.Text := Form2.midPath;
end;

Den första raden Form2.ShowModal; öppnar fönster nummer två (Form2). Den andra raden jag skriver LabeledEdit1.Text := Form2.midPath; kopierar text från det nya fönstrets textområde till huvudfönstrets textområde.

På motsvarande sätt fyller jag stegvis i kod i övriga av Lazarus skapade procedurer som jag behöver. Programmet kan hela tiden kompileras och köras men om kod saknas så finns naturligtvis ingen funktionalitet och det kommer i det färdiga programmet att finnas procedurer som har skapats automatiskt men som inte innehåller någon kod och som således är inaktiva. Intresserade läsare kan titta på källkoden till programmet som finns i zip-filen i slutet av artikeln.

Programmet innehåller en enda procedur som utför hela arbetet efter att man har definierat skrivkatalog, filnamn på fil som skall skrivas samt namnet på den fil som skall konverteras.

Koden är följande:

procedure extractMidi(filename:String);
var Ms:TMemoryStream;
Fs:TFileStream;
startMidi,endMidi,endCodeStart:Int64;
B : array of Byte;
fileSize : Integer;
pattern: TPatternArray;
begin
  Form1.Memo1.Lines.Add('Get contents of:'+filename);
  if not FileExists(filename) then Exit;
  destPath := Form1.LabeledEdit1.Text;
  if destPath='' then
  begin
    Form2.ShowModal;
    Form1.LabeledEdit1.Text := Form2.midPath;
    destPath :=Form2.midPath;
    Form1.Memo1.Lines.Add('Selected MIDI output destination:'+destPath);
  end;
  destFile := Form1.LabeledEdit2.Text;
  Form1.Memo1.Lines.Add('Set destPath to:'+destPath);
  Form1.Memo1.Lines.Add('Set destFile to:'+destFile);
  Form1.Memo1.Lines.Add('Set destFile to:'+destPath+'/'+destFile);
  if not DirectoryExists(destPath) then
  begin
    Form1.Memo1.Lines.Add('Error:'+destPath+' does not exist');
    Exit;
  end;
  if FileExists(destPath+'/'+destFile) then
  begin
    if DeleteFile(destPath+'/'+destFile) then
    begin
      Form1.Memo1.Lines.Add('Deleted old version of .mid file');
    end else
    begin
      Form1.Memo1.Lines.Add('Error: Could not delete old version of .mid file');
    end;
  end;
  Ms := TMemoryStream.Create;
  Ms.LoadFromFile(filename);
  filesize := Ms.Size;

  try
  Ms.Position := 0;
  Form1.Memo1.Lines.Add('Read Loop file.');
  Form1.Memo1.Lines.Add('Size='+IntToStr(fileSize));
  { Searching for 'MTrk' in the FileStream }
  pattern := StringToByteArray('MThd');
  startMidi := DoSearch(Ms,pattern);
  { Ensure we continue from 'MThd' forward }
  Ms.Seek(4,startMidi);
  pattern := StringToByteArray('CHS');
  endMidi := DoSearch(Ms,pattern);
  Form1.Memo1.Lines.Add('Looked for MIDI start=MThd, res='+IntToStr(startMidi));
  Form1.Memo1.Lines.Add('Looked for MIDI end=CHS, res='+IntToStr(endMidi));
  if (startMidi>0) and (endMidi>0) then
  begin
    Form1.Memo1.Lines.Add('Extract MIDI');
    //filePath := ExtractFilePath(filename);
    Form1.Memo1.Lines.Add('File path:'+destPath);
    Form1.Memo1.Lines.Add('Output File name:'+destPath+'/'+destFile);
    Fs := TFileStream.Create(destPath+'/'+ destFile, fmCreate);
    { Read into temporary buffer }
    SetLength(B,(endMidi-startMidi + 16));
    Ms.Position := startMidi;
    { We include the start and end codes (4=MTrk)(3=CHS)}
    Ms.Read(B[0],(endMidi-StartMidi+3));
    endCodeStart := endMidi-StartMidi+4;
    { Add MIDI end of track mark }
    B[endCodeStart]:= $00;
    B[endCodeStart+1]:= $FF;
    B[endCodeStart+2]:= $2F;
    B[endCodeStart+3]:= $00;
    { Write Buffer to FileStream }
    Fs.Write(B[0],(endMidi-StartMidi+3));
    Fs.Free;
  end else
  begin
    Form1.Memo1.Lines.Add('Invalid LOOP file, MThd and/or CHS not found.');
    Exit;
  end;
  finally
    Ms.Free;
  end;
end;

Programtexten bör vara relativt enkel att läsa. De första ca. 30-raderna är endast kontroll av möjliga fel d.v.s. kontroll att destinationskatalogen finns etc. Om filen som skall konverteras inte finns så ger programmet upp genast. Det egentliga arbetet börjar vid:

Ms.MemoryStream.Create;
Ms.LoadFromFile(filename);
filesize := Ms.Size;

Vi läser in hela .aif filen i maskinens minne. I mitt testfall är det ungefär 400 000 tecken eftersom aif-filen också innehåller ljuddata (WAV).  Alla rader som innehåller Form1.Memo … skriver till informationsfönstret så att man skall kunna se om något går fel. Dessa raders enda funktion är att informera om hur långt vi har kommit i konversionen och dessa rader kunde lämnas bort utan att programmets funktion ändras.

pattern := StringToByteArray('MThd');
startMidi := DoSearch(Ms, pattern);

Vi söker efter strängen som indikerar början på midi blocket.

Ms.Seek(4,startMidi);

Vi ställer en pekare så att vi fortsätter sökandet efter den hittade startpunkten. Det kunde annars, om vi skulle söka efter ‘CHS’ från början av filen,  hända att teckenserien vi härnäst söker efter ‘CHS’ kunde tänkas finnas i det redan avsökta området vilket skulle ge fel och eventuellt leda till mycket intressanta bieffekter då det funna blocket skall skrivas till skiva (sannolikt skulle krogrammet krascha och eventuellt skulle maskinen låsa sig). Därefter söker vi slutet på midifilen på motsvarande sätt.

pattern := StringToByteArray('CHS');
endMidi := DoSearch(Ms, pattern);

Om vi har hittat både en startpunkt och en endpunkt så antar vi att det som finns mellan dessa punkter är den MIDI-fil vi vill plocka ut.

Vi läser in MIDI-området i en temporär buffert som jag kallar B och som är tillräckligt lång för att rymma MIDI-filen.  Vi skapar en Fil-ström som vi senare använder för att skriva midifilen till skiva.

Fs := TFileStreamCreate(destPath+'/'+destFile);

Vi läser in midi-området i bufferten B innan vi skriver till skiva för vi vill modifiera filen en aning innan vi skriver den. Vi beräknar platsen i bufferten där midi-blocket är slut d.v.s. efter ‘CHS’ men så att ‘CHS’ också skrivs till skiva.

Ms.Read(B[0],(endMidi-startMidi+3);
endCodeStart := (endMidi-startMidi+4);

Vi lägger nu till stoppkoden som signalerar till något annat program som läser midifilen att midifilen är slut.

B[endCodeStart] := $00;
B[endCodeStart+1] := $FF;
B[endCodeStart+2] := $2F;
B[endCodeStart+3] := $00;

Slutligen skriver vi resultatet till skiva och är färdiga att börja behandla följande .aif fil.

Fs.Write(B[0],(endMidi-startMidi+8));
Fs.Free

Sökning i minnet

Att söka efter en textsträng i en s.k. binärfil är besvärligare än att söka i en normal textmassa. Sökning i en text kan göras med en mängd färdiga verktyg. Sökning i en binärfil blir mera komplicerad av att vilka tecken som helst kan förekomma också tecken som har specialbetydelse i en vanlig text och som kan få en sökfunktion att tappa bort sig. Sökningen görs med hjälp av en kort sökfunktion :

function DoSearch(Stream: TMemoryStream; Pattern: TPatternArray): Int64;
var
  idx :Integer;
begin
  result := -1;
  for idx := Stream.Position to Stream.Size - Length(Pattern) do
  begin
    if CompareMem(Strem.Memory + idx, @Pattern[0], Length(Pattern))
    then exit(idx);
  end;
end;

Wi söker alltså direkt i maskinens centralminne i en kopia på GarageBands aif fil vilket gör sökningen snabb också på en gammal och i princip långsam iMac som den jag har.

Det kan vara kul att titta på kostnaderna för de iMac-ar jag har satt upp för musikprojektet.

Den maskin jag skrivit programmet på är en 21,5 tums iMac från 2009 med 12 GB centralminne och 500 GB SSD hårdskiva. Totalpris ca. 100E efter minnesuppgradering och byte av en urgammal mekanisk hårdskiva som sannolikt sjöng på sista versen till SSD-skiva.

Anders, en god vän kör en 24 tums iMac årsmodell 2007 uppgraderad till maximalt 6GB centralminne med SSD hårdskiva. Pris totalt under 100E efter uppgradering … inköpt för 10E utan hårdskiva.

Det är intressant att notera att då jag inte spelar datorspel så fungerar båda maskinerna utmärkt utan att visa några som helst ålderskrämpor i form av störande tröghet gällande de program jag använder (Garageband, OpenOffice, Vebbläsare och Lazarus).

(Följande artikel beskriver hur det ”hackade” systemet används)

 

 


Pointman's

A lagrange point in life

THE HOCKEY SCHTICK

Lars Silén: Reflex och Spegling

NoTricksZone

Lars Silén: Reflex och Spegling

Big Picture News, Informed Analysis

Canadian journalist Donna Laframboise. Former National Post & Toronto Star columnist, past vice president of the Canadian Civil Liberties Association.

JoNova

Lars Silén: Reflex och Spegling

Climate Audit

by Steve McIntyre

Musings from the Chiefio

Techno bits and mind pleasers

Bishop Hill

Lars Silén: Reflex och Spegling

Watts Up With That?

The world's most viewed site on global warming and climate change

TED Blog

The TED Blog shares news about TED Talks and TED Conferences.

Larsil2009's Blog

Lars Silén: Reflex och Spegling