1 Problemanalyse Unified Modeling Language Problemformulering... 4

Transkript

1 Indhold 1 Problemanalyse Unified Modeling Language Problemformulering Designfase Design af filtre Frekvensområde og opdeling i frekvensbånd Udregning af knækfrekvenser Program til udregning af knækfrekvenser Båndpasfiltre til analyzer Digital filterdesign Design af software Softwaredesign Fejlhåndtering CExternal System V IPC Tilfældet CExternal Test CSound Behandling af data til CSoundCard Afspilning af pink noise Fejlhåndtering Testramme for funktionerne Interface til lydkort Initialisering af lydkort Afspilning og optagelse Test CAnalyzer Båndpasfiltrenes RMS-værdier

2 2 Indhold Returnering af RMS-værdier Fejlhåndtering Testramme for funktionaliterne Den grafiske brugerflade Qt Projektets grafiske brugerflade CButton GraphWindow Kodning af en speciel Qt widget CSliderWindow CPlayWindow Figurer der mangler at blive indsat Konklusion 39 5 Nomenklaturliste 40 A Mikrofon 41 A.0.1 Forsøg i lyddødt rum B Apparaturliste 44 C Komponentliste 45

3 1 Problemanalyse Projektoplægget til dette projekt henvender sig bl.a. til computerentusiaster og -interesserede, der ønsker den bedst opnåelige lyd fra en PC. Dette mål kan nås vha. et system bestående af en analyzer og en equalizer, hvorigennem frekvensindholdet i lyden korrigeres. Systemet vil være til gavn for såvel afspilning af musik og film som lyd fra spil, da systemet giver en bedre lydoplevelse for brugeren. Om systemet skal bestå af hardware og software eller være ren software er afhængigt af markedsefterspørgsel, men da PC er efterhånden bliver kraftigere og har en større ydeevne, vil det være fordelagtigt, at det er et software system, idet systemsintegration er mere enkelt end, hvis det er et system delvist af hardware og software. En ren softwareløsning kræver kun installation af et program, hvorimod en ny hardwareenhed kræver installation af såvel et program som tilslutning af en ekstern eller intern enhed. Idet Gruppen og dens medstuderende, som computerbrugere, vil være en del af målgruppen for produktet, vil det være nærliggende at opsætte kriterier for kravene udfra denne mindre gruppes ønsker til system funktioner. Til opstilling af kravene benyttes det objektorienterede designsprog, UML Unified Modeling Language UML anvendes til design af systemer, hvor der tid, arbejdskraft og succes er væsentlige faktorer for udviklingen og konstuktionen, da der med en godt UML-analyse og -design foreligger muligheden for elimeneringen af spildtid. Desuden skaber UML det fornødne overblik i projektarbejdet med henblik, således projektet former og antager de bestemte egenskaber og opfylder de fastsatte kriterier for systemet. Gennem et UML-forløb analyseres systemet, der ønskes konstrueret, først, hvorefter der foretages et design af indholdet i analysen. Udgangspunktet for analysen af problemet, og det efterfølgende design af systemet er en række Use-cases. En use-case er et værktøj der benyttes i samarbejde med en kunde, og bruges til at finde krav til et system ud fra brugerens synspunkt, og uden nogen forhåndsviden om den efterfølgende implementation. Use-cases stilles typisk op i tekstform ud fra kundernes udsagn om hvad de ønsker fra systemet. I projektgruppen fandtes følgende use-cases: Brugeren trykker på en knap og det måltes frekvensgang reguleres efter den ønskede frekvensgang. Brugeren skaber den frekvenskarakteristik han ønsker højttaleren (og rummet) skal have i målepunktet. 1 Unified Modeling Language

4 4 Problemanalyse Brugeren trykker på en knap og får vist højttalerens (og rummets) frekvenskarakteristik (ved mic. placering). Brugeren trykker på en knap og får grafisk præsenteret det måltes frekvensindhold i realtid. Brugeren skal kunne afspille lyd, således at det behandles gennem equalizeren. De fundne use-cases tegnes ind i et use-case diagram, som ses i figur??. Denne type diagram viser de enkelte use-cases, indkapslet i det system de tilhører, samt deres forbindelse til eksterne aktører. Aktører er i denne sammenhæng alle brugere eller systemer der kommunikerer med det analyserede system. To undersystemer, analyzeren og equalizeren, er ved udarbejdelse af use-case diagrammet blevet defineret, og de fem usecases er blevet samlet i systemet GUI 2, da det er dette undersystem brugeren ser. Andre use-case diagrammer for undersystemerne analyzer og equalizer vil blive udarbejdet under design. Som accepttest, for at bestemme om systemet senere opfylder de stillede krav, vil de enkelte use-cases blive gennemløbet. Hvis en given use-case, i tekstform, er sand for det konstruerede system, betragtes testen som bestået. 1.1 Problemformulering Problemet som gennem projektet skal løses kan formuleres som følger: Hvordan opbygges et system der kan kompensere for dårlig lyd i (multimedie-) højttalere? 2 Graphical User Interface

5 2.1 Design af filtre 2 Designfase For at analysere signalets frekvensindhold, sendes dette gennem et givet antal båndpasfiltre. Antallet af filtre, og båndpasbredden bestemmes af frekvensområdet der analyseres i, og båndopdelings-metoden Frekvensområde og opdeling i frekvensbånd Det hørbare område strækker sig fra 20 Hz til 20 khz[*note *], hvorfor dette frekvensområde vælges. Opdeling i frekvensbånd foretages efter konstant procentopdelt båndbredde, det vil sige, at båndbredden udgør en konstant procentdel af den enkelte centerfrekvens. Båndbredden opdeles efter oktav-princippet, dette medfører en logaritmisk frekvensskala, hvilket er i overensstemmelse med den måde, hvorpå det menneskelige øre hører. Den procentdel af centerfrekvensen som båndbredden udgør, bestemmes efter følgende formel: 2 1 N (2.1) litt. henvisning!!!, hvor 1 N angiver båndbredden i oktav. Ofte benyttede båndbredder:1 1, 1 3, 1 12 og 1 24 oktav. (?) Udregning af knækfrekvenser Ifølge afsnit XX[*Note *] skal der kunne vælges et vilkårlig antal bånd. Dette løses ved at angive 1 N oktav båndbredde som input til et program, der opdeler frekvensområdet i F antal Bånd. Desto højere værdi, der påtrykkes N desto højere F, hvormed opløsningen i frekvensområdet øges. fra samme program returnerer samtlige knækfrekvenser i frekvensområdet. ref til noget krav/design Program til udregning af knækfrekvenser Der tages i programmet udgangspunkt i en centerfrekvens på 1000Hz og 1 1 oktavs båndbredde. Udfra disse og båndbredden 1 N findes de resterende centerfrekvenser f C_x i frekvensområdet således (se figur 2.1): f C_x f C_D 2 x 1 N (2.2)

