Le module "guitare" en C a été entièrement vérifié. Nous avons commencé à chercher les dernières améliorations possibles des sonorités, en utilisant les enregistrements de réponse impulsionnelle de la caisse d'une guitare pour filtrer le résultat. Ceci pourrait également servir d'égaliseur numérique multibande, le son de la guitare pouvant être altéré graphiquement par l'utilisateur. Une courbe allant du grave à l'aigu, mettant en avant les bornes de fréquence de son choix, pourrait ainsi être librement modifiée par l'utilisateur lors de la définition d'un nouveau son de guitare, Beaucoup de réglages extrèmements poussés pourraient ainsi être disponibles. Il nous faut simplement nous assurer qu'ils ont une utilité, et que le concept qu'ils représentent soit compréhensible par un utilisateur moyen n'ayant que peu de notions de synthèse sonore. La partie "boîte de configuration" risque donc de ne pas être des plus simples. Autant que possible, nous essaierons de grouper les paramètres internes du modèle, d'en calculer automatiquement d'autres, et de formuler tout cela avec soin afin de pouvoir proposer des réglages ayant un rapport avec les attributs physiques de l'instrument. Il vaut mieux en effet demander la valeur "longueur de la corde en cm" plutôt que "taille des buffers de calcul de résonnance" par exemple |
|
|
by Olivier Guillion | | |
| |
|
La génération de sons de guitare est maintenant entièrement réécrite en C. Nous obtenons les mêmes résultats que le module MyrScript, mais, comme attendu, beaucoup plus rapidement. Le programme est court (une cinquantaine de kilo-octets) ce qui nous permettra de l'intégrer à n'importe quel produit sans augmenter sensiblement la taille du programme hôte. Pour l'instant, avant optimisation du code, pour calculer 50 secondes de son, il faut 10 secondes de traitement. Ceci est cependant trop lent pour envisager un passage en temps réel, car si une partition contient 3 guitares jouant à la fois sur un ordinateur moins rapide que le nôtre, le processeur est alors monopolisé. Donc la phase suivante consistera à tenter d'accélérer tout cela. |
|
|
by Olivier Guillion | | |
| |
|
Nous avons commencé le travail de réécriture en C, travail qui tient plus de la correction d'épreuve que de la véritable programmation. En effet, MyrScript et le C sont très proches, et la plupart du boulot consiste à reformuler chaque ligne et à en changer la ponctuation. Cette tâche n'est malheureusement pas automatisable, notamment à cause des structures dynamiques de MyrScript qui ne sont pas directement transposables en C. Nous avançons donc doucement, en testant dès que possible ce que nous avons écrit. La synthèse de guitare est constitué de quatre couches successives, de la plus profonde à la plus "haut niveau": 1- Gestion physique des résonnances et amortissements dans une corde 2- Définition de la corde, avec ses paramètres de matériau, et gestion des effets d'un doigt posé sur le manche, du glissement de celui-ci sur le trait, etc. 3- Définition de l'instrument, qui est un ensemble de cordes, une série de frettes, un corps résonnant... 4- Interprétation des notes et transformation de celles-ci en mouvements de doigts, grattage de chaque corde, etc Nous avons terminé le niveau 1 et sommes en train d'attaquer le niveau 2. Nous avons choisi de programmer tout cela comme un module indépendant, mais qui pourra cependant être inclus dans Harmony par la suite si besoin est. Avantage, la compilation et les tests sont très rapides, mais inconvénient, le module n'a pas accès facilement à une partition ou les notes qui la composent. Donc lorsque nous arriverons au niveau 4, un module MyrScript sera probablement nécessaire au début pour extraire d'une partition des informations simples (quelle corde, quelle case, à quelle puissance, à quel moment) pouvant être ensuite interprétées par le module. |
|
|
by Olivier Guillion | | | |
|
Nous avions oublié d'implémenter quelques dernier détails dans le rendu de la guitare : les pincements ou coups de médiator complexes, détaillés dans ce billet, et surtout les résonnances par sympathie. Surtout, car la nouvelle structure du programme considérait les cordes comme des entités acoustiquement indépendantes, chacune étant calculée indépendamment des autres, puis mixée au résultat final. Si on veut prendre en compte les résonnances par sympathie, ceci n'est plus possible, car à chaque instant, chaque corde reçoit un peu d'énergie provenant de la vibration des autres cordes. Les calculs doivent donc s'effectuer en parallèle. La structure du module a donc été repensée pour prendre cela en compte. Algorithmiquement, tout est donc maintenant au point. Acoustiquement, par contre, les résonnances par sympathie, comme nous avions pu nous en apercevoir lors de nos premiers tests, ne nous semblent pas améliorer tant que cela le résultat. De manière générale, cela allonge les délais d'amortissement des cordes, mais a tendance à faire perdre de la netteté au morceau. Il faut également régler les coefficients avec minutie, sous peine de produire un semblant de larsen. Le gain en "coffre", en profondeur du son, s'il est indéniable, peut être aisément remplacé par d'autres réglages déjà disponibles, et beaucoup plus faciles à manipuler et à régler. Donc, en conclusion, beaucoup de travail pour un bénéfice faible voire nul. Nous nous interrogeons encore sur la nécessité de conserver ce paramètre... |
|
|
by Olivier Guillion | | |
| |
|
La maquette Myrscript de la génération de sons de guitare est quasiment terminée. Elle intègre de manière propre tous les essais que nous avions effectués séparément : harmoniques, étouffement de corde, bruit de trait, passage de case en case lorsque le doigt glisse sur le manche, coup de médiator paramétrable, etc. Nous avons calé tout cela à partir de mesures réelles. Un passage de la guitare au scanner nous a permis de compter la densité des enroulements de chacune des cordes graves: . Nous avons également chronométré les temps d'amortissement naturel du son pour chaque corde à vide. Nour réobtenons donc des résultats sonores comparables à nos premiers tests, avec en plus les effets de déplacement des doigts, même si nous avons pour l'instant moins soigné le timbre de l'instrument. Cela demande en effet pas mal d'efforts, et le programme Myrscript est destiné à être entièrement réécrit en C dès que sa structure est fonctionnelle et vérifiée dans les détails. Notre test le plus récent (probablement le dernier calculé en MyrScript) donne ceci: Cliquer pour écouter En Myrscript, le temps de calcul est le triple du temps réel. Nous espérons que la version C sera, elle, suffisamment rapide pour ne pas nécessiter un calcul à l'avance comme pour Virtual Singer. C'est en fonction de cela que nous pourrons ensuite décider sous quelle forme et pour quels usages distribuer le nouveau module de synthèse sonore. |
|
|
by Olivier Guillion | | |
| |
|
Nous avons réécrit proprement, toujours en MyrScript, la génération de sons de cordes, pour l'instant pincées. C'est ce programme MyrScript, une fois parfaitement au point, qui nous servira de modèle pour le passage en C. Nous essayons donc de faire fonctionner à la fois tout ce que nous avions pu expérimenter jusqu'ici. Nous avons également mis en place les bruits de cordes lors du déplacement des doigts. Il devrait donc être possible, lors de la définition de l'instrument, d'indiquer la longueur de chaque corde et, pour les cordes gainées, le nombre d'enroulement du fil de gainage (appelé "trait") par centimètre, ainsi que sa rugosité. En effet, certains traits sont limés ou constitués de fil plat afin de minimiser les bruits parasites. En l'état, notre premier test a donné ceci (attention, c'est court): Bruit de trait Reste maintenant à gérer les déplacements des doigts de manière réaliste, afin de connaitre les moments où le doigt glisse sur la corde, et ceux où il ne la touche pas. |
|
|
by Olivier Guillion | | | |
|
Nous poursuivons notre amélioration des cordes frottées. Les résultats sont meilleurs, mais avec, parfois, des passages inexplicables à l'octave, ou des grattements inopinés. Peut-être est-ce dû aux paramètres de frottement de l'archet, car il semble qu'en modifiant légèrement la distance par rapport au chevalet, ces artefacts disparaissent. Afin de connaître un peu mieux les spécificités de cet instrument, et vérifier si ces effets étaient également présents dans la réalité ou dûs à des erreurs dans notre modèle mathématique, nous avons décidé de louer un violon. Malheureusement, tous les luthiers et loueurs de la région sont en vacances jusqu'au 24 août. Il nous faudra donc patienter jusque là pour commencer nos expérimentations. Nous préférons ne pas poster des exemples sonores imparfaits de notre travail, car nous savons que même si nous détaillons les imperfections connues, les commentaires ne manqueront pas de s'y attacher. C'est comme si on présentait un dessin en disant: les personnages sont terminés, mais le décor n'est encore qu'une ébauche, et que toute la discussion portait sur le rendu de l'herbe, des feuillages et des nuages. Nous avons entamé une dernière mise au propre du script MyrScript qui gère les sons de guitare, avant un passage en C. |
|
|
by Olivier Guillion | | |
| |
|
Les essais d'amélioration des cordes frottées ne sont malheureusement guère concluants. Mathématiquement, les calculs semblent justes, et le son obtenu est bien celui d'une corde frottée non reliée à une caisse de résonnance. C'est donc un son très aigu, désagréable et sans profondeur. Ce son, dans la réalité, passe au travers du filtre de la caisse de résonnance de l'instrument. Nous avons pu simuler ces résonnances, mais cela reste approximatif. En résultat, nous obtenons bien un son d'instrument à cordes frottées, mais un son pas beau, celui d'un mauvais violon utilisé par un mauvais interprète. Notre méconnaissance du son naturel d'un violon lors d'un jeu avec un archet frotté avec trop - ou trop peu- de force ou de vitesse rend d'autant plus difficile la tâche d'ajustement des paramètres du coup d'archet. Rien n'est donc encore désepéré, et ce travail nous a déjà permis d'élaborer des techniques qui seront probablement réutilisables ensuite, notamment l'établissement d'un banc de filtres rapides simulant les résonnance du corps d'un instrument. Simplement, le système, paramétrage ou astuce qui permettrait une amélioration significative du résultat sonore tarde à se montrer, et cela devient un peu lassant, et très fatigant pour les oreilles |
|
|
by Olivier Guillion | | | |
|
Bon, le système de corde est en place, et nous pouvons maintenant calculer des morceaux en traitant chaque corde indépendamment et en suivant les indications de doigté de la tablature. Tant qu'on y était, nous avons affecté à chaque corde une position stéréo légèrement différente, et avons géré les résonnances par sympathie. Ensuite, nous avons configuré l'excitation, c'est-à-dire l'action du doigt, de l'ongle ou du mediator sur la corde. Ceci a une importance sensible sur le résultat final. A titre d'exemple, un morceau avec une excitation simple, ponctuelle: pincement simple et le même morceau avec une excitation plus élaborée, faisant entendre le moment où le médiator touche la corde et le moment où il la relâche: pincement complexe La différence est assez subtile, il vous faudra tendre l'oreille. On arrive maintenant aux limites des possibilités de traitement par MyrScript. Chacun de nos tests demande un temps de calcul assez long (quelques minutes), nous empêchant d'ajuster rapidement les paramètres à l'oreille. Nous envisageons donc de réécrire tout ou partie de ce que nous avons fait en C, afin d'accélérer tout cela. |
|
|
by Olivier Guillion | | | |
|
Paradoxalement, l'augmentation du réalisme des modèles physiques nous empêchent de truquer facilement le système pour lui faire produire des sons paraissant plus réalistes à l'oreille. Ainsi, dans les premiers essais de guitare, nous nous étions affranchis des calculs de résonnance de la caisse. En jouant artificiellement sur les courbes d'amortissement de chaque corde, on pouvait obtenir un son "rond". Avec un vrai modèle vibratoire de la corde, il est plus difficile d'obtenir ce genre de résultat. C'est pourquoi nous avons continué à travailler sur les modifications du son liées aux résonnances de la caisse de l'instrument. Voici la piste que nous explorons : A partir de l'enregistrement de l'impusion de l'instrument (coup donné sur le chevalet), par convolution avec un bruit blanc, nous extrayons une courbe de réponse en fréquence du filtre audio que forme la caisse de l'instrument. Cette courbe est alors approximée par une série de filtres passe-bande simples, qui devraient être plus faciles à mettre en place qu'un filtrage par transformée de Fourier et inverse. Il n'est pas certain que nous arrivions à quelque chose avec cette méthode, mais avant de bricoler quelque chose de faux ayant l'apparence du vrai, autant commencer par essayer le vrai... |
|
|
by Olivier Guillion | | | |
|
Afin de simuler correctement les glissades, les "bend", le vibrato et toutes ces modifications de fréquences, nous avions besoin d'une grande précision dans la restitution. Or, avec nos modèles de vibration actuels, une telle précision n'était pas possible. Nous avions donc implémenté un oversampling, c'est-à-dire un calcul de 4 données numériques pour chaque donnée effectivement restituée, mais cela ne donnait toujours pas une précision suffisante, et le temps de calcul était multiplié par 4. Nous avons donc travaillé sur une généralisation de l'algorithme, en permettant une précision supérieure au 1000e d'Hz. Nous en avons profité pour mettre au propre notre programme MyrScript, en gérant vraiment plusieurs cordes différentes par instrument. Ceci nous a permis de mettre en place les résonnances des cordes par sympathie. Reste à savoir si cet effet sera audible lors du jeu. |
|
|
by Olivier Guillion | | | |
|
|