Nous avons continué à faire saigner nos oreilles sur les instruments à cordes frottées. Pour commencer, nous avons avancé sur la technique de filtrage à réponse impulsionnelle. Cette technique est principalement utilisée pour capturer et restituer l'acoustique d'une pièce : Un bruit très court est émis dans la pièce, à l'endroit où se trouverait l'instrument. Des micros, placés à l'endroit où devrait être l'auditeur, captent ce son, appelé Impulse Response, qui est simplement enregistré en numérique. Ensuite, il suffira alors d'effectuer une convolution (multiplication) entre n'importe quel morceau numérique 'sec' (sans effet) et cet "impulse response" pour restituer d'un coup toutes les réverbérations et l'acoustique de la pièce, comme si l'instrument avait été enregistré là. Nous avons adapté ce système aux instruments à cordes : la corde vibre, et produit un son avec un timbre assez aigu. Ces vibrations sont transmises à la table d'harmonie par l'intermédiaire du chevalet. La caisse de l'instrument fait résonner le son, altère son timbre, et c'est ce résultat que nous entendons. En enregistrant le résultat d'un coup sec porté sur le chevalet, on obtient l'Impulse Response de l'instrument: Impulse Response d'une guitare Pour éviter les calculs relativement simples mais trop nombreux liés à une véritable convolution, on stocke simplement les valeurs du banc de filtre que constitue la caisse de l'instrument, pour pouvoir l'appliquer ultérieurement aux sons bruts générés par notre modèle de corde. Mais d'abord il faut simuler le frottement de l'archet sur une corde. Le problème est, tous ceux qui ont essayé de tirer un son d'un violon le savent, il ne suffit pas de frotter n'importe comment pour produire une note. De nombreux paramètres entrent en jeu: - La position de frottement sur la corde - La force d'application de la mèche sur la corde, et l'évolution de cette force au cours du temps - La vitesse de déplacement de l'archet, et l'évolution de cette vitesse au cours du temps - Les paramètres de friction (pour un vrai violon, la qualité et quantité de collophane) Ainsi, notre premier essai virtuel, effectué sur une corde grave de violoncelle, n'a pas été fameux, l'archet glissant sans produire de son : Frottement raté En ajustant un peu, nous parvenons à produire notre premier son: Frottement un peu plus réussi Ca fait un peu mal aux oreilles, mais on est sur la bonne voie. On raccourcit la corde, et on réessaye: Note de violon bruitée On rend le glissement un peu plus fluide, et nous avons notre première note digne de ce nom: Note de violon correcte Il manque encore beaucoup de paramètres au modèle pour le rendre vraiment réaliste: un vibrato et surtout la gestion des numéros de corde, qui empêchent une corde de continuer à sonner lorsqu'une nouvelle note est jouée dessus. Ces erreurs sont présentes dans les morceaux d'exemple qui vont suivre, et génèrent un effet de réverbération indésirable, mais on peut déjà commencer à se faire une idée. Essai de violon Essai d'Alto Ces morceaux ont été filtrés à partir de véritables enregistrement Impulse Response de violon et d'alto trouvés sur Internet. Si vous avez un Stradivarius chez vous et que vous acceptez de donner un grand coup dessus pour enregistrer le résultat, nous sommes preneurs. |
|
|
by Olivier Guillion | | |
| |
|
Nous avons travaillé sur les instruments à cordes frottées. Devant la galérosité de la chose, nous en avons profité pour réétudier le modèle informatique de la corde vibrante, et améliorer du coup le module "corde pincées". Nous obtenons maintenant un calcul permettant de mettre en évidence les ondes stationnaires au sein de la corde. En effet, précisément aux fréquences multiples de la fréquence naturelle de la corde, cette dernière vibre, mais des points précis restent rigoureusement immobiles, la corde présentant alors une alternance de fuseaux et de noeuds. Lors du jeu, lorsque la corde est pincée, ces ondes stationnaires ne se forment pas, car toutes les fréquences multiples sont jouées en même temps. Cependant, c'est ce phénomène qui est utilisé pour jouer des "harmoniques". Le doigt du guitariste est placé précisément à l'endroit d'un noeud d'un multiple donné de la fréquence de base de la corde. Ce doigt ne bloque pas vraiment la corde, il amortit ses mouvements en ce point. Ainsi, toutes les fréquences qui ne possèdent pas de noeud à cet endroit sont coupées, laissant sonner la corde à une fréquence plus aigue, avec un son caractéristique. Grâce à notre nouveau modèle de corde, ce phénomène est facilement reproductible. Voici un exemple: la corde est grattée normalement, puis la même corde est jouée, mais un doigt est positionné au milieu, puis au tiers et enfin au quart de la longueur de la corde: Harmoniques Guitare Le phénomène est réellement créé par modélisation. Si on place le doigt au mauvais endroit on obtient un "ploc" comme dans la réalité. De même, il est maintenant facile de modifier la position sur la corde du grattement de la main droite. En effet, la position du pincement influe sur le son. Généralement, les guitaristes grattent toujours au même endroit (au-dessus de la rosace), mais en proportion de la longueur vibrante de la corde, plus la case pressée sur le manche est proche de la rosace, et plus le pincement s'approche de la moitié de la corde. Le timbre du son doit donc changer. Ce n'est peut-être pas perceptible, mais ça vaut le coup d'en tenir compte, le réalisme général pourrait en être augmenté. En attendant une démo complète, voici un exemple de corde grattée normalement (sur la rosace), puis près du chevalet, et enfin au-dessus du manche, au milieu de la corde. La différence est flagrante: Positions de pincement Maintenant que le modèle vibratoire de la corde est complet, si nous voulons simuler violon, alto ou violoncelle, il faut passer du pincement au frottement, et modéliser l'influence d'un archet sur une corde en mouvement. |
|
|
by Olivier Guillion | | |
| |
|
Tout d'abord, merci à ceux qui ont commenté le billet d'hier. Nous avons toujours un doute lorsque nous partageons des sons, la notion de réalisme d'un instrument étant grandement subjective. Nous tentons maintenant d'adapter notre programme de synthèse de sons de guitare à d'autres instruments de la même famille. Des essais ont été menés pour trouver les paramètres correspondant aux divers sons de basse (frappée, sans frette, slappée, etc) En parallèle, nous commençons à récolter de la documentation (et à la lire, lorsque nous en avons le courage) sur les autres types d'instruments, plus ou moins proches. Si quelques parties de ce que nous avons déjà fait devrait pouvoir être réutilisées pour la simulation d'autres instruments à cordes (l'amortissement des vibrations d'une corde obéit toujours aux mêmes lois physiques), pour les bois ou les cuivres, il faudra tout reprendre à zéro. Pour l'instant, donc, nous nous contentons de faire un tour d'horizon, et de travailler sur le son de la guitare et des instruments apparentés. |
|
|
by Olivier Guillion | | |
| |
|
Ces derniers jours, nous avons mené quelques expérimentations dans le domaine de la synthèse sonore d'instruments à cordes, et plus spécialement la guitare. MyrScript s'est révélé un atout précieux pour construire les maquettes, régler les divers paramètres, et essayer les solutions techniques possibles. Nous avons pour l'instant arrêté notre choix sur une combinaison de plusieurs méthodes, notamment un banc de filtres d'amortissement couplé à de la synthèse additive. Quel est l'avantage d'une telle génération d'instrument, comparé aux instruments samplés? - Tout d'abord, la dynamique du son est beaucoup plus importante. Pas la peine de filtrer les bruits parasites, d'atténuer la réverbération de la pièce dans laquelle l'enregistrement a eu lieu, etc. - Ensuite, les niveaux de vélocité (la puissance de jeu) sont infinis, puisque calculés et non stockés. - L'instrument est configurable à l'envi, en modifiant les paramètres de génération, ce qui n'est pas le cas des instruments samplés. - La possibilité de produire facilement un son différent en fonction de la corde, une même note pouvant être jouée par des cordes différentes (pas encore abordé dans notre maquette) - La possibilité de pousser plus loin l'humanisation et le réalisme de l'instrument, en gérant les bruits des doigts sur les cordes, les résonnances par sympathie, etc. (pas encore abordé dans notre maquette) - Enfin, la légèreté, une guitare virtuelle complète occupant seulement au plus quelques kilo-octets, contre des dizaines de méga-octets pour un enregistrement de guitare en 3 couches de vélocités Mais nous atteignons là les limites de la maquette en MyrScript. Outre le temps de calcul, bien plus long que celui d'un "vrai" programme en C, nous n'avons pas écrit l'éditeur pour les paramètres du synthétiseur, ce qui nous oblige à les régler "à la main". Soyez donc indulgents sur les démos, une interface graphique devrait permettre d'affiner plus précisément tous les réglages. A titre d'exemple donc, des extraits MIDI glanés ça et là sur le net, joués avec une guitare "standard", aux paramètres passe-partout (tout cela généré, je le rappelle, entièrement par notre programme en MyrScript) : Exemple 1 Exemple 2 Exemple 3 Exemple 4 Exemple 5 Et enfin, pour le "fun", quelques sons plus ou moins étranges issus des manipulations des divers paramètres. Ils ont le mérite, à défaut de présenter des sons réalistes, de montrer l'étendue de ce qu'on peut ajuster. Click Maintenant, la question principale reste entière : qu'allons-nous faire d'une telle technologie ? Etendre les sons d'Harmony / Melody avec ce générateur d'instruments virtuels, s'adresser spécifiquement les guitaristes, en leur offrant un jeu d'outils et de sons dédiés ? Un module additionnel destiné à générer des sons de guitare, à la manière de Virtual Singer ? Nous y réfléchissons... |
|
|
by Olivier Guillion | | |
| |
|
Nous nous sommes attachés à tenter de réduire le délai de chargement du plug-in Flash. Il faut attendre en effet environ une seconde et demie pour voir le contenu du plug-in à chaque rechargement de page. Nos tests ont montré que 80% de ce temps est passé à initialiser le moteur de Flash. Le lancement de l'application elle-même ne prend que les 20% restants. Il est donc inutile de nous embêter pour espérer gagner si peu. Nous allons bientôt relancer les "spiders" à la recherche de nouveaux fichiers pour compléter la base. Il nous faut aussi programmer la collecte des déchets, qui vérifie que les fichiers déjà en base sont toujours valides. Au cours de nos tests de recherche, nous avons déjà trouvé quelques liens brisés... |
|
|
by Olivier Guillion | | | |
|
Tout est maintenant en place. Nous avons programmé un petit synthétiseur de type analogique, afin d'éviter d'avoir à embarquer dans le plug-in flash des échantillons complets d'instruments. Le son ne sera donc pas celui d'un instrument réel, mais un son synthétique, que nous essayons de rendre le plus agréable possible. Pour l'instant, il s'agit d'un travail en synthèse additive, auquel nous avons adjoint une petite réverbération, afin de le rendre moins sec. Le but est évidemment de conserver une taille réduite au programme, mais il faut également surveiller les performances, afin de ne pas prendre trop de temps machine pour le jeu de la musique. Nous travaillons sur cette dernière contrainte, ActionScript n'étant pas un foudre de guerre, et les calculs de génération sonore étant assez gourmands. Nous devrions proposer une première version, vous permettant d'essayer tout cela par vous-même en début de semaine prochaine. Bon week-end ! |
|
|
by Olivier Guillion | | |
| |
|
Pour l'instant, le plug-in Flash n'était compilé que sur Macintosh, à l'aide de la version d'essai de Adobe Flash Builder. Nous avons donc recherché les solutions pour faire de même sur Windows. Nous nous sommes arrêtés sur FlashDevelop, une solution gratuite et open source qui offre une interface de développement (IDE) autour des compilateurs et autres outils mis à disposition gratuitement par Adobe. Surprise, pour un freeware open source, FlashDevelop est assez bien fait, compréhensible, et apparemment assez solide. Nous avons pu rapidement créer un programme "Hello world", puis recompiler une petite applet musicale open source proposée par l'excellent André Michelle, pour enfin terminer par le transfert des fichiers source de Kooplet et leur recompilation. Tout ceci est passé comme une lettre à la poste. Seul problème constaté jusqu'ici, mais peut-être dû à une mauvaise installation : le "profiler"montre des pertes de mémoire qui n'existent que lors de l'analyse, et ne sont pas présentes lors du lancement réel du plug-in dans une page Web. Pas très pratique pour traquer les problèmes de consommation de mémoire, par ailleurs assez récurrents dans Flash, apparemment... |
|
|
by Olivier Guillion | | | |
|
Parallèlement au développement Flash, nous avons terminé la mise en place du nouveau système de bases de données et de recherche sur le serveur. Ceci a été mis en ligne à l'adresse habituelle. Seules les recherches ont pour l'instant été testées, il nous faut encore bien vérifier avant de relancer nos robots qui indexent de nouveaux morceaux, afin de s'assurer que les bases sont complétées correctement. Nous avons également mené des essais d'utilisation du nouveau module Flash dans les pages de recherche, et tout semble fonctionner parfaitement. Cette version n'est pas encore en ligne, car le programme Flash est encore ergonomiquement incomplet, mais cela ne devrait plus être qu'une question de jours avant une première version alpha testable de Kooplet, totalement affranchie du Myriad Music Plug-in. |
|
|
by Olivier Guillion | | | |
|
|