[ Ne demandez pas ce que aRts peut faire pour vous, mais ce que vous pouvez faire pour aRts ;) ]
Peut-être voulez-vous participer à l'amélioration de aRts, mais vous ne savez pas quels sont les besoins. Peut-être que vous n'êtes pas à l'aise avec la programmation C++ ou Qt.
Tout d'abord, inscrivez-vous à la liste de diffusion, jetez un coup d'oeil à http://linux.twc.de/arts pour plus de détails. La liste des tâches de cette documentation ne sera certainement pas toujours à jour.
J'ai créé une liste de tâches qui me semblent importantes pour un développement rapide du projet. Si vous voulez, choisissez une tâche qui vous intéresse et contactez-moi...
Ce serait bien d'avoir une documentation/des tutoriels (éventuellement illustrés) qui décriraient réellement les différents types de synthèse, les effets, les instruments.
Juste pour en citer quelques uns, je pense que beaucoup de personnes qui veulent apprendre à utiliser aRts ont besoin d'introductions sur
Qu'est-ce que la modulation de fréquence ?
Qu'est-ce que la modulation en anneau ?
Comment fonctionnent les oscillateurs ?
Que font ces filtres ?
Comment créer un vocoder ?
Comment créer un son analogique qui sonne bien ?
Comment fonctionnent les vieux synthétiseurs tels que les 303, 909, mini moog, ... ?
Comment faire tout ça avec aRts ?
Ce serait bien si tout ça était au format sgml ou html ou n'importe quel format lisible par tout le monde.
Même choses que pour la documentation. Les gens doivent voir que ce programme est vraiment puissant !
Si vous avez créé quelque chose de bien, contactez-moi simplement ;) On devrait voir grossir une collection de mp3 sur le site web de aRts, afin que tout le monde puisse juger à l'écoute ce que ça donne quand on utilise aRts.
Comme aRts grossit lentement, il va atteindre son but : virtuellement, chaque synthétiseur, appareil de studio et effet peut être construit à partir de petits modules.
Mais cela signifie aussi que quelqu'un maintienne un jeu de structures standards qui seront livrées avec la distribution de aRts, comme des mixeurs, des égaliseurs, des synthétiseurs, des effets, des panneaux de contrôle, des applet incrustable dans le tableau de bord etc. Tout comme la partie aujourd'hui la plus importante de emacs n'est certainement pas le code de base, mais toutes les choses emacs-lisp livrées avec emacs (de la coloration syntaxique à la "dunnet dungeon" (jeux d'aventure en mode texte sous emacs) et autres jeux), une grande partie de la facilité d'utilisation pour l'utilisateur final dépendra du grand ensemble de structures qui seront livrées avec aRts.
C'est un gros travail, mais certainement intéressant et en tout cas un vrai challenge.
Nous avons environ trente modules maintenant. Nous en aurons besoin de 50 au moins, pour que ça vaille vraiment le coup. Ils doivent être catégorisés et triés, décrits et écrits.
Ce qui est tout particulièrement important est qu'ils doivent suivre le même concept. Par exemple, ça n'aurait pas de sens si on devait spécifier les fréquences de certains modules par 1/f, alors que d'autres attendraient qu'elles soient données par f.
Ça ferait avancer les choses si vous écriviez vos propres modules (vous n'avez besoin que d'un peu de C++), mais ce n'est certainement pas nécessaire.
Un bon point de départ serait de créer une hiérarchie de noms, où tous les modules seraient répertoriés, comme par exemple Synth_BUS_UPLINK => Synthesis/Busses/Uplink ou Synth_SHELVE_CUTOFF => Synthesis/Filters/Shelve Cutoff. Les noms donnés aux modules est une sorte de hiérarchie, mais comme ils ne changent jamais, utiliser une autre hiérarchie serait une bonne idée (ceci nous permettrait aussi de traduire cette hiérarchie pour les versions internationalisées).
Tous les modules non-structurés comme Synth_PLAY ou Synth_MUL ou Synth_CDELAY devraient tout de même trouver une place dans cette hiérarchie.
Imaginez comment l'interface graphique et le système de synthèse pourraient être étendus en temps réel avec les modules externes chargeables dynamiquement. Il y a quelque chose dans koffice2, mais je ne sais pas si ça peut nous être utile.
En particulier pour les synthétiseurs, on ne peut pas se permettre d'avoir des pertes de performances lors de l'ordonancement ;)
Comment Arts et le reste du monde communiquent ? Comment les événements midi peuvent être acheminés ? OK, il y a une solution facile, mais ce n'est pas recommandé si vous avez dix appareils sur votre bus midi. Pas encore. Dans tous les cas, ceci doit être discuté en public (sur la liste de diffusion KDE correspondante), pour rendre les choses compatibles à l'avenir.
En tout cas ce serait bien si plus de programmes (outre Cantor) pouvaient supporter les bus midi. Peut-être quelques "trakers" (voodoo tracker, soundtracker, kegtracker), ou quelques séquenceurs (jazz, koobase, gseq, etc.)
PS : je ne me focaliserai pas à faire de aRts (et le bus midi et ce qui va avec) un projet KDE uniquement, mais écrire une interface graphique KDE était pour moi le meilleur moyen de faire fonctionner les choses rapidement et de les rendre utilisables. Je veux FAIRE DE LA MUSIQUE avec bientôt, et pas de la conception pendant deux ans ;)
Le bus midi devient lent sous une forte sollicitation (un millier d'événements par seconde). Ce n'est pas sympathique. Je pense qu'il serait possible de remédier totalement à ce problème s'il y avait un standard pour passer les événements par le bus mais pas en temps réel. Ça pourrait fonctionner comme suit :
Le programme client demande au serveur d'ouvrir un canal
Le programme client envoie les événements pour les dix premières secondes (avec des messages de synchronisation ou "time stamp")
Le programme client dit au serveur de démarrer
Le serveur notifie au programme client lorsqu'il a besoin de plus d'événements
Le programme client décale la position dans le morceau
Le programme client envoie plus d'événements lorsque cela est nécessaire.
Puisque transférer plusieurs événements d'une séquence simultanément devrait être beaucoup plus rapide que les transférer un par un, on devrait pouvoir utiliser CORBA.
Une autre option serait de transférer les événements en utilisant des sockets TCP, UDP ou IPC à mémoire partagée. Toutes ces solutions seront plus rapides que CORBA.
Il y aura peut-être quelque chose d'autre... voir la section bus midi/autres considérations.
Cette partie est aussi un vrai challenge. Nous avons besoin de quelque chose qui montre ce qui se passe - et bien sûr tous ces boutons que l'on peut bidouiller pour modifier le son. Peut-être pouvons-nous aussi réutiliser quelque chose de koffice, pour avoir des composants qui peuvent être simplement chargés en cours d'exécution.
Bref, il y a des choses qui fonctionnent, mais bien sûr beaucoup de choses à améliorer.
Tout ce qui peut accélérer les choses est le bienvenu. Vous aurez à essayer, vous arrêter un instant et réfléchir un peu ici. aRts est déjà beaucoup plus rapide à partir de la version 0.3.0 en raison du calcul multi-échantillons
PS : le support multiprocesseur (SMP) serait une bonne chose.
C'est proche de la normalisation des modules (voir plus haut). Nous en avons besoin... maintenant, parce que sans modules sympathiques et qui travaillent ensemble à merveille, aRts ne vaut rien.
Vous n'avez pas besoin de grandes connaissances en programmation (C ou C++), puisque les modules qui mélangent deux échantillons ou ceux qui retardent des données audio sont relativement simples. ;)
La synthèse n'est certainement pas le moyen idéal pour tout faire. Si vous voulez un Steinway, vous devez peut-être en acheter un en échantillons et l'utiliser. Ce serait bien si aRts pouvait simplement lire les CD d'échantillons dans des formats habituels, comme AKAI. Cela rendrait la composition avec aRts vraiment plus facile. C'est aussi beaucoup de travail en moins que d'utiliser un piano complet échantillonné avec des commutations sur la vélocité, plutôt que de les configurer à la main dans des boîtes de dialogue.
Résolu en grande partie.
Ce serait bien si le système de flux de aRts pouvait, outre traiter les signaux audio, supporter aussi les événements. Cela signifierait que vous pourriez avoir des modules qui transposent, combinent, modifient et filtrent les messages midi tout comme les modules qui font la même chose sur les signaux.
Personnellement, je pense que ce serait une bonne idée de rendre aRts capable de remplacer esd, kaudioserver, nas et d'autres à l'avenir. aRts devrait devenir un mélange de DirectX et DirectShow, Generator et le sous-système audio CuBase VST/Logic audio.
En tous cas cela nécessite de travailler sur l'intégration avec les autres et de s'assurer que aRts peut réellement supporter toutes les tâches qui sont actuellement aussi supportées par les serveurs audio classiques.
Considérons le problème suivant : vous voulez décrire une table de mixage virtuelle. Cette table a un certain nombre de canaux, et un certain nombre d'effets. Sur chaque canal, vous avez un préamplificateur, et ensuite un égaliseur. Alors, une certaine quantité du signal est acheminée à travers les différents processeurs d'effets (y-compris un processeur d'effet nul, correspondant à un jeu direct).
Il devrait être possible de décrire la table de mixage virtuelle dans aRts, puis les effets (délai, réverb, chorus...) puis les instruments (piano, kit de batterie, cordes...).
Après cela, les caractéristiques devraient être placées dans une sorte de base de donnée de structures. Finalement, l'utilisateur final devrait uniquement faire les choses suivantes :
Démarrer le séquenceur
Dire hmmm, je veux une table de mixage
En sélectionner une dans la liste
Avoir des boutons pour ajouter et enlever des canaux
Régler le nombre de canaux à 4
Charger des effets (délai, réverb, chorus et aucun)
Charger des instruments (piano, kit de batterie, cordes)
Assigner les instruments aux canaux
Utiliser la table de mixage pour calibrer les canaux
Utiliser les panneaux d'effets pour les configurer
Commencer à composer
Les structures qui peuvent être utilisées comme modules (comme dans la version 0.3.1) résolvent probablement une partie du problème, mais ces structures ne sont pas vraiment un concept complet. Il y a déjà eu des travaux sur ce problème, mais encore plus de travaux sont probablement nécessaires
Par exemple, le fait qu'il y ait un exemple example_mixer_simple, example_mixer_eqfx, example_mixer_eq, example_mixer_eqfx8, ... devrait vous faire réfléchir. Pourquoi autant ? Et pourquoi le comptage des canaux est codé en dur ? Il devrait y avoir un moyen plus modulaire pour résoudre cela dès que de nouveaux effets vont apparaître.
Pensez-y.
Arts ne devrait pas consommer du processeur tant que rien n'est calculé - ceci implique des changements significatifs dans l'ordonnanceur pour que cela fonctionne.
Le serveur de l'interface graphique et du flux devraient partager une quantité plus importante de leur implantation - ce serait parfait s'ils utilisaient aussi des modules externes communs
Le transfert entre l'interface graphique et le serveur de synthèse avec CORBA est une mauvaise idée dès que le nombre d'événements augmente. Un nouveau logiciel médiateur de transfert a besoin d'être écrit, par exemple pour être capable de supporter les analuseurs de spectres graphiques, dans un soucis d'économie du processeur.
Utiliser la mémoire partagée ou TCP serait probablement une bonne idée.
Synth_WAVE_TRI devrait s'appeler Synth_WAVE_SAW, et Synth_WAVE_TRI devrait être réimplantés comme sur tous les autres synthétiseurs. Changez les exemples pour cela.
Synth_WAVE_PULSE devrait être une onde carrée avec des temps de montée/descente configurables. Faites des exemples.
Utiliser une structure appelée "foo" dans une structure "foo", et exécuter le résultat donne un plantage.
Considérer l'écriture d'un module qui lit directement /dev/midi (pas par midisend)=> plus rapide.
Transposition de la hauteur des fichiers d'échantillons (même implantation que dans les modules AKAI, peut être beaucoup de code commun à convert.cc).
Refaire la structure des répertoires (si vous voulez le faire, demandez d'abord). Les modules devraient être séparés.
Ajouter le code d'un écran d'accueil lors du chargement au lieu de ce laid "should I start the server now". Contactez Harald pour les graphiques.
Essayez d'intégrer le support des polices de partition de façon intelligente - le code est par exemple disponible dans timidity.
Ajouter le support ALSA natif.
Implanter le chargement progressif des échantillons, ce qui devrait conduire à de meilleures performances sur le premier échantillon joué.
Éliminer Interface_MIDI_NOTE et le remplacer par des ports standards (éventuellement compliqués).
Les instruments qui nécessitent un nom de fichier devraient être capables d'avoir un panneau de contrôle où vous pouvez entrer cela (éventuellement compliqué).
Chaque module devrait avoir son propre fichier (cette idée est proche du nettoyage de la structure du répertoire)
Les modules devraient être des librairies partagées.
Éviter d'appeler kvt s'il n'est pas présent (appeler autre chose comme xterm à la place).
Enlever chaque "Calculate" et le remplacer par "CalculateBlock" - après cela, enlever complètement "Calculate" de SynthModule et mettre "CalculateBlock".
Introduction de kdoc
Les boutons d'aide devraient faire quelque chose (le mieux serait d'afficher une page d'aide, en fonction du contexte).