6 6 Designfase 1/1 oktav båndbredde N N N 1/N oktav båndbredde x 1/N oktavs centerfrekvenser f C_x Hz D 1/1 oktavs centerfrekvenser f C_D Hz Figur 2.1: Forhold mellem opdeling i 1 N og 1 1 oktav båndbredde., hvor f C_D D D udgør de forskellige 1 1 oktavs centerfrekvenser, og x N angiver opdeling i de nye 1 N oktavs centerfrekvenser f C_x imellem de to tilhørende 1 1 oktavs centerfrekvenser (se figur 2.1). Der gives følgende tal-eksempel ved D 0 x 2 og 1 3 oktav: f C_x Hz Udfra de fundne centerfrekvenser f C_x beregnes de tilhørende knækfrekvenser efter en modificeret version af udtrykket 2.1. Udtrykket, der er fremyndet gennem studier af figur 2.1, opdeles i to algoritmer; f HP for nedre knækfrekvens og f LP for øvre. f HP 2 1 N 2 f C_x (2.3) f LP 2 N 1 2 f C_x (2.4) Båndpasfiltre til analyzer Signalets frekvensindhold findes ved at anvende en række båndpasfiltre på signalet for at opdele dette i række frekvensbånd som omtalt i afsnit?? og frem, hvorefter RMS niveauet svarende til energien findes for hvert bånd.

7 Design af filtre 7 db 0 3 Hz f HP f C_x f HP f LP f C_x f LP f HP f C_x f LP Figur 2.2: Filtrenes overlapning. Båndpasforstærkningen skal være 0 db og ved øvre og nedre knækfrekvens skal forstærkningen være faldet til 3dB således at summen af båndpasfiltrenes overføringsfunktioner er 0 db. Filtersummen vil afvige fra 0 db idet nabofiltrene vil overlappe og derved give et yderligere bidrag. Størrelsen af dette bidrag afhænger derfor af filterordnen og båndbredden. Således at en højere orden og større båndbredde giver en mindre afvigelse. Filtreordenen kan bestemmes ud fra krav defineret i anderkendte standarder f.eks DIN. Idet analyseren skal køre i realtid kræves det at de implementerede digitale båndpasfiltre kan procesere en sample og beregne RMS hurtigere end 1 f s. Dette betyder at filterorden og antal filtre begrænses af maskinens regnekapacitet. Idet båndpasfiltrene skal være symmetriske skal høj- og lavpas filtrene være af sammme orden, dette medfører at båndpasfilterets orden altid vil være lige. Der ønskes maksimal fladhed i pasbåndet, hvilket betyder at typen skal være af Butterworth. Dette svarer til at filterets poler ligger på en cirkel med radius Ω 0 og er fordelt lige i s-planets venstrehalvplan som skitseret på figur 2.3 på den følgende side. Det generelle Butterworth lavpasfilter af N te orden hvor pasbåndsforstærkningen er 0 db kan udtrykkes som formel 2.5. H l p s Θ N Ω 0 s Ω 0 e jθ (2.5) n 1 π 2n 1 2N π 2 Af beregnings grunde opdeles det generelle Butterworth filter af N te orden i en række 2. ordens filtre med komplexkonjugerede poler samt et 1. ordens filter ved ulige filterorden. En kaskadekobling af disse 1. og 2. ordens sektioner vil give det ønskede Butterworth filter. Generelt 2. ordens filter i frekvensdomænet med Laplace operatoren s.

8 8 Designfase a b Figur 2.3: a) 2. orden og b) 3. ordens polplacering i s-domænet H 1 H 2 P Ω 0 e jθ a Ω s 0 s P s s P Ω 2 0 jb Ω 0 s Ω 0 s P Ω 2 0 s 2 2Ω 0 cos Θ s Ω 2 0 s 2 2as a 2 Ω 2 0 b 2 (2.6) Eksempel på et 5. ordens lavpas filter som skal indgå i et 10. ordens båndpasfilter. H l p s Θ n Θ 1 Θ 2 Ω 2 0 s 2 2Ω 0 cos Θ 1 s π 2n 1 π π π 144 Ω 2 0 Ω 2 0 s 2 2Ω 0 cos Θ 2 s Ω 2 0 Ω 0 s Ω 0 (2.7) TODO?: Bestemmelse af minimum filterorden for eks. 1 og 1/3 oktav bp-filtre Digital filterdesign Udfra filtrets overføringsfunktion i det analoge s-domnæne skal dette z-transformeres. Dette kan gøres ved matched, impuls invariant eller bilineær z-transformation. I denne situration anvendes bilineær z-transformation for at udgå aliasing. Aliasing er et problem for de øvre båndpasfiltre som ikke er væsentligt dæmpet ved den halve samplingsfrekvens. Dette vil medføre en amplitude karakteristik som afviger væsentligt fra det analoge prototype filter.

9 Design af software 9 Bilineær z-transform: Ved at anvende denne transformation undgås aliaserings fejl og er derfor den beste tilnærmelse til det prototype filtret. Ved denne transformation erstates s i teorien af formel 2.8 men da ln ikke er på lukket form laves en rimelig tilnærmelse. s s 1 lnz (2.8) T d 2 T d 1 z 1 1 z 1 (2.9) Ved transformationen bliver venstre halvplan i s domænet kortlagt i z domænet inden for enhedscirklen, således bliver Ω til π ω π. Dette betyder at den analoge frekvens Ω bliver komprimeret og derfor er det nødvendigt at udføre en prewarp af knækfrekvenserne for at rette op på frekvenskarakteristikken af de digitale filtre. ω 2arctan ΩT d 2 (2.10) De fundne 1. og 2. ordens sektioner z-transformeres individuelt idet koeficienterne umiddelbart kan beregnes udfra formler udledt fra det generelle frekvens normerede 1. og 2. ordens filter i s-domænet. De digitale filtre er implementeret i C++ højniveau software og derfor er der ikke noget krav fra dedikeret DSP hardware om en given filter struktur. For at minimere mængden af lokal hukommelse til båndpasfiltrene er det samlede filter udregnet således at differensligningen for filtret kan implementeres på en enkelt programlinie. y n a 0 y n a 1 y n 1 b 0 x n 1 b 1 x n 1 RMS værdien skal findes for hvert udgangssignal fra båndpasfiltrne. RMS værdien er et kvadratiskgennemsnit for signalets niveau over perioden T. RMS værdierne skal præsenteres grafisk på analyserens brugerflade og skal derfor opdateres med en rimelig hastighed så brugeren af analyseren kan danne sig et korrekt indtryk af signalet. RMS 1 T T y n 2 n 0 (2.11) 2.2 Design af software [*Note *] skal de private metod (cleanup)

