<para>aRts är inte enbart ett program, den tillhandahåller också ett antal olika programmeringsgränssnitt (API) för olika syften. I det här avsnittet, försöker jag beskriva "helhetsbilden", en snabb överblick av vad de här gränssnitten är tänkta att användas till, och hur de hänger samman. </para>
<para>Det finns en viktig distinktion som måste göras: De flesta gränssnitten är <emphasis> språk- och platsoberoende</emphasis> eftersom de är specificerade som <emphasis>mcopidl</emphasis>. Det här betyder att man egentligen kan använda den service som de tillhandahåller från vilket språk som helst, implementera dem i vilket språk som helst, och man behöver inte bry sig om ifall man pratar med lokala eller fjärrobjekt. Här är först en lista på dem: </para>
<listitem><para>Grundläggande definitioner som bildar grunden i MCOP-funktionen, som själva protokollet, definitioner av objekt, handlaren, flödessystemet och så vidare. </para></listitem>
<listitem><para>De här innehåller flödessystemet som man använder för att ansluta ljudflöden, definitionen av <emphasis>Arts::SynthModule</emphasis> som är grunden för alla gränssnitt som har strömmar, och till slut några användbara ljudobjekt </para></listitem>
<listitem><para>Här definieras <emphasis>Arts::PlayObject</emphasis>, ett objekt som kan spela upp en mediatyp. Mediaspelare som KDE:s mediaspelare noatun kommer att kunna spela upp vilka media som helst som har PlayObject. Därför är det vettigt att implementera PlayObject för olika format (som mp3, mpg video, midi, wav, ...) med det här som grund, och det finns redan många. </para></listitem>
<listitem><para>Här definieras ett gränssnitt för systemets ljudserver artsd. Gränssnittet benämns <emphasis>Arts::SoundServer</emphasis>, och implementerar funktioner som att ta emot strömmar från nätverket, spela samplingar, skapa andra egna aRts-objekt och så vidare. Nätverkstransparens är underförstådd eftersom MCOP används (som för allt övrigt här). </para></listitem>
<listitem><para>Den här modulen definierar grundläggande flödesfunktioner, dvs. kombinera enklare objekt till mer komplexa genom att definiera en graf som binder samman dem. Den definierar det grundläggande gränssnitten <emphasis>Arts::StructureDesc</emphasis>, <emphasis>Arts::ModuleDesc</emphasis> och <emphasis>Arts::PortDesc</emphasis> som innehåller en beskrivning av en struktur, modul och port. Det finns också ett sätt att skapa ett "levande nätverk av objekt" från de här förbindelserna och värdebeskrivningarna med användning av en fabrik. </para></listitem>
<listitem><para>Den här modulen definierar grundläggande midi-funktioner, som objekt som skapar midi-händelser, vad en midi-händelse är, och <emphasis>Arts::MidiManager</emphasis> för att förbinda producenter och konsumenter av midi-händelser, och så vidare. Som alltid är nätverkstransparens underförstådd. </para></listitem>
<listitem><para>Här finns diverse ytterligare filter, oscillatorer, ljudeffekter, fördröjningar och så vidare, allt som behövs för riktigt användbar signalbehandling, och för att bygga komplexa instrument och effekter från de här grundläggande byggblocken. </para></listitem>
<listitem><para>Det här tar hand om synliga objekt. Det definierar den grundläggande typen <emphasis> Arts::Widget</emphasis> som alla moduler med ett grafiskt gränssnitt utgår från. Det här åstadkommer oberoende av verktygslåda, och ... visuell redigering av det grafiska gränssnittet, och möjlighet att serialisera grafiska gränssnitt. Dessutom, eftersom de grafiska komponenterna har normala egenskaper, kan deras värden på ett rättframt sätt anslutas till vissa signalbehandlingsmoduler. (dvs. värdet av ett skjutreglage till klippning för ett filter). Som alltid, nätverkstransparent. </para></listitem>
<para>Där det är möjligt implementeras aRts själv med IDL. Å andra sidan finns det några <emphasis>språkspecifika</emphasis> programmeringsgränssnitt, som antingen använder enkel C++ eller C. Det är ofta förnuftigt att använda IDL-gränssnitt om möjligt, och de övriga gränssnitten när det är nödvändigt. Här är en lista på språkspecifika programmeringsgränssnitt: </para>
<listitem><para>De här är KDE:s programmeringsgränssnitt för bekvämlighet med de enkla och väldigt vanliga fall, när man bara vill spela upp en sampling. Gränssnitten är enkel C++, Qt/KDE-optimerade, och så enkla som de kan vara. </para></listitem>
<listitem><para>Här sker all magi som har med MCOP att göra. Biblioteket innehåller de grundläggande saker som behövs för att skriva ett enkelt MCOP-program, avsändaren, tidtagning, I/O-hantering, men också de interna funktioner som behövs för att själva MCOP-protokollet ska fungera. </para></listitem>
<para>C-gränssnittet för &arts; skapades för att göra det lätt att skriva och anpassa enkla C-program till &arts; ljudserver. Det tillhandahåller flödesfunktioner (att skicka samplingsströmmar till <application>artsd</application>), antingen med eller utan blockering. För de flesta program tar man helt enkelt bort de få systemanrop som hanterar ljudenheten och byter ut dem mot lämpliga anrop till &arts;.</para>
<para>Jag gjorde två anpassningar för att verifiera idén: <application>mpg123</application> och <application>quake</application>. Du kan skaffa programfixarna <ulink url="http://space.twc.de/~stefan/kde/download/artsc-patches.tar.gz">härifrån</ulink>. Bidra gärna med dina egna programfixar till underhållaren av &arts; eller till programvarupaket för multimedia så att de kan integrera stöd för &arts; i sin kod.</para>
<title>Att kompilera och länka: <application>artsc-config</application></title>
<para>För att lätt kunna kompilera och länka program med &arts; C-gränssnitt, finns verktyget <application>artsc-config</application> som känner till vilka bibliotek som man måste länka med och var deklarationsfilerna finns. Det anropas med</para>
