Quelques correction sur les scripts, ce jour. Script Finale, NoteWorthy, GuitarPro. Rien de trépidant, on reprends doucement le rythme.
Nous commençons à réfléchir comment intégrer le nouveau système de synthèse sonore à nos produits. Il va y avoir deux parties :
- D'abord, la configuration de l'instrument, globale à la portée qui devra être la plus simple possible et se référer à des valeurs "humaines" : longueur et tirant (diamètre) des cordes, résonance de la caisse, densités des traits, etc.
- Ensuite, tous les paramètres qui peuvent changer lors de l'exécution : vitesse et pression sur l'archet par exemple. Ceci pourrait être géré par de nouvelles courbes de paramètres...
Le but étant de proposer des instruments réalistes facilement utilisables, mais que l'utilisateur plus pointilleux soit capable de configurer finement.
|
|
|
| by Didier Guillion |  |
| |
|
Aujourd'hui, et pour redémarrer en douceur après une semaine de vacances, quelques corrections.
Correction d'un débordement au chargement MIDI de certains fichiers très particuliers.
Correction de l'ouverture des palettes filles depuis la palette maître.
Enfin, correction d'un décalage de texte dans les ressources Italiennes et Allemandes.
|
|
|
| by Didier Guillion | |
| |
|
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 | |
| |
|
Aujourd'hui quelques corrections sur l'aspect graphique des tablatures.
Nous compulsons énormément de documentations sur le violon, le piano, la guitare.
Nous avons lu que pour calculer une tablature pour violon, il suffisait de choisir la mandoline comme instrument...
Un violoniste peut il confirmer ?
|
|
|
| by Didier 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 | |
|
| |
|
Quelques corrections dans Harmony et Melody aujourd'hui.
Correction du script "Suit les portées jouées".
Correction du script "Doigté pour instrument à cordes frettées".
Correction du script "Import NoteWorthy".
Et puis, un truc qui me mets en rogne, en discutant avec Olivier d'une question reçue par email qui m'a pris du temps, c'est d'apprendre que la personne avait envoyé le même mail à nous deux et nous a fait travailler tous les deux dessus.
C'est du temps gâché et cela me rends furax. Grrrr ! |
|
|
| by Didier 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 | |
| |
|
Aujourd'hui nous avons repris certains éléments du plug-in Flash afin d'optimiser des temps de réponse. Nous ne pensons pas aller beaucoup plus loin dans ce développement. Il nous a permis d'appréhender ActionScript/Flex/Flash et d'ajouter ainsi une compétence à notre liste de faisabilité. Sincèrement, Flash est un très bon concept, soutenue par une communauté des plus active, une excellente et amusante expérience.
Maintenant, la prochaine étape (dès que nous aurons du temps) va être d'étoffer et de nettoyer la base de donnée.
Bon week end à tous ! |
|
|
| by Didier Guillion | |
| |
|
Comme pas mal de code est commun entre le Player et le Plug-In, nous avons intégré le Clavier Virtuel au Plug-In.
Des commandes spécifiques permettrons de l'activer, de l'afficher par défaut, de choisir l'octave de base et le nombre d'octaves représentées.
La demande initiale vient d'une société qui commercialise des méthodes d'apprentissage du piano, nous espérons qu'elle saura séduire d'autres utilisateurs... |
|
|
| by Didier Guillion | |
|
| |
|
On nous a suggéré, il y a quelques mois, une amélioration de Melody Player. Le but initial était d'utiliser ce logiciel pour gérer des méthodes d'apprentissage du piano. Après quelques temps de réflexion nous avons ressorti le dossier. Voilà ce que cela va donner.
Une nouvelle icône fait son apparition, elle active le clavier virtuel.
L'utilisateur peut choisir quel instrument va être représenté sur le clavier, soit tous, soit un seul. Dans le cas du piano, bien sur, il faut que main gauche et main droite sortent sur des instruments séparés.
Une demande était de permette un branchement direct sur une URL pour pouvoir télécharger des MP3 de la partition ou de lire des explications sur l'interprétation du morceau. L'astuce a été d'utiliser le champ "Site Web" du document, ainsi chaque document de la liste peut avoir son URL dédiée.
Une autre demande était de pouvoir différencier la main gauche et la main droite par des couleurs différentes. Là aussi, astuce : il suffira de donner une indication stéréo correspondante à l'instrument associé à la portée. Les instruments de position stéréo inférieure à 64 seront en bleu, les autres en orange.
Enfin, si dans le site Web associé au document, la séquence "key=on" est trouvée, le piano virtuel est actif par défaut.
Théoriquement, ceci pourrait être facilement implémenté dans le Myriad Music Plug-In. |
|
|
| by Didier 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 | |
| |
|
Après le traditionnel traitement des emails du week end, nous avons réfléchi au logo de Kooplet, guidé par les conseils de Franck.
Pour l'instant, nous en sommes là :
 |
|
|
| by Didier Guillion | |
|
| |
|
La palette de doigté pour instruments à cordes frettées gère maintenant les gauchers.
Elle sera disponible dans la prochaine version d'Harmony.
Parallèlement à ceci, le moteur de génération d'onde a été calé finement. Il servira pour tous les instruments à corde, il devait donc être parfait et rapide. Nous avons fait quelques essais sur une synthèse de guitare et il apparaît que l'excitation de lancement du son est des plus importante. On obtient, si on utilise des médiators plus ou moins souples des résultats très différents, ce qui est encourageant.
Allez, bon week à tous et peut être un échantillon sonore Lundi... |
|
|
| by Didier Guillion | |
| |
|
L'édition d'un symbole pouvait "casser" la mise en page, c'est corrigé.
Correction d'un problème de déplacement de coulé.
En MyrScript, nouvelle valeur Application.IsLeftHandedNotation
On nous a demandé si la palette de doigté pour instruments à cordes frettées pouvait tenir compte de la notation pour les gauchers.
Nous avons commencé l'analyse de ceci.
|
|
|
| by Didier 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 | |
| |
|
Correction de la taille des fenêtre utilisateur zoomées au chargement.
Nouvelle gestion des accroches sur tuplet en import music XML.
Correction de l'affichage de l'accroche en tablature guitare quand un écart était demandé entre la tige et la note. |
|
|
| by Didier 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 | |
| |
|
|