10 10 Designfase sendsignal() Trigger fra knap eller objekt. Benyttes til at starte forløb i et andet subsystem (analyzer/equalizer eller GUI). (er ikke sikker; flag, semaphore, messagequeue etc.). receivesignal() Signal fra sendsignal(). Modtager startsignal fra andet subsystem (analyzer/equalizer eller GUI). Metodekald. senddata() data:short[], target:short. Sender data fra et subsystem til et objekt (target:short) i et andet. (Kald til subsystem) data:short[], target:short receivedata() data:short[], target:short. Modtager data fra andet subsystem og foretager et metodekald ud fra target. Metodekald samt data:short[] getstatus() Henter aktuel status for system currentstatus:short setstatus() short fra knaptryk eller receivesignal() i CExternal Opdaterer currentstatus:short Tabel 2.1: Metodespecifikation for CExternal.

11 Design af software 11 quit() Tryk fra bruger på GUI-knap Sender signal til analyser/equalizer om at lukke processerne og lukker GUI Kald af sendsignal i CExternal og close showspkchar() Tryk fra bruger på GUI-knap Sender signal til analyser/equalizer om at vise højttalerens frekvenskarakteristik Kald af sendsignal og setstatus i CExternal showrtfreq() Tryk fra bruger på GUI-knap Sender signal til analyser/equalizer om at vise frekvensindholdet i realtid Kald af sendsignal og setstatus i CExternal correctspeakers() Tryk fra bruger på GUI-knap Sender signal til analyser/equalizer om at starte korrektionen af højttalerne Kald af sendsignal og setstatus i CExternal playsong() Tryk fra bruger på GUI-knap Sender signal til?????? Kald af sendsignal i CExternal og setstatus stopplaying() Tryk fra bruger på GUI-knap Sender signal til?????? Kald af sendsignal i CExternal og setstatus storewanted() Tryk fra bruger på GUI-knap Sender signal til?????? Kald af sendsignal i CExternal og setstatus setdefaults() Tryk fra bruger på GUI-knap Sender signal til?????? Kald af sendsignal i CExternal og setstatus setstatus()????? Sender signal til?????? Kald af?????? fetchstatus()????? Sender signal til?????? Kald af????? Tabel 2.2: Metodespecifikation for CButton.

12 12 Designfase playnoise() Afspiller en fil med pink noise outputsound() Sender data fra sound:signed short[] til CSoundCard Tabel 2.3: Metodespecifikation for CSound. getipointer() Henter pointer til inputbuffer signed short* getopointer() Henter pointer til outputbuffer signed short* getbufferlength() Henter in- og outputbuffernes længde int init() int bits, int sampling_frequency Initialiserer lydkortet start() Sætter lydkortet i gang med at afspille og optage pause() Pauser afspilning og optagelse stop() Stopper afspilning og optagelse cleanup() int err Lukker lydkortet, unmapper mapped memmory og kaster en fejlbesked Tabel 2.4: Metodespecifikation for CSoundCard.

13 Design af software 13 findrms() filteredseq:signed short[] Bestemmer RMS værdien af en lydsekvens rmscoeff:*char returnrms() Returnerer rmscoeff[] til brug ved grafgeneration. rmscoeff:char[] Tabel 2.5: Metodespecifikation for CAnalyzer. calcdiffkvot() correctedcoeff:double[] Finder forholdet mellem målt energi og energi i pink-noisefilen i de enkelte bånd diffkvot:double[] fetchwanted() Henter ønsket frekvenskarakteristik fra filen <slidervalues> wantedfreqchar:double[] subwantedfromdiff() diffkvot:double[], wantedfreqchar:double[] Beregner og gemmer forskellen mellem den ønskede frekvenskar. og den faktiske i bandamp:short[] og filen <bandamp>. fetchbandamp() Henter båndpasforstærkninger fra filen <bandamp> og gemmer i bandamp:short[] Tabel 2.6: Metodespecifikation for CEqualizer. drawgraph() coeff:double[] Tegner analyzer-graf ud fra modtagne værdier. getcoeff() Koefficienter fra CExternal gemmes i coeff:double[] Tabel 2.7: Metodespecifikation for CGraphWindow.

14 14 Designfase storewanted() Gemmer aktuelle sliderindstillinger i filen <slidervalues> fetchwanted() Henter ønsket frekvenskarakteristik fra filen <slidervalues> double[] Tabel 2.8: Metodespecifikation for CSliderWindow. setsliders() Indstiller sliders; hvis kaldt uden parameter nulstilles sliders og værdierne i filen <slidervalues> fetchsliders() Returnerer aktuelle slider-værdier. double[] Tabel 2.9: Metodespecifikation for CSlider. filtersamples() Filtrerer en række samples, hentet med getsequence i CSound fetchseq() sound:signed short[] Returnerer de filtrerede sekvenser signed short[] Tabel 2.10: Metodespecifikation for CFilter.

15 3.1 Fejlhåndtering 3 Softwaredesign I C++ findes en indbygget mekanisme til fejlhåndtering kaldet exception handling. Via exceptions kan et objekt, der fejler, informere sig selv eller andre i stakken højere placerede objekter om fejlen. Afhængigt af fejlens betydning for afviklingen af hovedprogrammet i main, er exception handleren i simple tilfælde placeret i det fejlende objekt og i mere alvorlige tilfælde i main; typisk dog i main. Exception handling er opbygget omkring brugen af try, throw og catch. I selve objektet indsættes throw-kommandoen på de steder i metoderne, hvor der ønskes en fejlhåndtering. I hovedprogrammets main pakkes de dele af metodekaldene, der ønskes kontrolleret for exceptions, ind i try s klammer. Og slutteligt forefindes catch i main til at opfange de afsendte exceptions fra metodekaldene indkapslet i try. For at sofistikere fejlhåndteringen kan de enkelte exceptions bestå af specifikke argumenter såsom brug af metoder. Tilsvarende opfanges specifikt de enkelte fejlobjekter, og på denne måde kan en præcis fejlbeskrivelse inddelt i forskellige fejlområder håndteres og forevises brugeren. Der findes mange forskellige måder at opbygge fejlhåndteringen på, og den i dette projekt benyttede fejlhåndtering baserer sig på brugen af klasser. Der er således oprettet følgende fire overordnede klasser: GUIErrors. AnalyzerErrors. EqualyzerErrors. MiscErrors. GUIErrors omfatter exceptions fra GUI, og disse vil blive behandlet udelukkende i GUIens egen exception handler, da GUI kører som et selvstændigt program. De resterende omfatter exceptions fra AnalyzerEqualizer-programmet, og indgår således i dette programs fejlhåndtering. Fælles for alle fire klasser er, at der udskrives fejlbeskeder både via GUI og via en konsol, da dette sikrer, at fejlbeskeden når frem. Om nødvendigt giver tekstboksen mulighed for, at brugeren skal tage stilling til hvordan fejlen skal håndteres. Der vil være specialtilfælde, hvor eksempelvis de to hovedprogrammer ikke kan kommunikere, hvilket gør at der ikke kan udskrives en fejlbesked via GUI.

