Nous avons poursuivi nos discussions sur le futur module d'instruments à cordes.
D'un coté, l'édition avancée des instruments va nous demander de gros efforts de documentation, car les concepts manipulés sont assez costauds, et nécessitent d'être expliqués en détail. De plus, l'assistance technique promet d'être assez ardue. Ceci ferait pencher la balance du coté de la séparation en deux versions, une version standard et une version pro.
D'un autre coté, mettre en place deux produits différents, gérer les différentes licences, expliquer tout cela clairement sur notre site, sachant qu'il ne s'agit que d'un module additionnel (comme Virtual Singer) dont le prix restera modeste, même en version "pro", n'en vaut peut-être pas la chandelle. De plus, limiter les possibilités de création de nouveaux instruments pourrait réduire la quantité d'instruments développés pas les utilisateurs, et donc nuire à l'intérêt que les autres utilisateurs porteraient au module.
Nous y réfléchissons donc toujours. |
|
|
| by Olivier Guillion |  |
|
| |
|
Avant de pouvoir envisager une version beta des instruments à cordes virtuels, il nous faut mettre en place le système de protection et de codes d'enregistrement.
Notre générateur de code, qui est également utilisé pour tous nos autres produits, a très exactement 13 ans d'âge. Il a jusqu'ici parfaitement rempli son rôle, et va apparemment continuer à le remplir quelques années encore.
C'est probablement l'application "privée" (réservée à notre usage interne) la plus spartiate au niveau de l'interface, puisqu'elle ne tourne que sur PC, dans une console MS/DOS. Mais pour calculer de simples séries de codes et les inscrire dans un fichier texte, nous n'avons jamais eu besoin de plus. |
|
|
| by Olivier Guillion | |
| |
|
- Dans MyrScript, mise en place de la gestion du copier-coller dans les objets de type "EditText".
- Amélioration des instruments frettés :
. Conservation d'une mesure sur l'autre des sens de gratté imposés.
Il est maintenant possible d'indiquer les sens de grattage des accords seulement sur la 1e mesure, et toutes les mesures suivantes qui jouent le même rythme utiliseront le même schéma.
. Gestion des différences de vélocités entre la 1e et la dernière note de l'accord gratté
. Correction des décalages en octave des jeux de cordes prédéfinis
. Prise en compte de la longueur du manche de l'instrument dans la prévisualisation de la liste. |
|
|
| by Olivier Guillion | |
| |
|
Retour au générateur d'instruments frettés. Nous avons procédé à des ajustements finauds qui améliorent le rendu sonore.
Après avoir entendu sur France Musique un luthiste expliquer quelques-unes de ses techniques de jeu, nous avons amélioré les positions de gratté des cordes.
Ensuite, nous avons bien étudié quelques vidéos d'exercice de guitare, et notamment de guitare Bluegrass (country). Les mauvaises langues diront qu'en gros, nous avons donc passé notre temps à écouter la radio et mater des vidéos.
L'écoute nous a convaincu de l'importance du son du plectre en prise directe, c'est-à-dire le bruit du plectre ou de l'ongle qui accroche la corde, enregistré directement par le micro, sans passer par la caisse de résonnance de l'instrument.
Nous avions déjà implémenté cela, mais nous avons décidé de l'améliorer un peu.
Ainsi, la transcription d'un petit exercice de guitare rythmique bluegrass donnait ceci :
Guitare bluegrass sans bruit de plectre
Le même, avec le bruit du plectre (légèrement exagéré pour que vous entendiez bien)
Ecoutez bien la différence d'attaque des accords.
Guitare bluegrass avec bruit de plectre
Mais ce bruit, s'il convient à un jeu rythmique, est trop marqué pour des jeux plus délicats.
Il a donc fallu prévoir plusieurs ensembles de bruits de plectre, qui pourront être sélectionnés en fonction de l'instrument.
Ainsi, voici une pièce pour luth, jouée sans bruit de plectre:
Luth sans bruit de plectre
Et le même morceau, avec le bruit du plectre, différent de celui de la guitare bluegrass (et ici également, légèrement exagéré)
Luth avec son bruit de plectre
Voila, il reste maintenant à implémenter ce choix au niveau de l'interface graphique, et à finaliser les différents ensembles de sons de plectre proposés au concepteur d'instruments. |
|
|
| by Olivier Guillion | |
|
| |
|
Lorsque nous avons mis en place les liste de choix arborescentes (pour le choix du modèle de nouveau document) il y a quelques années, nous nous sommes heurtés à un problème de mise en place des traductions.
Les fichiers (modèles) contenaient leur nom complet dans toutes les langues, mais comment traduire les noms des dossiers qui les contiennent ?
Nous avions donc mis en place un système de dictionnaire, relativement complexe, avec prise en compte de l'inversion éventuelle de l'adjectif et du nom, ainsi que les règles de mise au pluriel. Ce dictionnaire est logé dans les données du programme (fichier ressource) et sert également à traduire le nom des portées à l'intérieur du document.
Mais, avec la mise en place des instruments virtuels à cordes frettées, de nouveaux dossiers sont souvent ajoutés, avec des noms qui n'éxistent pas encore dans le dictionnaire. Modifier les données du programme à chaque fois s'avérait compliqué.
Nous avons maintenant prévu qu'un ou plusieurs dictionnaires utilisateurs, sous forme de fichier texte, puissent être directement insérés dans l'arborescence de répertoire qui constituera la liste. Ainsi, l'ajout de nouveau répertoire est facilité, et le système de traduction est accessible à l'utilisateur, qui peut le modifier ou le compléter.
Voici un premier jet de ce que donne le système de traduction sur la liste des instruments virtuels (l'original en anglais, suivi de la traduction automatique en français)
Bon week-end !
|
|
|
| by Olivier Guillion | |
| |
|
Notre envoi d'e-mails de courriels à tous nos clients est maintenant terminé (si vous êtes client mais n'avez rien reçu, votre adresse électronique n'est probablement pas correcte dans notre base de données). Afin d'éviter d'être considérés comme du spam pourriel, ce courrier a été envoyé individuellement à chaque destinataire, à raison d'une poignée d'envois par minute.
Nous avons réceptionné tous les messages d'erreurs, dus à des boîtes aux lettres disparues, ou même des serveurs entiers ayant été rayés de la toile. Etant donné que certaines adresses remontent à près de 15 ans, il y a eu un nombre important de mails courriels non délivrés, en moyenne 30%.
Lors d'un envoi précédent, nous avions déterminé à la louche que chaque année, 5% des adresses e-mails électroniques disparaissaient. Cette fois, l'envoi étant général, les valeurs statistiques sont plus précises. Nous avons entré toutes les données dans un tableur et avons obtenu cette courbe :
La valeur de 5% à l'année semble se confirmer, puisque c'est approximativement la pente de la courbe sur les 10 dernières années (2003-2013).
Par contre, avant cela, on observe un plateau aux alentours de 50%, ce qui semblerait indiquer que la moitié des adresses communiquées il y plus de 10 ans sont encore valables aujourd'hui.
A moins que ce ne soit dû à un nettoyage précédent de la base, qui aurait déjà éliminé les adresses obsolètes de la période 1998-2003.
Mais on peut tout de même affirmer que statistiquement, l'adresse électronique que vous utilisez actuellement a environ une chance sur deux de ne plus exister à l'horizon 2023. Mais le courrier électronique existera-t-il encore dans 10 ans ?
Notez que j'ai fait attention à ne pas utiliser d'anglicisme this time |
|
|
| by Olivier Guillion | |
|
| |
|
Pour réaliser la carte cadeau, nous avions besoin d'un logiciel qui nous permette de préparer le modèle.
Nous avions quelques impératifs. Le logiciel devait :
- permettre de superposer plusieurs images (png) sur le fond de la page
- permettre d'inscrire des textes dessus
- permettre d'écrire certains textes tête en bas
- permettre d'exporter (imprimer) au format PDF
- être multiplateforme (MacOS/Windows)
- être gratuit ou pas trop cher (devoir donner un rein pour fabriquer un truc gratuit nous aurait un tantinet dérangé)
- si possible, permettre à terme d'automatiser certaines tâches (changement de texte, etc)
Nous avons donc passé en revue les programmes qui pouvaient correspondre. Le plus proche a été Inkscape (mais qui a refusé de s'installer sur notre Macintosh) ou The Gimp (mais qui ne nous a pas permis de créer des textes qui restent éditables après rotation)
Nous étions donc résignés à développer une solution en ligne en interne (un formulaire couplé à une application Perl utilisant ImageMagick) mais nous hésitions, car passer du temps pour un programme jetable destiné à fabriquer un truc gratuit, ça nous gênait moins que le rein ci-dessus mais faut pas pousser hein.
Quand, tout à coup, nous avons eu une révélation, une vision, un flash.
Un programme qui satisfasse à tous les critères, nous en avions déjà un : Harmony Assistant !
Nous avons créé un document sans portée, y avons positionné les images en objet libre, puis les textes par-dessus, et le tour était joué. Et MyrScript nous permettrait même à l'avenir d'automatiser une partie du processus.
Nous étions déjà conscients qu'Harmony était une boîte à outils extrêmement polyvalente, mais n'avions pas songé l'utiliser comme logiciel de PAO.
Il ne reste plus qu'à prévoir des formules de calcul entre les divers objets, et on pourra s'en servir comme tableur ! 
Je vous laisse libre d'imaginer de quelle autre manière Harmony Assistant pourrait être détourné. Le premier qui sort un "space invaders" programmé en MyrScript gagnera l'assurance de notre respect éternel et, bien sûr, une carte cadeau.
Bon week-end ! |
|
|
| by Olivier Guillion | |
|
| |
|
Lorsqu'il est utilisé pour visualiser un didacticiel sur notre site, le plug-in pouvait crasher à la fin du jeu d'une musique d'exemple incluse dans le didacticiel en question (sur tous les OS).
Ceci a été corrigé, et nous mettrons une version beta du plug-in à disposition en même temps que la prochaine beta d'Harmony Assistant.
En attendant, tous les didacticiels peuvent être visualisés directement depuis le programme (Menu "Aide > Didacticiels"). |
|
|
| by Olivier Guillion | |
| |
|
PDFtoMusic (version Standard ou Pro) ne traite que les fichiers PDF directement issus d'un logiciel d'édition de partition. Les images scannées ne sont pas utilisables. C'est d'ailleurs cette limitation qui fait la force du programme, car la qualité de la reconnaissance dépasse alors celle des logiciels qui traitent de simples images.
Kooplet, lorsqu'il collecte les morceaux destinés à être indexés dans la base, ne sait pas à quel type de PDF il a affaire a priori.
Jusqu'alors, il procédait donc comme ceci :
Les fichiers PDF trouvés sur les sites par nos multiples"crawlers" étaient téléchargés par ces derniers, puis envoyés au programme central qui les stockait dans une base de données privée.
Un ou plusieurs exemplaires de PDFtoMusic qui tournent en permanence sur nos machines demandaient alors au programme central de leur fournir un fichier PDF afin qu'ils puissent le traiter.
Le résultat du traitement était alors renvoyé au programme central, qui l'ajoutait à la base de données publique si le PDF avait pu être traité.
Le problème est que les fichiers PDF contenant des pages scannées suivaient le processus jusqu'au bout, et n'étaient éliminés qu'à la fin, lors du traitement par PDFtoMusic. Etant donné qu'ils sont généralement assez volumineux, cela prenait pas mal de place, occupait de la bande passante sur le réseau et faisait souffrir la machine qui faisait tourner PDFtoMusic.
Nous avons donc mis en place un test rapide qui détecte ces fichiers PDF, dès la première étape, juste après leur téléchargement. Ils sont ainsi éliminés très rapidement, ce qui allège sensiblement la charge de travail du reste du processus.
La machine qui fait tourner PDFtoMusic travaille moins, donc elle chauffe moins, donc le ventilateur tourne moins vite, donc elle fait moins de bruit, donc nous pouvons mieux nous concentrer sur les "sujets plus importants" chers à tous nos amis grincheux. |
|
|
| by Olivier Guillion | |
|
| |
|
|
