<para>aRts er ikke kun et program, den sørger for også et antal forskellige programmeringsgrænseflader (API) til forskellige formål. I dette afsnit, forsøger jeg at beskrive "helhedsbilledet", et hurtigt overblik over hvad disse grænseflader er tænkte at bruges til, og hvordan de hænger sammen. </para>
<para>Der er en vigtig distinktion som skal gøres: De fleste grænseflader er <emphasis> sprog- og pladsuafhængige</emphasis> eftersom de er specificerede som <emphasis>mcopidl</emphasis>. Dette betyder at man egentlig kan bruge den tjeneste de sørger for fra et hvilket som helst sprog, implementere dem i et hvilket som helst sprog, og man behøver ikke tage sig af om man taler med lokal- eller fjernobjekter. Her er først en liste af dem: </para>
<listitem><para>Grundlæggende definitioner som danner kernen i MCOP-funktionen, såsom selve protokollen, definitioner af objekter, handleren, flowsystemet og så videre. </para></listitem>
<listitem><para>Disse indeholder flowsystemet som man bruger til at forbinde lydstrømmene, definitionen af <emphasis>Arts::SynthModule</emphasis> som er grundlaget for alle grænseflade som har strømme, og til slut nogle nyttige lydobjekter. </para></listitem>
<listitem><para>Her defineres <emphasis>Arts::PlayObject</emphasis>, et objekt som kan spille en mediatype. Mediaspillere såsom KDE's mediespiller noatun vil kunne afspille hvilket som helst medie som har et PlayObject. Derfor giver det mening at implementere PlayObject for forskellige formater (såsom mp3, mpg video, midi, wav, ...) med dette som grundlag, og der findes allerede mange. </para></listitem>
<listitem><para>Her defineres en grænseflade for systemets lydserver artsd. Grænsefladen benævnes <emphasis>Arts::SoundServer</emphasis>, og implementerer funktioner såsom at tage imod strømme fra netværket, spille samplinger, oprette andre egne aRts-objekter og så videre. Netværkstransparens er underforstået eftersom MCOP bruges (som for alt øvrigt her). </para></listitem>
<listitem><para>Dette modul definerer grundlæggende flowfunktioner, dvs. kombinerer enklere objekter til mere komplekse ved at definere en graf som binder dem sammen. Den definerer den grundlæggende grænseflade <emphasis>Arts::StructureDesc</emphasis>, <emphasis>Arts::ModuleDesc</emphasis> og <emphasis>Arts::PortDesc</emphasis> som indeholder en beskrivelse af en struktur, modul og port. Der er også en måde at oprette et "levende netværk af objekter" fra disse forbindelser og værdibeskrivelserne ved brug af en fabrik. </para></listitem>
<listitem><para>Dette modulet definerer grundlæggende midi-funktioner, såsom objekter som laver midi-begivenheder, hvad en midi-begivenhed er, og <emphasis>Arts::MidiManager</emphasis> til at forbinde producenter og konsumenter af midi-begivenheder, og så videre. Som altid er netværkstransparens underforstået. </para></listitem>
<listitem><para>Her er der diverse yderligere filtre, oscillatorer, lydeffekter, forsinkelser og så videre, alt som behøves for rigtig nyttig signalbehandling, og for at opbygge komplekse instrumenter og effekter fra disse grundlæggende byggeblokke. </para></listitem>
<listitem><para>Denne tager sig af synlige objekter. Den definerer den grundlæggende type <emphasis> Arts::Widget</emphasis> som alle moduler med en grafisk grænseflade udgår fra. Dette giver uafhængighed af værktøjskasse, og ... visuel redigering af den grafiske grænseflade, og mulighed for at serialisere den grafiske grænseflade. Desuden, eftersom de grafiske komponenter har normale egenskaber, kan deres værdier på en ligetil måde forbindes til visse signalbehandlingsmoduler. (dvs. værdien af en skyder til klipning for et filter). Som altid, netværkstransparent. </para></listitem>
<para>Hvor det er muligt implementeres aRts selv med IDL. På den anden side er der nogle <emphasis>sprogspecifikke</emphasis> programmeringsgrænseflader, som enten bruger enkel C++ eller C. Det er ofte fornuftigt at bruge IDL-grænseflade hvis muligt, og de øvrige grænseflader når det er nødvendigt. Her er en liste over sprogspecifikke programmeringsgrænseflade: </para>
<listitem><para>Disse er KDE's programmeringsgrænseflader for bekvemmelighed med de enkle og vældigt almindelige tilfælde, hvor man kun vil afspille en sampling. Grænsefladen er enkel C++, Qt/KDE-optimerede, og så enkle som de kan være. </para></listitem>
<listitem><para>Her sker al magi som har med MCOP at gøre. Biblioteket indeholder de grundlæggende ting som behøves for at skrive et enkelt MCOP-program, afsenderen, tidtagning, I/O-håndtering, men også de interne funktioner som behøves for at selve MCOP-protokollen skal fungere. </para></listitem>
<para>C-grænsefladen for &arts; oprettedes for at gøre det let at skrive og overføre enkle C-programmer til &arts; lydserver. Den sørger for strømningsfunktioner (at sende samplingsstrømme til <application>artsd</application>), enten med eller uden blokering. For de fleste programmer tager man helt enkelt de få systemkald væk som håndterer lydenheden og skifter dem ud mod passende kald til &arts;.</para>
<para>Jeg lavede to overførsler for at verificere idéen: <application>mpg123</application> og <application>quake</application>. Du kan skaffe programrettelserne <ulink url="http://space.twc.de/~stefan/kde/download/artsc-patches.tar.gz">herfra</ulink>. Bidrag gerne med dine egne programrettelser til vedligeholderen af &arts; eller til programmelpakken for multimedia så de kan integrere understøttelsen for &arts; i deres kode.</para>
<title>Kompilere og linke: <application>artsc-config</application></title>
<para>For let at kunne kompilere og linke programmer med &arts; C-grænseflade, findes værktøjet <application>artsc-config</application> som kender til hvilke biblioteker som man skal linke med og hvor deklarationsfilerne findes. Det kaldes med</para>