16 16 Softwaredesign Følgende eksempel viser et exception throw fra metoden makeerror(), der programmæssigt er placeret under Analyzer en, hvorfor fejlbeskeder fra denne hører under klassen CAnalyzerErrors. Exception-objektet kommer med to argumenter, hhv. fejlnummeret 1 og en specifik fejlbesked, der i dette tilfælde fortæller brugeren hvilken metode, der fejlede. CmakeError::makeError() {... if(error=1){ throw CAnalyzerErrors(1,"makeError() has made en error!"); }... } Den praktiske opbygning er, at der til main i de to hovedprogrammer er knyttet en fejlhåndteringsfil kaldet CErrors.cpp med en tilsvarende h-fil. Denne indeholder alle fejlhåndteringer, og objekterne oprettes fra main når en exception er opfanget. Et eksempel på et catch med efterfølgende kald af exception handling er: CmakeError err; try /**:INFO: This is the method we want to * test for errors while running. */ { err.makeerror(); } /**:INFO: Here we will catch the specific * errors coming from the CmakeError instances */ catch(canalyzererrors errorinstance){ CErrors pass_to_handler; pass_to_handler.analyzererrors --> (errorinstance.errornumber,errorinstance.errorstring); } I dette eksempel er der tale om, at et objekt af klassen CmakeError fejler med en exception af klassen CAnalyzerError. Dette objekt oprettes med udgangspunkt i følgende fejlhåndtering, som for eksemplets skyld er simpel og udelukkende håndterer fejlen ved, at udskrive fejlbeskeden til hhv. GUI og konsol: CErrors::AnalyzerErrors(int error,string s1) { CExternal outputgui1(analyzererror); CExternal outputgui2(analyzer); switch(error) { case 1: /** :INFO: Writes output to console */ /** :INFO: Standard text for the specific error * number plus the number is written to cout. */

17 CExternal 17 cout << "GUI error number " << error << ":" << endl; /** :INFO: Specific text from the thrown * exception is written to cout. */ cout << s1 << endl; /** :INFO: Writes output to GUI */ outputgui2.sendsignal(error); outputgui2.senddata((char*)s1.c_str()); break; } default: break; } Udskrivning til konsollen er simpel og ligefrem. Ved udskrivning til GUI oprettes derimod et objekt af CExternal med en parameter ANALYZER for at angive, at det er en fejl fra Analyzeren. Derudover benyttes som tidligere fejlnummeret og den specifikke fejlbesked. Selve håndteringen af dette objekt tilhører ikke dette afsnit. For overskuelighedens skyld, er der her ikke inkluderet al koden, og eksemplet er som nævnt et eksempel på opbygningen. Selve implementeringen kan ses i appendiks [*Note *] hvilket appendix indeh den? 3.2 CExternal Klassen CExternal varetager kommunikation mellem de to processer systemet gennem analyse- og designfasen er blevet opdelt i. Denne kommunikation består af to ting: Signaler og data. Signalerne benyttes til at markere hvornår en af processerne skal starte en sekvens af metodekald, for at opfylde kravene fra en specifik usecase. Under behandling af samme usecase opstår behovet for at sende data imellem processerne. Den grafiske brugerflade skal f.eks. have returneret værdier til brug for at tegne analyzer-grafen. For at muliggøre kommunikationen kan findes under Linux (og nogle Unix-systemer) benytte System V IPC 1. System V IPC er en samling af en række systemkald, som stiller følgende værktøjer til rådighed ved kommunikation mellem processer: Semaphores. Shared memory. Message queues System V IPC Semaphores Semaforer er en mekanisme der tillader styring af hvordan forskellige processer afvikles. En proces kan sættes i stå mens den venter på at en semafor får en bestemt værdi, og 1 Inter Process Communication

18 18 Softwaredesign bruger således ingen ressourcer inden dette sker. Andre processer (eller evt. andre tråde i samme proces) kan derefter sætte semaforen, hvorefter afvikling af processen tages op igen. Koordineringen af semaforerne, og de processer der afhænger af semaforerne, varetages af styresystemet, der opretter og vedligeholder en kø der indeholder de aktive semaforer. Delt hukommelse Delt hukommelse (eng. shared memory) er som navnet antyder, et stykke hukommelse som flere processer har adgang til. Ved brug af et eller flere sådanne områder, og med den rette koordinering, kan processer dele data i begge retninger. Koordineringen kan f.eks foregå ved at sætte flag direkte i den delte hukommelse, og polle på disse, eller ved brug af de førnævnte semaforer, hvorved man undgår at polle, og derfor sparer systemressourcer. Message queues e 4kB? Dave? Det tredje værktøj der stilles til rådighed via. System V IPC er message queues. En message queue kombinerer egenskaber fra de to andre værktøjer, og kan således bruges både til styring af andre processers afvikling, og til udveksling af data. En besked sendes som en struct i C++, og kan, ud over en obligatorisk beskedtype, indeholde så mange forskellige datatyper som man har brug for, så længe den samlede mængde ikke overskrider 4 kb[*note *]. Beskedtypen kan i modtagerenden benyttes til at foretage prioritering af beskederne, til at udvælge specifikke beskeder, eller den kan ignoreres, hvilket bevirker at den første besked i køen, uanset type, modtages. Det skal bemærkes at en beskedkø ikke virker efter FIFO 2 princippet. Ved prioriteret modtagelse kan det altså lade sig gøre at tage den sidst ankomne besked ud af køen, hvis den matcher kriterierne bedst Tilfældet CExternal [*Note *] For at løse de opgaver CExternal skal løfte, kan enten en kombination af de to før- ste værktøjer, semaforer og shared memory, eller det sidste værktøj, message queues, benyttes. Da message queues kan håndtere både den indbyrdes styring, der her kaldes signaler, og overførsel af data, vælges denne løsning. Der skal i CExternal-klassen findes tre sæt metoder: sendsignal og receivesignal, der står for den indbyrdes styring mellem processerne, senddata og receivedata, der som navnene antyder, håndterer dataoverførsler, og senderrortype og receiveerrortype, der tager sig af fejlhåndteringens kommunikation mellem GUI og AnalyzerEqualyzer. Følgende afsnit gennemgår implementationen af disse tre metodepar i forhold til brugen af beskedkøen som værktøj. skrift? 2 First In, First Out

