enjeux

Ceci est une ancienne révision du document !


A PCRE internal error occured. This might be caused by a faulty plugin

====== Enjeux et Défis ====== La lutherie augmentée pose des vrais défis techniques et artistiques que nous nous proposons de creuser dans ce projet. Prenons quelques exemples. ===== Ultra-faible latence ===== Quel point commun entre le pilotage d'un avion de ligne, le contrôle d'un laser industriel et la lutherie augmentée? Tous trois nécessitent un système informatique fonctionnant à ultra-faible latence, c'est-à-dire que le temps de réaction du système à un événement externe doit être extrêmement court et prévisible. Cet élément est crucial pour la lutherie augmentée, ceci afin que le son traité par l'ordinateur parvienne aux oreilles de l'auditeur "en même temps" que le son direct de l'instrument, créant ainsi l'impression d'augmentation. Dans notre expérience, il est possible d'atteindre sous Linux des latences fiables inférieures à 5ms. À titre de comparaison, cela correspond à peu près au délai introduit en éloignant une source sonore de son auditeur d'une distance de 1.50m! Ces ultra-faibles latences sont comparables à celles de dispositifs dédiés tels que les multi-effets numériques. Malgré cela, plusieurs questions restent ouvertes: quelle est la latence "juste" pour un système de lutherie augmentée? Est-ce que le plus court sera le mieux ou est-ce plus subtil? Peut-on viser des latences encore plus faibles pour synchroniser jusqu'aux transitoires d'attaques? etc. ===== Mélange son direct/son traité ===== On peut argumenter que la guitare électrique est l'instrument pionnier de la lutherie augmentée, et ce n'est pas pour rien: dans un instrument électro-acoustique comme la guitare électrique seul le son amplifié est audible, ce qui permet par exemple l'application de toutes sortes d'effets sans problèmes. En augmentant un instrument acoustique, le son direct de l'instrument reste perceptible et se mélange au son traité, ce qui constitue à la fois toute la richesse de la démarche et un véritable casse-tête pour concevoir des traitements appropriés (sans parler des difficultés liées à l'effet larsen...). Par exemple, l'ajout d'un effet de chorus à une flûte traversière passera presque inaperçu à volume "raisonnable" (c'est-à-dire comparable au volume naturel de l'instrument non-amplifié). Pour que l'effet de chorus prenne le pas sur le son naturel, il faudra pousser considérablement le volume (comprenez "concert de rock" ou très grande salle), ce qui change fondamentalement les domaines d'applications et pose des problèmes considérables de larsen. ===== Intégration physique de l'augmentation ===== Lors d'un concert pour instrument augmenté, la scène ressemble parfois plus au laboratoire d'un savant fou qu'à un salon de musique. Fou, le musicien le devient parfois aussi à force de branchements et fils dans tous les sens, longs et pénibles à remettre en place lors de chaque déplacement. À terme, il conviendra donc de penser de plus en plus l'augmentation comme l'intégration physique de nouveaux éléments dans le corps même de l'instrument afin d'en faire réellement un objet cohérent et utilisable sans migraine (même si, selon toute vraisemblance, le besoin d'une amplification externe restera...) ===== Perennité ===== À la vitesse où évolue la technologie, comment savoir si les développements que je fais aujourd'hui resteront utilisables dans 5 ans, 10 ans? Un critère nécessaire nous semble être l'utilisation de logiciels libres (comme exposé dans le [[credo#perennite-et-independance|credo]]). Mais si elle lui est nécessaire, la liberté ne garantit pas à elle seule la pérennité. Le matériel et les logiciels évoluent très rapidement; les nouveaux modes de jeu développés ne disposent pas toujours de notation permettant de fixer sur le papier les compositions; et les traitements informatiques appliqués au son sont eux-même parfois difficiles à documenter de manière complète. Pour ces dernier point, le langage de programmation *faust* propose une piste originale en permettant de générer automatiquement des représentations mathématiques abstraites du traitement considéré, incluant ainsi toutes les informations nécessaires à une ré-implémentation dans un autre contexte technique. Est-ce réaliste? Faisable pour un dispositif complet? Y a-t-il d'autres pistes à considérer?