Lors de l'import MusicXML, si une note était liée à plus d'un coulé, la tige de la note pouvait disparaître (ici, une blanche double-pointée): Cela a été corrigé : Un utilisateur nous a signalé que l'espacement automatique des notes lors de l'entrée de paroles ne fonctionnait pas toujours. Lors de l'entrée de paroles sur des notes proches, on obtenait quelque chose comme : L'analyse a montré plusieurs dysfonctionnements: - L'option "Formatage automatique des paroles", qui permettait un espacement automatique lors de la frappe, est désactivé par défaut dans plusieurs modèles de document. Il nous faudra traiter tous les modèles et activer cette option - En mode gravure, l'espacement en question est géré par l'algorithme du mode. L'option "Formatage automatique des paroles" ne devrait plus être sélectionnable, et activé automatiquement lorsque le mode gravure est en cours. Lors de la frappe, on obtient alors: ce qui est nettement plus satisfaisant. |
|
|
by Olivier Guillion | | |
| |
|
Le format Myrweb est maintenant entièrement défini. Il permet de stocker l'ensemble des informations musicales et graphiques dont l'app a besoin et même largement plus. Nous avons aujourd'hui entièrement relu le contenu du format pour le rendre le plus propre possible, en éliminant les informations inutiles, en nommant les champs de manière claire, en utilisant des unités cohérentes, etc. Pour être certains de nous y retrouver, nous avons rédigé une documentation technique décrivant le format, et deux "parsers", l'un en C dans Harmony et l'autre en Javascript sur une page Web, permettant de décomposer à l'écran le contenu exhaustif de n'importe quel fichier Myrweb. Nous nous interrogeons sur l'opportunité de publier la description de ce format et de le rendre libre, permettant à quiconque de l'utiliser à sa guise. Des opinions divergentes à ce sujet se font entendre au sein de notre petite équipe, mais il est quasi certain que ce ne sera pas fait, au moins dans un premier temps, afin de nous permettre de modifier facilement le format si nous nous apercevions d'un manque. Voici la liste non exhaustive des "pour" et des "contre" Pour un format Myrweb public et libre En tant que créateurs et mainteneurs du format, nous garderions un avantage stratégique, nos applications étant toujours 100% compatibles avec la dernière version. Le format myrweb pourrait amener plus de musiciens à s'intéresser à nos produits, qui pourraient les choisir de manière à être certains de la compatibilité des exports (ou de la correction rapide des erreurs) C'est toujours sympa de faire profiter une communauté de ce qu'on fait C'est ce que fait Finale avec le MusicXML, et comme ce ne sont pas des mécènes, ils doivent bien y trouver un avantage financier Contre un format Myrweb public et libre Même s'il n'y a aucun engagement formel, un format libre nous contraindrait à assurer une assistance technique sur ce format, et fédérer les demandes d'évolutions, émanant de personnes non clientes chez nous. Si nous désirions modifier ou adapter le format, un format libre serait plus contraignant, nous devrions gérer des versionnements, publier les modifications, etc. et surtout : Une diffusion libre donnerait la possibilité à n'importe quel logiciel de musique d'exporter en Myrweb pour visualiser ses partitions en ligne, en utilisant notre app gratuite. La gratuité, c'est bien, et nous pensons que l'app peut amener des personnes à s'intéresser à nos logiciels. Mais offrir tout notre travail sur un plateau à nos concurrents directs, ce serait un peu fort de café. Bon, il y a peut-être d'autres possibilités de droits de diffusion, par exemple libre et gratuit pour un usage personnel, académique, ou freeware/open source, mais avec une redevance ou une licence pour une utilisation commerciale. Mais pour les 10 développeurs potentiellement intéressés, est-ce que cela vaut la peine de s'embêter ? La question n'est pas réthorique, il faudra nous la poser sérieusement un jour, dès que nous aurons un peu de temps ... libre. |
|
|
by Olivier Guillion | | |
| |
|
Parmi les fonctionnalités les plus utiles de l'ancien plug-in, on trouvait la modification du tempo, et la transposition. L'altération du tempo était le plus souvent utilisée pour ralentir la musique et s'entraîner à vitesse réduite, avant de l'augmenter peu à peu. La transposition était utilisée, elle, soit par les chanteurs, pour ramener la partie chant à une tessiture plus confortable, soit par des instrumentistes, pour jouer dans une clé plus facile, ou plus adaptée. En MIDI ou en MYR, transposer ou changer le tempo est très facile. Les notes étant stockées en tant que telles, il suffit d'augmenter leur durée, ou d'ajouter ou retrancher un certain nombre de demi-tons à leur hauteur. En format audionumérique, c'est une autre paire de manches. Cela demande des calculs mathématiques très lourds, incluant des décomposition en série de Fourier, des calculs sur le spectre des fréquences, et une resynthèse du son. Le Javascript n'est pas un foudre de guerre, aussi nous craignions que ces calculs ne soient bien trop long pour être envisageables. En fait, il n'en est rien. Nous avons préparé une petite démo pour vous montrer: Démo de transposition/tempo Bien entendu, la vitesse du langage, et la lourdeur des calculs ne nous permet pas de faire dans la dentelle. Pas question de hi-fi, ici. Pour réduire les calculs, on ne traite que du mono, et on entend nettement les défauts inhérents au système: un affaiblissement de la dynamique, des attaques moins franches, un chevrotement des fréquences basses lorsque le tempo est fortement réduit, et un effet général d'écho du type "salle de bain". Mais l'idée n'est pas ici de faire quelque chose de parfait, seulement de produire un son écoutable et pas trop désagréable. Il est à noter que la vitesse de calcul varie très fortement d'un navigateur à l'autre, du simple au double, selon l'optimisation du moteur Javascript dans le traitement des 'tableaux typés', qui permettent d'effectuer des calculs intensifs sur des zones mémoire brutes. Firefox remporte ce match haut la main, très loin devant Chrome ou Safari. |
|
|
by Olivier Guillion | | |
| |
|
Alors que le format de fichier "MyrWeb" évolue pour y intégrer la totalité des données dont nous avons besoin, l'app qui présente et joue les partitions se complète petit à petit. Elle est loin d'être entièrement fonctionnelle, mais est maintenant presque présentable. Des fonctionnalités sont encore absentes, d'autres ne fonctionnent pas comme prévu, ou ne fonctionnent pas sur certaines plateformes, mais l'essentiel est là. Démo de l'app Myrweb v-1.-1.-1 C'est une version pré-pré-alpha, une bande-annonce en quelque sorte. Dans Harmony Assistant, lors de la génération d'un fichier Myrweb à partir d'une partition, un bouton "Aperçu" permet de voir ce que donnera cette partition une fois publiée sur Internet. Pour ce faire, Harmony crée une page totalement autonome, qui intègre à la fois la dernière version de l'app (telle qu'elle était à l'instant de la génération), ainsi que les données graphiques et sonores de la partition. Ainsi, il serait possible par exemple d'envoyer ce genre de pages par e-mail, même si elles sont un peu volumineuses, pour que le correspondant à l'autre bout puisse ensuite jouer et visualiser une partition, même hors-ligne, sans rien avoir à installer, et sans risque qu'un fichier ou une image soit manquante. Sur ces considérations, bon week-end ! |
|
|
by Olivier Guillion | | |
| |
|
Les incompatibilités entre navigateurs, conjuguées avec le bricolage duquel est issu le format MP3, nous obligent à improviser un numéro de jongleur contorsionniste. Voici l'état de l'art en la matière : Le format MP3 La base de ce format est solide et claire, mais les manques ont été comblés de bric et de broc, créant toute une série de "standards" de facto Par exemple: A l'origine, les fichiers MP3 étaient en "Constant Bit Rate" (CBR) : chaque petit bout de son (trame) était compressé de la même façon, quel que soit son contenu. Une seconde de silence occupait la même place qu'une seconde de son d'un orchestre symphonique. Puis est apparu le "Variable Bit Rate" (VBR) : la trame est plus ou moins compressée selon son contenu, de manière à maximiser la qualité globale de la compression. Problème: en CBR, il est facile de savoir où est située la 100e seconde d'un morceau. On connait la durée de chaque trame, et sa longueur en octets. Il suffit de multiplier. En VBR, c'est impossible, les trames ayant des longueurs variables, il faudrait tout balayer depuis le début. De même, il n'est pas possible de prévoir la durée du morceau avant de le jouer en se basant sur la taille du fichier. Alors, une tentative de "standard" bricolé de table de correspondance entre position en seconde et position dans le fichier a été créée. Ca améliore les choses, mais ne les résout pas vraiment. Il y a encore une imprécision importante entre la position estimée et la position véritable dans la musique. Web Audio et <audio> en HTML5 - en HTML 5, le Web Audio permet de jouer de charger des extraits sonores en divers formats, les décoder, les modifier (ou en créer à partir de rien), puis les jouer en totalité ou en partie. En gros, tout est possible, sauf le changement de tempo, qui doit alors être réalisé en Javascript, par des opérations mathématiques très (trop ?) complexes. Le Web Audio n'est pas géré par certains navigateurs sur Windows (IE 10 et 11) ou certains terminaux mobiles. - Dans ce cas, il est la plupart du temps possible d'utiliser à la place le tag HTML5 <audio> destiné à jouer un fichier audio complet. Par une astuce permettant d'inclure les données audio dans les données de la page Web, il n'est pas obligatoire que les données audio soient dans un fichier à part, ce qui nous permet de les extraire du fichier Myrweb. Mais : les formats de fichier gérés par le tag <audio> dépendent du navigateur. Seul le format MP3 semble être géré par à peu près tous, heureusement. Cette solution est bien moins souple que le Web Audio, on ne peut pas gérer la position stéréo de chaque piste, ou créer des sons de toute pièce pour superposer les sons de métronome à la musique. Par contre, curieusement, il est possible de changer facilement le tempo de la musique jouée. Les combinaisons On en arrive donc à cela : - En Web Audio, avec des données MP3 CBR ou VBR, on peut jouer tout ou partie, pauser, reprendre, changer le volume et la position stéréo de chaque piste, et superposer les sons de métronome, mais pas changer le tempo - Lorsque le Web Audio n'est pas disponible, avec le tag <audio>: . avec des données MP3 CBR, on peut jouer tout ou partie, pauser, reprendre, changer le volume et changer le tempo, mais pas changer la position stéréo des pistes ni superposer les sons de métronome . avec des données MP3 VBR, on peut jouer depuis le début, changer le volume et changer le tempo, mais ni jouer une partie, ni pauser ou reprendre, ni changer la position stéréo des pistes, ni superposer les sons de métronome. Ca ne va pas être évident à expliquer à l'utilisateur lambda, même avec une doc hyper bien fichue... |
|
|
by Olivier Guillion | | | |
|
Nous avons travaillé sur la partie "rendu sonore" de l'app, et y avons intégré quelques fonctions que nous avions préparées et mises au point à part. Le but est maintenant non pas d'obtenir une app diffusable et entièrement finalisée, mais d'avoir suffisamment de fonctionnalités mises en place pour pouvoir vérifier que le format de fichier myrweb contient tout ce dont nous avons besoin. L'app gère donc maintenant le métronome (en Web Audio, donc pas sur IE), la visualisation de la position de jeu, soit en mesure entière, soit sous forme d'une barre fine, le clavier virtuel avec choix des portées à montrer et de l'octave médian, le jeu de la musique, la pause, le redémarrage, l'avance et le retour rapide et le volume général. Sont implémentés, mais pas encore interfacés: la gestion de la barre de position en temps, le jeu d'une sélection, le bouclage infini sur ce passage, le volume et la position stéréo de chaque piste. Ne sont pas implémentés pour l'instant : la modification du tempo de jeu, et la transposition. Il n'y a en fait aucune méthode standard pour faire cela en WebAudio, alors qu'une modification de tempo existe en tag <audio>. Malgré les tentatives de justification des équipes de Google, c'est assez inexplicable. Pour réaliser cela malgré tout, il faudrait que nous intégrions à l'app un module de traitement audionumérique (FFT/IFFT, etc) qui, en Javascript, risque de s'avérer trop lent pour être utilisable. Même si la vitesse est suffisante, cela représente un assez gros boulot, qui n'est pas prioritaire. Ces fonctionnalités ne seront donc probablement pas implémentées dans les premières version publiques de notre app, si elles le sont un jour. |
|
|
by Olivier Guillion | | |
| |
|
Pour créer les données graphiques d'une partition destinée à être présentée sur le Web (fichier MyrWeb), l'application doit : - Convertir graphiquement les pages de la partition au format SVG - Calculer l'aire de chaque mesure sur ces exports graphiques Le premier a nécessité l'écriture d'un convertisseur SVG, qui est maintenant quasiment terminé, il ne manque plus que la gestion des images (objets libres) que l'utilisateur peut avoir incrusté sur son document. Pour le deuxième, nous avons un peu galéré, il faut l'avouer. Les calculs d'échelle de page, de dpi d'impression, de zoom, de justification automatique, etc, sont une des parties les plus complexes du logiciel, et nous avons passé une journée entière à trouver les bons calculs, qui font correspondre exactement l'aire de la mesure à son graphisme exporté. Mais nous avions commis une erreur : le SVG était exporté sur une aire de page A4, alors que l'utilisateur peut imposer une taille de papier quelconque. Nous avons donc repris l'export SVG pour en tenir compte. Ceci est utilisé par exemple dans la documentation, ou nous présentons une seule ligne de portée, en créant un document de 20 cm de large sur 2cm de haut. On peut donc maintenant, avec l'app, obtenir quelque chose comme (ici grandeur nature): Seul problème: ceci a modifié les positionnements et tailles de page, et nos calculs d'aire de mesure, que nous avions eu tant de mal à ajuster, ne fonctionnent plus, il faut tout reprendre Nous espérons seulement ne pas avoir à y consacrer une autre journée. |
|
|
by Olivier Guillion | | |
| |
|
Quelques modifications d'aspect ou ajustements de style, et le visualiseur de didacticiels est passé en version beta-2. Les pages de présentation des listes ont été reprises, pour supprimer les références au plug-in, qui n'est donc plus nécessaire ici. La gestion des clics sur les différents titres pour ouvrir le didacticiel correspondant a également été reprise. L'option de téléchargement et sauvegarde du fichier du didacticiel (.myt), inutile, a été supprimée. Le son de la barre d'espace, qui jouait à tort un bruit de double-clic, a été corrigé. Enfin, le jeu de musiques depuis le didacticiel en ligne a été amélioré, avec une mise en pause lorsque cet outil est cliqué, et un petit délai avant le démarrage, pour laisser le temps à l'effet sonore (généralement, bruit de la barre d'espace) de se jouer. Sur Harmony Assistant, version publique courante, nous avont testé le téléchargement et le jeu de didacticiels au nouveau format, afin de nous assurer que tout continue à fonctionner. C'est bien le cas. Le jeu des didacticiels est maintenant suffisamment fonctionnel pour que nous puissions le laisser ainsi pendant un petit moment. Nous allons donc nous remettre à l'app de visualisation et jeu des partitions. Bon week-end ! |
|
|
by Olivier Guillion | | |
| |
|
Nous avons corrigé les dernières erreurs les plus visibles dans l'app "didacticiels". Ensuite, nous avons mis en place le système qui délivre le code Javascript à la demande. Ce système permettra de limiter à presque rien l'empreinte de notre app sur les pages Web qui l'utilisent. Ainsi, même si notre code Javascript a été écrit en de nombreux modules, dans la page Web, il n'y aura qu'une seule ligne pour télécharger et activer ce code. Nous avons ensuite repris les pages de notre site qui montrent l'arborescence des didacticiels, afin de leur faire utiliser la nouvelle syntaxe d'appel. Nous sommes en train de tester ça sur notre intranet, avant de mettre tout ça publiquement en ligne. Si aucun lézard n'est déniché au dernier moment, ça devrait être disponible sous quelques heures. De toutes façons, on se dit que même si ça ne fonctionne pas tout à fait correctement, cela ne devrait pas être pire que l'incompatibilité croissante de l'ancien plug-in. Ce sera donc testable bientôt ici: Didacticiels |
|
|
by Olivier Guillion | | |
| |
|
Le nouveau système d'app destiné à remplacer notre plug-in ne nous permet plus de jouer des musiques au format MYR (ou tout autre format de partition, d'ailleurs). Si cela avait été possible, nous aurions déjà terminé le travail. Dans nos didacticiels, il arrive qu'une musique soit jouée pour permettre à l'utilisateur d'entendre le résultat des opérations décrites. Jusqu'ici, cette musique était intégrée au didacticiel au format MYR. Il nous a donc fallu étendre le format des fichiers de didacticiels, pour permettre de stocker, en plus du MYR, le résultat sonore au format MP3. Le format de fichier était heureusement assez bien conçu, et les nouveaux fichiers contenant des données MP3 pourront être visualisés avec les anciennes versions d'Harmony/Melody, ou avec l'ancien plug-in pour ceux qui parviennent encore à le faire fonctionner. Nous avons ensuite repris l'app pour lui faire jouer l'audio sur tous les navigateurs qui supportent le format MP3 ainsi que le jeu de l'audio en mode "inline data". Pour les autres, ce sera muet. Enfin, nous avons lancé un traitement par lot qui a chargé un à un les 273 didacticiels existants (excusez-moi du peu) et leur a adjoint les MP3 lorsque c'était nécessaire. Nous sommes les seuls à utiliser ce système de didacticiels, aussi nous pouvons nous permettre de mettre en ligne une version, puis de modifier à nouveau toutes les pages si nous faisons évoluer l'app. Pour la partie "visualiseur de partition", c'est plus délicat, car de nombreuses personnes utilisent le plug-in sur leur site, et nous ne pouvons pas les contraindre à reprendre plusieurs fois leurs pages. C'est pourquoi la première app à être utilisée en vraie grandeur sur le site sera ce visualiseur de didacticiels. Et c'est aussi pourquoi, vu la proximité de la mise en ligne de la version définitive, il n'est pas nécessaire de vous en proposer une démo aujourd'hui. |
|
|
by Olivier Guillion | | |
| |
|
|