19 CExternal 19 Styring Signalerne der skal flyttes med sendsignal og dennes modpart benyttes til at starte sekvenser af metodekald, der svarer til de usecases projektet fra starten er baseret på. Den eneste information der er nødvendig at sende med en besked i sendsignal er således en identifikation af den sekvens der skal startes. Denne gives i sendsignal som et nummer, og den overførte datastruktur består derfor af en long mtype der angiver beskedtypen, og en int signal der identificerer den ønskede sekvens.afhængigt af om CExternals constructor kaldes med parameteren GUI, parameteren ANALYZER, GUIERROR eller ANALYZERERROR sættes sendsignal til at sende beskeder af typen 1, 2, 3 eller 4. Modsvarende sættes receivesignal til at modtage beskeder af typerne 4, 3, 2 eller 1. Alternativt kunne metoderne være opbygget med prioriteret modtagelse, hvorved den anden del af datastrukturen, int signal, kunne spares. Dette kunne dog bevirke at den ene af processerne, hvis denne foretog et receivesignal kald efter et sendsignal, og før den anden proces, ville modtage sin egen besked. Den førstnævnte implementation blev derfor foretrukket. Dataoverførsel Metodeparret senddata og receivedata har som hovedfunktion at returnere de udregnede værdier der skal bruges til at tegne analyzergrafen på den grafiske brugerflade. Der er tale om en række talværdier, svarende i antal til de implementerede filtre. For at overføre denne række af værdier benyttes et array af typen char. Dette giver mulighed for en opløsning på grafens værdiakse på op til 256 punkter. Det skal bemærkes at værdien af en char kan ligge mellem 128 og 127, hvorfor det vil være nødvendigt at lade metoden findrms i klassen CAnalyzer returnere værdier mellem disse to grænser. Metoden receivedata skal returnere den data der modtages til en kaldende funktion. Hvis man i C++ returnerer et array fra en metode, får man reelt en pointer til adressen på dette array. Da metoden afsluttes ved kaldet af return, frigives den benyttede memory imidlertid, og den returnerede pointer er ikke længere brugbar. For at omgå dette problem oprettes et privat array i klassen, og en pointer til dette returneres. Da de to oprettede CExternal objekter ikke lukkes ned før hele programmet afsluttes, vil denne pointer også være brugbar uden for objektet. Metodeparret senderrortype og receiveerrortype fungerer i hovedtræk ligesom send- Data og receivedata, men har til formål at sende informationerne om fejltypen samt en specifik fejlbesked mellem AnalyzerEqualyzer og GUI. Fejlhåndteringen omtales yderligere i afsnittet Fejlhåndtering 3.1 på side 15. Fælles for alle metoderne er, at de med funktionen msgget opretter en message queue første gang de bliver kaldt. Køen får for Signal nøglen 0xCAFE, for Data nøglen FACE og for Error nøglen FEAC [*Note *]. Findes en kø med samme nøgle i forvejen, får msgget ingen betydning. De oprettede message queues skal nedlægges med funktionen msgctl, med kommandoen IPC_RMID ved programmets afslutning. Denne oprydning skal ligge i hhv. main-funktionen i den grafiske brugerflade, og main-funktionen i analyzer-/equalizerprogrammet. bør skrives til i fejlhånd snittet i stedet

20 20 Softwaredesign Test For at teste de metoder CExternal indeholder, benyttes to små testprogrammer, testramme1 og testramme2. De to programmer opretter hver især et CExternal objekt, i testramme1 med parameteren ANALYZER, og i testramme2 med parameteren GUI, hvorved de to seperate processer i projektet simuleres. I hvert testprogram oprettes herefter to message queues, med hhv. nøglerne 0xCAFE og 0xFACE. I testramme1 kaldes send- Signal, og i testramme2 kaldes receivesignal. Denne sekvens gentages i den modsatte retning, og de modtagne signaler skrives til cout. Samme fremgangsmåde gentages for senddata og receivedata, med et array af characters oprettet til formålet. Til slut nedlægges de oprettede message queues, og de to programmer afsluttes. Testen forløb tilfredsstillende, CExternal anses for afsluttet og tages i brug i de andre klasser. 3.3 CSound Klassen CSound varetager fortolkning af instruktioner fra CPlayWindow og internt i klassen, til brug ved forsendelse af lyddata til CSoundCard. Funktionen består i modtagelse af instruktioner fra CPlayWindow og playnoise, der henholdvis er i GUI og klassen selv. Instruktionerne fra CPlayWindow kalder outputsound med parameteren const char, hvori stien til lydfilen er defineret, som skal håndteres og videresendes. Instruktionen for playnoise består i kaldet med en statisk sti til filen for pink noise Behandling af data til CSoundCard Afspilning af pink noise Ved korrektion af højttalerne skal der afspilles et kendt signal, der dækker hele frekvensområdet for mikrofonen. Til dette formål anvendes pink noise, men white noise kan også anvendes, hvor gengivelsen af pink noise sker ved afspilning af en wave-filer, som skal ligge i samme mappe som filerne for klassen. Af hensyn til kaldet af filen skal det sikres, at filens placering er korrekt. Idet kaldet af playnoise vil fejle, hvis filens placering ikke stemmer overens med stien angivet i koden. /** :INFO: Play a pink noise file through outputsound */ CSound::playNoise(){ } /** :NB: Make sure the file "pink.wav" is placed in * the same directory as the CSound.* files */ CSound noise = CSound(); noise.outputsound("pink.wav");

21 Interface til lydkort Fejlhåndtering Testramme for funktionerne 3.4 Interface til lydkort En instans af klassen CSoundCard ligner ikke et typisk objekt med en række instansvariable og metoder til at manipulere disse - i stedet er objektets primære formål at styre lydkortets optagning og afspilning. For at tilgå lydkortet anvendes en driver. Der er til linux/unix lavet et sæt drivere, der giver et ensartet API 3 kaldet OSS 4. Det er således muligt at tilgå et givent OSSkompatibelt lydkort i en computer kørende linux med de samme kald; programmet der implementerer disse er således portabelt. Ud over OSS findes ALSA 5, der giver mulighed for flere avancerede funktioner, men da disse ikke er nødvendige i dette projekt, og da OSS er den standard der pt. er til linux, anvendes ALSA ikke. Til at understøtte kodningen af CSoundCard anvendes de to internetsider (?) og (?) samt et konkret kodeeksempel af Søren K. Olesen. [*Note *] For at være i stand til at optage og afspille skal man kunne: skal søren nævnes her? Initialisere lydkortet. Skrive til og læse fra lydkortet Initialisering af lydkort Lydkortet sættes op med en række ioctl-kald; ioctl-funktionen manipulerer med et givent device s parametre - se manualsiderne for ioctl[*note *]. I disse sider står ok? int ioctl(int d, int request,...); hvor d er file descriptor 6, og hvor request fortæller hvilke parametre, der skal ændres (de forskellige requests anvendt kan findes på internetsiderne (?) og (?)). Det sidste felt kan bruges til at fortælle, hvordan parametrene skal ændres. Et eksempel på brugen af ioctl er ved opsætning af bitopløsningen: int actual_value = bits; if(ioctl(audio_fd, SNDCTL_DSP_SAMPLESIZE, &actual_value) == -1) clean\ Up(0x0030); if(actual_value!= bits) cleanup(0x0031); 3 Application Programming Interface 4 Open Sound System 5 Advanced Linux Sound Architecture 6 Et systemspecifikt nummer der bruges til at identificere den åbne fil for systemet

