<para>aRts no es sólo un conjunto de software, también proporciona una serie de APIs para propósitos variados. En esta sección trataré de describir de una forma resumida lo que se supone que hacen esas APIs, y cómo interaccionan. </para>
<para>Hay que hacer una importante distinción: la mayoría de las APIs son <emphasis>independientes del lenguaje y la localización</emphasis> ya que están especificadas como <emphasis>mcopidl</emphasis>. Es decir, se pueden utilizar los servicios que ofrecen desde cualquier lenguaje, implementarlas en cualquier lenguaje, y no será necesario tener en cuenta si se trata de objetos locales o remotos. Esta es una lista de las primeras: </para>
<listitem><para>Definiciones básicas que forman el núcleo de la funcionalidad MCOP, como el propio protocolo, definiciones del objeto, el intercambiador, el sistema de flujo, etc. </para></listitem>
<listitem><para>Aquí está contenido el sistema de transmisión que se utilizará para conectar transmisiones de audio, la definición de <emphasis>Arts::SynthModule</emphasis> que es la base de cualquier interfaz que tenga transmisiones y finalmente algunos objetos de audio útiles. </para></listitem>
<listitem><para>Aquí se define un objeto que puede reproducir un medio, <emphasis>Arts::PlayObject</emphasis>. Los reproductores de medios como noatun de KDE serán capaces de reproducir cualquier medio para el que se encuentre un objeto PlayObject. Así que cobra sentido implementar objetos PlayObject para varios formatos (como mp3, video mpeg, midi, wav, ...) en esa base, y, de hecho, ya hay muchos. </para></listitem>
<listitem><para>Aquí se define un interfaz para el servidor de sonido global del sistema. El interfaz se llama <emphasis>Arts::SoundServer</emphasis>, que implementa funcionalidades como aceptar transmisiones desde la red, reproducir muestras, crear objetos de aRts propios, etc. La transparencia de red está implícita debido al uso de MCOP (como para todo lo demás). </para></listitem>
<listitem><para>Este módulo define la funcionalidad básica de los gráficos de flujo, es decir, la combinación de objetos sencillos en otro más complejos, definiendo una gráfica de ellos. Define los interfaces básicos <emphasis>Arts::StructureDesc</emphasis>, <emphasis>Arts::ModuleDesc</emphasis> y <emphasis>Arts::PortDesc</emphasis> que contienen una descripción de una estructura, un módulo y un puerto. También hay un modo de obtener una «red viviente de objetos» de estas conexiones y descripciones de valor, utilizando una fábrica. </para></listitem>
<listitem><para>Este módulo define la funcionalidad MIDI básica, como objetos que producen eventos MIDI, lo que es un evento MIDI, un <emphasis>Arts::MidiManager</emphasis> para conectar los productores y consumidores de eventos MIDI, etc. Como siempre, la transparencia de red está implicada. </para></listitem>
<listitem><para>Aquí hay varios filtros adicionales, osciladores, efectos, retardos, etc. así como todo lo requerido para poder realizar procesamiento de señal y construir instrumentos complejos a partir de estos elementos básicos. </para></listitem>
<listitem><para>Se encarga de los objetos visuales. Define el tipo básico <emphasis> Arts::Widget</emphasis> del que se derivan todos los módulos del entorno gráfico. Ésto proporciona independencia del conjunto de herramientas, edición visual del entorno gráfico y entornos gráficos serializables. Además, al tener los elementos del entorno gráfico atributos normales, sus valores puede estar conectados directamente a algunos módulos de procesamiento de señal. (Por ejemplo, el valor de un control al corte de un filtro). Como siempre: transparencia de red. </para></listitem>
<para>Donde es posible, el propio aRts está implementado usando IDL. Por otro lado, hay algunas APIs <emphasis>específicas del lenguaje</emphasis> que utilizan C o C++. Lo más correcto es utilizar interfaces IDL donde se pueda, y las otras APIs donde sea necesario. Esta es una lista de APIs específicas del lenguaje: </para>
<listitem><para>Estas son APIs convenientes para los casos más sencillos y comunes, donde sólo se quiere reproducir una muestra. Las APIs están en C++, optimizado para Qt/KDE, y son lo más sencillas posible. </para></listitem>
<listitem><para>Toda la magia de MCOP se produce aquí. La biblioteca contiene los elementos básicos necesarios que debe conocer para escribir una aplicación MCOP sencilla, el repartidor, temporizadores, administración de entrada/salida, pero también los elementos internos que hacen que funcione el propio protocolo MCOP. </para></listitem>
<para>El <acronym>API</acronym> de C de &arts; se diseñó para facilitar la escritura y adaptación de aplicaciones en C al servidor de sonido &arts;. Proporciona funcionalidad de flujos (envío de suceciones de muestras a <application>artsd</application>), ya sea exclusivas o no. En la mayoría de las aplicaciones, basta con eliminar unas pocas llamadas al sistema que realizan la comunicación con el dispositivo de audio y sustituirlas por las llamadas a &arts; correspondientes.</para>
<para>Yo he realizado dos adaptaciones como demostración del concepto: <application>mpg123</application> y <application>quake</application>. Los parches se puede obtener <ulink url="http://space.twc.de/~stefan/kde/download/artsc-patches.tar.gz">aquí</ulink>. Usted mismo puede enviar sus propios parches al mantenedor de &arts; o de otros paquetes de software para facilitar el uso de &arts; en su código.</para>
<title>Compilación y enlace: <application>artsc-config</application></title>
<para>Para compilar y enlazar de un forma sencilla los programas que utilicen la <acronym>API</acronym> para C de &arts;, se proporciona la utilidad <application>artsc-config</application> que sabe qué bibliotecas son necesarias para el enlace y dónde se encuentran los archivos de inclusión. Se ejecuta utilizando</para>