# 4.4. Plus de détails internes

Le code d'Arts est déjà du code distribué. Cela signifie que vous avez

1. Une interface graphique utilisée pour relier les modules entre eux.

2. Le synthétiseur (qui fonctionne sur un autre processus), qui s'occupe de la synthèse. Il est capable de construire une structure quelconque de modules interconnectés, et de l'exécuter.

Les processus 1 et 2 communiquent en permanence. En fait, le processus 1 ne peut exister sans le processus 2, tandis que le processus 2 peut exister sans le processus 1.

Il y a même un programme sans interface graphique, artsshell, qui peut entre autre donner l'ordre au synthétiseur de se mettre au travail (donc si vous n'avez pas KDE, vous pouvez quand même utiliser les modèles de synthèse, mais c'est bien sûr moins pratique quand on ne peut pas les éditer).

Voici ce que vous avez avec aRts :

Maintenant, ce que fait fondamentalement midisend, c'est ajouter un nouveau processus (processus 3), qui envoie les données midi au synthétiseur (en utilisant CORBA aussi) :

Ainsi, voilà ce que je voudrais logiquement avoir :

Physiquement (suivant la façon dont vous l'implantez), ça devrait ressembler à ça :

Notez que tous les rectangles sont ici des processus distincts, et vous pouvez brancher de nouveaux processus comme vous le voulez (par exemple un clavier virtuel sur l'écran, qui vous permet d'envoyer des données midi en cliquant dessus).

Voici les trucs liés à idl qui peuvent vous intéresser :

arts.idl : (qui n'est pas si intéressant dans le contexte de cette discussion). midibus.idl :

       1 interface MidiChannel {
       2     oneway void noteOn(in octet channel, in octet note, in octet volume);
       3     oneway void noteOff(in octet channel, in octet note);
       4 };
       5
       6 // This of course doesn't look finished ;) where are parameter, such as
       7 // echo depth, where is midi mapping, where is instrument changing, where
       8 // is...
       9 //
      10 // I hope to complete that later.