22 22 Softwaredesign Her forsøges bitopløsningen (eller sample-størrelsen) sat til actual_value. Hvis det ikke er muligt at sætte en bitopløsning, returnerer ioctl -1. Efter bitopløsningen er sat, kontroleres om det er den rigtige opløsning der er sat (da actual_value videregives som en reference, er ioctl i stand til at ændre dens værdi). Sker der en fejl under initialiseringen, lukkes lydkortet og der kastes en fejlbesked. På lignende vis sættes andre parametre for optagelse og afspilning: Fuld duplex 7 Bitopløsning: 16 bit sample 2 kanaler (optagelse og afspilning) Samplingsfrekvens: 44 1 khz Afspilning og optagelse er det: optagelse, op- vnt før? [*Note *] Efter lydkortet er sat op, er det muligt at begynde at optage og afspille lyd. CSoundCard er lavet således, at det er muligt at hente pointerne til optagebufferen og til afspillebufferen samt længden af bufferne; længden er det halve af størrelsen, da hver sample er to bytes stor. Der anvendes et såkaldt[*note *] dobbeltbuffer-system (to buffere i indgangen og to i udgangen), hvor det er muligt for applikationen at læse/skrive til den buffer, lydkortet ikke er i gang med at bruge. En illustration af dette ses på figur 3.1 Hvis man anmoder CSoundCard-objektet om pointere til input- og output-bufferen, IN B1 B2 in_ptr1 lk_in_ptr in_ptr2 OUT B1 B2 out_ptr1 out_ptr2 Figur 3.1: Dobbeltbuffer-systemet kontrollerer objektet først, hvor lydkortet er i gang med at skrive og læse fra (lk_in_ptr). Derefter returneres pointere til starten af de ubenyttede buffere (in_ptr2 og out_ptr2). Anmodes om pointere til input- og output-bufferen hvor lk_in_ptr stadig er ved B1, venter objektet med at returnere pointerne in_ptr1 og out_ptr1, indtil lydkortet begynder på B2. Da lydkortet læser og skriver fra/til input- og output-bufferen med det samme offset fra begyndelsen af bufferne, og da bufferne har samme længde, er det nok bare 7 Mulighed for at optage og afspille på samme tid.

23 Interface til lydkort 23 at bestemme hvor lydkortet skriver i inputbufferrummet for at returnere en pointer til inputbufferen og outputbufferen. Dataene til lydkortet er formateret som vist på figur 3.2. Et standard konsumer-lydkort 16 bit L R L R L R n = 0 n = 1 Figur 3.2: Således er data til lydkortet formateret anvender little endian-formaterede 16 bit samples. På en x86-maskine kan således anvendes en signed short til at indeholde en enkelt sample. Til tiden n 0 er der i stereo to samples, en til højre og en til venstre kanal (venstre før højre). Da mikrofonen optager i mono, og applikationen i stereo, vil der således kun komme brugbare data i den ene af de to kanaler Test Til test af CSoundCard er lavet en testramme. Hvad der sker i den opridses her: 1. Lydkortet initialiseres 2. Start optagelse og afspilning 3. - og output-pointer hentes 4. bufferen kopirers over i outputbufferen 5. goto gange; (her anvendes en for-løkke) 6. Luk lydkortet Med denne testramme er det altså muligt at fastslå, om CSoundCard virker. Da testprogrammet blev kørt første gang, viste det sig, at der var hørbare klik i lyden. Det viste sig at denne sammenligning var forkert info_in.ptr>input_buffer_length, da info_in.ptr er af typen char og input_buffer_length af typen short (den rigtige sammenligning kan ses [*Note *]). Resultatet af det var, at dobbeltbuffer-systemets første buffer (B1 figur 3.1) havde 1 4 af bufferrummet og den anden (B2 figur 3.1) 3 4. Efter fejlen er rettet, er det muligt at høre, hvad der kommer ind i mikrofonen gennem højttalerne med en bufferlængdes forsinkelse. hvor??

24 24 Softwaredesign 3.5 CAnalyzer Klassen CAnalyzer varetager fortolkning af data fra CFilter, til videre brug i eksempelvis CGraphWindow. Funktionen består i at omforme de data, der modtages til en samlet mængde data indeholdende informationer om RMS-værdierne på på de i afsnit?? beskrevne 1 N oktavs bånd. Dette udføres ved at modtage data fra et forudbestemt antal båndpasfiltre og dernæst beregne RMS-værdien for hver af disse. Dernæst samles og sendes til CGrphWindow. Metoderne til håndtering af ovenstående er beskrevet i afsnit 2 og består af findrms(filteredseq[]) og returnrms() Båndpasfiltrenes RMS-værdier Til beregning af RMS-værdien for et bånd skal den lydsekvens, som modtages i et array af typen signed short, gennemgå en procedure. Denne procedure består i at udføre følgende beregning, der er omtalt i afsnit??: RMS 1 T T y n 2 n 0 (3.1). For at udføre denne beregning er det nødvendigt at inkludere <math.h> der bla. omfatter funktionerne sqrt() og pow(x,y), der henholdsvis uddrager kvadratroden og opløfter x i potens af y. Værdierne tilhørende de enkelte elementer i omtalte array repræsenteres ved y n og omtales i koden som filteredseq[i], et lokalt array, hvor int i går fra 0 til og med T, der i koden benævnes number og udgør antallet af array-elementer.number beregnes ud fra bufferlængden bufferlength, som angiver antallet af samples. Hver beregnet RMS-værdi lagres som et element i et lokalt array rmscoeff[rmsnr]af klassen, hvor rmsnr angiver i hvilket element der skal lagres. rmsnr er en lokal variabel af klassen CAnalycer, og initialiseres til 0, når der oprettes et nyt objekt af klassen. Desuden tæller rmsnr een op hver gang metoden findrms(filteredseq[]) kaldes. rmsnr re-initialiseres når antallet af forudbestemte bånd(nrofband) er nået, hvorved de næste RMS-værdier påny placeres fra første element i rmscoeff[rmsnr]. Dette ser på kode form således ud: for (int i=0; i<number; i++) { sum = sum + pow(filteredseq[i], 2); } rms = sqrt(sum) / number;

25 CAnalyzer Returnering af RMS-værdier Når de udregnede RMS-værdier, ønskes returneret, foregår det ved at kalde metoden returnrms(), der blot sender en pointer til startadressen på det lokale array rmscoeff[rmsnr], hvor RMS-værdierne ligger. Dette foregår gennem klassen CExternal, indebærer følgende kode, hvor external er et tidligere oprettet CEXternal(GUI)-objekt: CAnalyzer::returnRMS(){ external.senddata(rmscoeff); } Figuren 3.3 illustrerer, hvorledes RMS-værdierne for de enkelte båndpasfiltre placeres i output-array et rmscoeff og det kald, der foretages inden værdierne er beregnet. Båndpasfiltre CAnalyzer rmscoeff[] F 1 CAnalyzer::findRMS() i = 0 F 2 CAnalyzer::findRMS() F 3 CAnalyzer::findRMS() F N CAnalyzer::findRMS() i = (nr_og_bands 1) N = nr_og_bands Figur 3.3: Illustration af placering af RMS-værdier i rmscoeff(). Metodekald af findrms(filteredseq[]), foregår sekventielt fra main[*note *]svarende til antallet af bånd, for til sidst at kalde returnrms() for at få RMS-værdierne sendt videre. navn eks ændres Fejlhåndtering I denne klasse inddrages, under fejlhåndtering, en undersøgelse af bufferlength, der ikke må være nul eller derunder. Dette kriterie er opstillet da denne indgår som nævner i en division, og da en negativ bufferstørrelse ikke giver mening.

26 26 Softwaredesign slet ikke stå der!!!!!! Der kan udover ovennævnte fejl, opstå uhensigtsmæssigheder, iform af for tidlig kald af returnrms(), dette resulterer i at de sendte RMS-værdier kan bestå af en blanding af gamle og nye, tilhørende de respektive bånd. Dette vil ikke være synlig for brugeren, og undgåes ved kalde returnrms() efter sidste bånd.[*note *] Testramme for funktionaliterne Klassen testes ved at kode en testramme, der opretter et test-objekt af klassen CAnalyzer og kalder klassens Constructer med antallet af bånd som parameter. Herefter genereres et givet antal array s indeholdende både positive og negative værdier. Hvert array benyttes derefter som parameter ved kald af metoden test.findrms(short x-array[]). Dernæst oprettes et CExternal-objekt, hvorefter test.returnrms() kaldes, der sender RMS-værdierne til CExternal. Til sidst kaldes CExternal-objekt.receiveData(), der modtager en pointer til RMS-værdierne, hvorefter værdierne skrives ud gennem en for-løkke. Denne test forløb uden konplikationer og minimal debugging. Der kan i appendiks XX[*Note *] findes en samlet integrationstest hvor CAnalyzer er inkluderet. 3.6 Den grafiske brugerflade Softwaren i projektet udvikles efter objektorienterede principper, og skrives i C++. For at implementere en grafisk brugerflade 8 til analyzer- og equalizerprogrammet var det derfor nødvendigt at vælge et grafikbibliotek til brug med C++. Valget faldt på Qt, et professionelt softwareudviklingsværktøj, som er gratis tilgængeligt for Unix/Linux systemer under GPL 9. Qt tilbyder et omfattende bibliotek af funktioner og objekter (kaldet widgets) til brug ved konstruktion af en GUI, og nyder derudover popularitet fordi en applikation udviklet i Qt kan benyttes på kryds af de tre store platforme, Unix/Linux, Windows og MacOS. Et godt eksempel på brugen af Qt kan findes i Linux desktoppen KDE. Det følgende afsnit gennemgår nogle koncepter og metoder i forbindelse med Qt, præsenterer et udkast til projektets GUI, og går derefter i dybden med implementationen af de enkelte elementer i denne Qt - et kort overblik [*Note *] Qt er som nævnt et grafikbibliotek til C++. Brugen af de funktioner og klasser der findes i Qt tillader at projektets GUI kan udvikles uden det bliver nødvendigt at sætte sig ind i de indre virkemåder af X11, Unix og Linux graphics-engine. To ting er centrale for Qt: Widgets, og Qt s signal/slot fremgangsmåde, til at kommunikere mellem forskellige elementer af en applikation. Widgets En widget er i Qt (og i andre sammenhænge) et element af en GUI, som giver brugeren information, eller en mulighed for at kommunikere med systemet. Definitionen kan 8 GUI: graphical user interface 9 Gnu Public License; se for yderligere licensinformation.

27 Den grafiske brugerflade 27 udvides til at omfatte elementer af GUI en som har den funktion at indeholde andre widgets, og dermed tjener et layoutmæssigt formål. Som eksempler på widgets kan f.eks. nævnes en simpel trykknap, eller et vindue. Trykknappen tillader brugeren at kommunikere med systemet; når et tryk på knappen registreres kan forskellige forløb i systemet startes eller stoppes. Vinduet er en såkaldt container-widget, som kun giver information eller mulighed for interaktion gennem de widgets den indeholder. Vinduet giver en ramme om en applikations GUI, og tillader evt. at applikationen minimeres, eller at størrelsen ændres. I en Qt-applikation består alt synligt således af widgets. Selve vinduet, trykknapper, scrollbars og tekstvinduer er alle widgets, og kan i vid udstrækning findes som standardelementer i Qt. De enkelte widgets er defineret som C++ klasser, og indgår i et nedarvningshierarki, der for de flestes vedkommende starter med klassen QWidget. Fra QWidget nedarves en lang række af de mest almindeligt brugte egenskaber og metoder til at tegne et objekt på skærmen, og de enkelte underklasser specialiceres derefter ned gennem hierarkiet. Signals and slots For at give f.eks. en trykknap mening, skal den forbindes til noget. Hvis der intet sker når der trykkes på knappen kan den lige så godt udelades. For at opnå forbindelse mellem de enkelte widgets der udgør en GUI, benytter Qt signals og slots. En widget kan indeholde et arbitrært antal signals og slots. Et signal kan udsendes (emittes) enten på baggrund af en event, som er en handling fra systemets bruger, eller et eksternt system, eller det kan udsendes som følge af en intern ændring i den pågældende widget. Udefrakommende events håndteres internt af Qt, og det er som bruger af Qt kun nødvendigt at specificere hvilke events en widget skal reagere på, og implementere koden for de ønskede reaktioner. Når en widget har modtaget en event, og har udsendt et signal, er dens rolle i forløbet reelt udspillet. En widget sikrer sig ikke at signalet modtages af nogen, og det kan derfor lade sig gøre at implementere dele af et system, uden at der opstår fejl pga. manglende modtagere. Når modtageren til et signal tilføjes til systemet, forbindes det udsendte signal til et slot i modtagerwidget. I modtagerwidget er det pågældende slot implementeret som et stykke kode, der køres hver gang det specificerede signal modtages Projektets grafiske brugerflade Designprocessen tager udgangspunkt i en række usescases, som også danner grundlag for et udkast til GUI en: 1. Brugeren trykker på en knap og det måltes frekvensgang reguleres efter den ønskede frekvensgang. 2. Brugeren skaber den frekvenskarakteristik han ønsker højttaleren (og rummet) skal have i målepunktet. 3. Brugeren trykker på en knap og får vist højttalerens (og rummets) frekvenskarakteristik (ved mic. placering).

28 Softwaredesign 4. Brugeren trykker på en knap og får grafisk præsenteret det måltes frekvensindhold i realtid. 5. Brugeren skal kunne afspille lyd, således at det behandles gennem equalizeren. Usecase 1 kræver en knap til regulering af systemets frekvensgang. Ligeledes kræves fra usecases 3 og 4 knapper til start af hhv. måling af systemets frekvensgang, og visning af frekvensindhold i realtid. For at kunne stoppe de enkelte processer igen kræves derudover en stopknap. Disse knapper tildeles et område på den grafiske brugerflade. Ud over de fire nævnte trykknapper kommer to fra usecase 2, som bruges til hhv. at gemme den indstillede frekvenskarakteristik, og til at gendanne default-værdierne for denne. Fra usecase 5 kommer en play og en stop knap til brug ved afspilning af lyd gennem equalizeren. Alle disse trykknapper samles i en klasse, CButton, og er beskrevet i afsnit Usecase 2 lægger op til at brugeren skal kunne indstille en række værdier gennem GUI. Denne funktionalitet er oplagt at implementere med en række sliders, som tildeles et område på GUI, sammen med de to knapper til at gemme, og nulstille. Implementation af sliders og knapper samles til en enhed i klassen CSliderWindow, med underklassen CSlider, og dokumenteres i afsnit Fra usecase 3 og 4 kan udledes et krav om en grafisk præsentation af data fra analyzeren. Denne repræsentation håndteres i klassen CGraphWindow, som beskrevet i afsnit Usecase 5 lægger ud over knapperne til play og stop op til at brugeren skal kunne vælge en fil fra en liste på displayet. Implementationen af denne funktion er lagt i klassen CPlayWindow, og dokumenteret i afsnit Ud fra de fundne elementer er udkastet i figur 3.4 udarbejdet... // """ ## *** ++,, -- $$$ %%% &&& '''!!! (( )) Lydfil1.wav Lydfil2.wav Lydfil3.wav Lydfilx.wav Figur 3.4: Udkast til GUI, udarbejdet fra usecases.

29 Den grafiske brugerflade CButton Klassen CButton s funtkion er formidling af information mellem brugeren og softwaren, idet brugeren via knapperne indgiver forskellige funktionskald, som på forhånd er defineret i de forskellige knapper på brugergrænsefladen. Med henblik på en brugervenlig GUI, hvor brugeren har adgang til de fornødne funktioner. Derved er der via analyseog designfasen fremkommet forskellige knapfunktionaliteter. Disse funktionaliteter for CButton kan ses i tabel 3.1. GUI skal danne rammen for de forskellige trykknapper, der hver varetager specifikke opgave. Dette leder hen til den næste fælles funktion, der skal aktiveres efter et vilkårligt knaptryk, som er midlertidig deaktivering af alle knapper med undtagelse af quit, da programmet til en hver tid skal kunne lukkes. Funktionens varighed er variabel, da denne afhænger af den opstartede proces s varighed. Til varetagelse af opgaven er konstrueret en Radiobutton, som illustativt skal give brugeren information om statusen for det funktionskald, der er aktiveret. Dette sker ved en ON/OFF stilling, hvor ON informerer om en igangværende proces, mens OFF for en afsluttet proces og dermed venter på ny aktivering. Foruden den illustative ændring af Radiobutton, sker der samtidig en Lowlight af de enkelte knapper, der ikke kan tilgåes. Processen med lowlight er en funktion, der kommer med brugeren af QT. Til varetagelse af denne funktion er der konstrueret et slot setstatus, som sender et signal til en Radiobutton med kommandoen RadioButton1->setChecked( FALSE ). Med denne kommando sættes knappens status til OFF uafhængigt af tidligere status. Slottet setstatus aktiveres via signaler fra eksempelvis CgraphWindow, der sender signal efter udføret funktionskald. Derved kan aktivering af knapperne før den igangværdende proces er fuldført ikke forekomme. Figuren 3.5 viser, hvorledes nogle af knapperne og radiobutton er grafisk illustreret, mens figuren 3.6 viser signalvejen ved knaptryk inden for CButton og til dens periferi. Tabel 3.1 viser en oversigt over sammenhængen mellem knappernes funktioner, knaptekster, slot og signaler, hvor funktionerne beskriver, det brugeren forespørger af programmet via brugergrænsefladen. Dernæst beskriver kolonnen med knaptekst kort, hvilke valg muligheder brugeren har tilrådighed, og hvilken funktion der kaldes ved et knaptryk. Den næste kolonne er en mere programmeringsmæssigt indsigt i, hvilke slot der er forbundet til de enkelte knapper, og hvori koden til skrevet, som klades ved aktivering af den eller de enkelte knapper. Den sidste kolonne giver en oversigt over, hvilke signaler der sendes videre til andre dele af systemet, som kald af andre funktioner. Beskivelsen af knapperne og deres tilhørende funktioner er i relattion til den opgave, der skal udføres. Imodsætning er signalerne, der sendes, valgt ud fra ide om bedre overskuelighed og en gruppering af de enkelte knapper i henhold til deres pladsering på GUI. Det eneste signal, der påforhånd kan fastsættes til en værdi, er Quit, idet definitionen af int(1) er fastsat til at stoppe og lukke alle processer og underprogrammer. Beskivelsen af knapperne og deres tilhørende funktioner er i relattion til den opgave, der skal udføres. Imodsætning er signalerne, der sendes, valgt ud fra ide om bedre overskuelighed og en gruppering af de enkelte knapper i henhold til deres pladsering på GUI og overordent funktionalitet. De to eneste knapper, der påforhånd kan fastsættes til en værdi, er Quit og Stop All, idet definitionen af int(1) er fastsat til at stoppe og lukke alle processer og underprogrammer, mens int(9) er defineret til at stoppe samtlige