Le Tracé des pages
Nous nous sommes tout d'abord attaqués à la partie censée poser le moins de problème: l'affichage graphique des partitions.
Avant de se décider sur une solution ou une autre, nous avons besoin de savoir ce qui est faisable, ce qui fonctionne, et sur quels navigateurs. Nous avons donc exploré plusieurs possibilités, en créant pour chacune une page Web de démonstration, nous permettant de savoir si les concepts tenaient la route.
I- Les polices
Le premier problème était celui des polices. Le logiciel embarque des polices musicales, et laisse le système se charger de leur affichage. Comment faire sur le Web?
Il nous faut utiliser le système des Webfonts, qui permet d'ajouter une police spécifique à une page Web. Le système n'est pas encore complètement standardisé, et demande de fournir les polices en question en plusieurs formats alternatif afin que chaque navigateur y trouve son compte.
Nous avons utilisé l'un des multiples services en ligne pour convertir ainsi toutes les polices incluses dans Harmony Assistant.
Démonstration des Webfonts
II- L'affichage des pages
Les pages devront être pré-calculées par le programme (ce qui empêchera les transpositions graphiques, à moins de stocker toutes les alternatives transposées).
Ces pages doivent ensuite être affichées dans le navigateur. On peut envisager leur stockage dans plusieurs formats:
A- Le format PNG
Il s'agit d'un format d'image non vectoriel, qui peut être affiché directement dans un navigateur. Pas besoin de page de démo ici; Harmony Assistant exporte directement à ce format, et ces images peuvent être affichées très facilement, n'importe où (c'est le format généralement utilisé pour les illustrations de ce blog).
Problème:
- Format d'image point à point, donc impossible de zoomer à volonté, à moins de stocker de très grands format
- Fichiers relativement gros (une centaine de Ko par page)
B- Le format PICT
C'est le format interne à Harmony Assistant, basé sur les spécifications du QuickDraw (Macintosh). Les tracés graphiques de la page sont, dans Harmony Assistant, collectés dans ce format, pour être ensuite imprimées ou converties dans un autre format graphique.
Il était donc naturel de chercher à afficher directement ce format, et d'écrire en Javascript un visualiseur de PICT.
C'est chose faite :
Démonstration d'affichage de PICT
C'est un format vectoriel (donc zoomable à l'infini).
Pas de problème particulier, si ce n'est que cela demande un code Javascript assez complexe (les technophiles pourront le consulter en regardant le code source de la page de démo). Cela a l'air assez rapide, et les données sont plutôt courtes (23 Ko compressées).
C- Le format SVG
C'est le format de dessin vectoriel conçu pour Internet. De mieux en mieux pris en compte par les différents navigateurs, il a l'avantage d'être pris en compte directement par ces derniers, ce qui est la garantie d'un affichage très rapide. Quelques problèmes de standardisation subsistent, notamment quant à l'usage de polices externes.
Nous avons écrit, dans Harmony Assistant, un export graphique SVG (en fait, un convertisseur PICT->SVG) qui inclut directement dans le fichier les tracés des caractères musicaux utilisés dans la page.
On obtient un fichier un peu plus long, mais qui au final se compresse mieux que le PICT (18Ko compressés pour la même page).
Démonstration d'affichage de SVG
Cela semble, à première vue, le format le plus pratique. Seuls quelques navigateurs très anciens (Safari sur iOS 6) rencontrent des problèmes d'affichage. Sur Internet Explorer, il y a des problèmes de débordement du cadre lors des zooms. Nous avons trouvé la solution sur Internet, mais ne l'avons pas encore essayée.
Le format SVG serait probablement celui que nous retiendrions. Dans tous les cas, l'export graphique SVG sera proposée dans la prochaine version d'Harmony. |
|
|
| by Olivier Guillion |  |
|
| |
|
Il y'a avait un gros problème dans la gestion des polices définies dans les préférences générales, c'est corrigé.
L'écriture d'un accord de type F7/9 (avec un slash dans le nom) dans la grille d'accord pouvait redonner F9 (son équivalent plus simple) lors de certains recalculs, c'est corrigé.
Nous avons commencé à mettre les ressources à plat dans les différentes langues.
|
|
|
| by Didier Guillion |  |
| |
|
Afin de savoir ce qu'il sera possible de faire (ou pas), nous avons analysé rapidement les solutions retenues par les autres éditeurs de musique.
De manière générale, on peut dire qu'ils ne sont pas nombreux à proposer quelque chose.
Le plus proche de ce que nous avions développé était le plug-in Scorch (Sibelius). Comme le nôtre, basé sur NPAPI, et comme le nôtre menacé de désuétude.
Ce plug-in serait apparemment remplacé à terme par une plateforme "Cloud" qui permettrait aux clients (moyennant finance?) de disposer d'un espace de stockage pour leurs partition, accessibles par le Web.
Leur système fonctionne apparemment comme ceci:
lorsqu'un fichier musical est envoyé sur le cloud d'Avid (l'éditeur de Sibelius), il est automatiquement converti en images de pages, et en MP3. Ce sont ces images qui sont présentées à l'écran dans le navigateur, et le MP3 qui est joué.
C'est également ce genre de solution qui a été retenue par MuseScore.
Avantage : pour l'utilisateur, cela correspond peu ou prou au MUSL, un espace dédié hébergé par l'éditeur. Les manipulations sont simples.
Problème: tous les documents musicaux présentés sur le Web doivent être hébergés sur les serveurs de l'éditeur, et dans un format assez gourmand en place (un MP3 est plus gros qu'un MYR). De plus, la conversion en images+MP3 doit être réalisé par le serveur, ce qui implique une consommation de CPU assez conséquente.
Jusqu'ici, avec notre plug-in, n'importe qui pouvait héberger les partitions sur son propre serveur, et les gérer à sa guise, sans contrainte de taille, de disponibilité d'un cloud externe, ou autre.
De nombreuses chorales, mais aussi des profs, de simple amateurs ne s'en sont d'ailleurs pas privés. Il y a environ 10000 partitions sur le MUSL, mais le nombre de partitions .MYR actuellement proposées sur l'ensemble du Web est difficilement quantifiable.
Avons-nous les ressources, le temps matériel, les capacités humaines et techniques pour gérer un tel système de cloud centralisé, même s'il devait être payant? Rien n'est moins sûr.
L'alternative à cela serait, comme nous l'avions prévu au départ, de proposer l'export vers le format de partitions Web directement depuis Harmony Assistant, et fournir les outils (sources Javascript) permettant à tout un chacun d'héberger ses musiques sur son propre serveur. MUSL utiliserait simplement le même système que celui proposé aux utilisateurs, comme c'est le cas actuellement avec le plug-in.
Nous nous interrogeons encore, et n'avons pas encore pris de décision définitive à ce sujet. |
|
|
| by Olivier Guillion | |
|
| |
|
En MyrScript les methodes Score.JumpToPage et Score.JumpToBar ont ete implémenté.
Correction dans l'édition des diagrammes d'accord.
Correction d'affichage de la grille d'accord.
Affichage d'une alerte quand on sauvegarde avec une ancienne version de format.
Mise en place d'un mode "maintenance" pour le serveur MUSL.
Implémentation des menus pour les nouvelles commandes de fusion et de récadrage des mesures et raccourcis clavier correspondants.
|
|
|
| by Didier Guillion | |
| |
|
Cela fait maintenant quelque temps que nous réfléchissons à la manière de continuer à proposer un plug-in permettant de visualiser sur une page Web les musiques réalisées avec nos programmes.
Le changement forcé de technologie que nous avons évoqué dans ce billet réduit drastiquement notre éventail de possibilités.
Voici le cheminement logique que nous avons été contraints de suivre.
- Avec l'abandon de NPAPI, aucune possibilité de développement nous permettant de réutiliser directement les codes sources d'Harmony/Melody (comme le faisait jusqu'ici le plug-in) n'existe. Ou en tout cas, aucun système de ce type n'est compatible avec suffisamment de navigateurs pour être réellement utilisable.(Cf Chrome PPAPI)
- Les convertisseurs automatiques (emScripten, ...) ne fonctionnent pas pour de gros projets, et demandent la mise en place sur le site d'un environnement assez lourd (grosses bibliothèques Javascript).
- Flash et son langage ActionScript ne fonctionnent pas sur nombre de plateformes, et est en train d'être éliminé petit à petit des navigateurs récents.
- Il ne reste guère que HTML5/Javascript, mais il nous faut alors réécrire intégralement le plug-in pour ce langage. Il est impensable de porter le code d'Harmony/Melody : Cela équivaudrait au bas mot à plusieurs mois de travail, pour un résultat pouvant s'avérer trop lent (n'oublions pas que Javascript est un langage interprété et pas compilé).
La seule solution réaliste serait donc d'écrire une app en HTML5/JS permettant d'effectuer au moins les opérations de base du plug-in : visualiser une partition et la jouer.
Pour des raisons de complexité du développement et de rapidité d'exécution, il n'est pas raisonnable de laisser cette app "comprendre" par elle-même la structure d'une partition pour la montrer ou la jouer : il faut absolument lui fournir des données pré-machées, aussi bien visuellement que musicalement, afin de la cantonner à des opérations de base. Et encore, même cela risque de s'avérer trop compliqué pour ce langage.
Ceci exclut donc que ce plugin/app charge directement de fichiers MYR, MIDI, ou MusicXML.
Il faut prévoir un format spécial d'export depuis Harmony, qui intègre de manière simple les données visuelles de la partition, les données sonores, et les liens entre les deux.
Ceci impliquera donc de convertir à ce format toutes les musiques du MUSL (cela pourra être réalisé automatiquement de notre coté), et toutes les personnes ayant utilisé notre plug-in sur leur site devront faire de même. |
|
|
| by Olivier Guillion | |
|
| |
|
La recherche des Titres, Compositeur, Remarques gère maintenant les pages de gardes. L'export de ces informations en MusicXML a été amélioré.
La gestion des textes multi-styles a été améliorée, de même que la constitution des blocs de textes.
Bon week-end ! |
|
|
| by Didier Guillion | |
| |
|
Dans Harmony Assistant, La fonction de recadrage des mesures aux durées écrites a été finalisée, avec l'ajout d'une option pour rendre visibles (ou laisser invisibles) les changements de signature temps.
La fonction qui indique les notes hors tessiture a été améliorée pour les instruments qui peuvent servir à noter plusieurs instruments de registres différents. Par exemple, le son de tuba peut être utilisé aussi bien pour un tuba baryton ou contrebasse.
Le logiciel va donc d'abord analyser les notes de la portée pour déterminer celui des deux instruments qui est le plus probable sur cette portée. Il indiquera ensuite les notes en dehors de l'étendue de cet instrument.
Sur PDFtoMusic, les bases de détermination de caractères alphanumériques ont été améliorées, pour prendre en compte notamment les fontes textuelles Swing proposées en complément de Finale.
Sur PDFtoMusic toujours, sur des portées couplées main droite/main gauche des problèmes de positionnement des changements de clé en milieu de mesure, ou de hauteur d'appoggiatures après ce changement, ont été corrigés. |
|
|
| by Olivier Guillion | |
| |
|
Nous cherchons une méthode permettant de déterminer automatiquement que l'encodage d'une police nécessite de la passer en reconnaissance optique de caractère. Ce n'est pas gagné... |
|
|
| by Didier Guillion | |
| |
|
Une nouvelle option va être ajoutée au menu "Edition > Mesures" : "Recadrer aux durées écrites".
Imaginons par exemple le cas où l'utilisateur a entré une partition avec une anacrouse, mais n'a pas inséré une mesure incomplète au début pour cela.
Il obtient ceci:
Ici, nous avons demandé de visualiser par une double flèche les silences fantômes, qui indiquent que la durée totale de la mesure n'a pas été remplie par les notes. Mais ceux-ci peuvent être invisibles.
Jusqu'ici, la méthode la plus simple pour corriger cela était d'insérer une mesure incomplète, de recopier les notes ou de les copier-coller, puis de supprimer la mesure d'origine.
La nouvelle option, en un clic, réduira la durée de la mesure demandée (en jouant sur la signature temps) de manière à ce qu'elle corresponde à la durée des notes écrites, éliminant ainsi les silences fantômes :
Nous avons eu par le passé le cas d'un utilisateur qui avait entré l'intégralité d'une pièce en 3/4 sur des mesures en 4/4. Il ne s'est inquiété du temps vide à la fin de chaque mesure lors du jeu que lorsque tout a été entré.
Récupérer cela sera désormais facile, il suffira d'appliquer l'option à l'intégralité des mesures.
|
|
|
| by Olivier Guillion | |
|
| |
|
Le script qui linéarise les partitions gère maintenant la grille d'accord.
Dans Melody Player correction d'un problème de click sur l'ascenseur de la liste.
Dans PDFtoMusic, amélioration de la recherche des tempi.
|
|
|
| by Didier Guillion | |
| |
|
Deux nouveautés dans MyrScript:
un membre "PlayedVelocity" a été ajouté à l'objet "Symbol". Il donne (en lecture seule) une estimation de la vélocité jouée de la note.
Estimation, car les nuances pouvant être conditionnelles, une même note peut être jouée plusieurs fois avec des vélocité différentes au gré des répétitions. Dans ce cas, la valeur retournée par PlayedVelocity devrait être la première, mais ce n'est pas garanti.
Une méthode Score.SetDisplayAtPage() a été ajoutée. Elle permet de se positionner graphiquement sur n'importe quelle page de la partition. Inutile de préciser qu'elle fonctionnera mieux en mode page qu'en mode ruban. Cela permet à un script de positionner la visualisation de la partition à n'importe quel endroit.
Sinon, nous avons passé une bonne partie de la journée à traquer un bug tenace dans PDFtoMusic, qui faisait générer un fichier MusicXML avec des durées de mesures improbables (plusieurs millions de temps). Le problème ne se produisait que sur un fichier de 60 pages et plus de 700 mesures, et uniquement sur Macintosh.
Après grosse et longue prise de tête, nous avons pu trouver et corriger le problème (dû à un accès à une zone mémoire non initialisée). Il était localisé dans une portion relativement récente du code, donc ne concernait pas la version publique.
Bon week-end à tous, et restez au chaud! |
|
|
| by Olivier Guillion | |
| |
|
Une étape non négligeable de PDFtoMusic est de reconstituer les mots à partir des caractères puis d'assembler les mots en blocs de textes. On obtient ainsi les textes associés à la partition. Certains de ces textes sont assignés au Titre, Compositeur et Remarque de l'oeuvre. En fait, l'algorithme de cette dernière étape est assez simpliste : ce qui est centré en haut de la première page est considéré comme le Titre et ainsi de suite.
Maintenant les différents blocs de texte sont matérialisés sur la partition et un click droit permet de changer leur affectation.
|
|
|
| by Didier Guillion | |
| |
|
Nous avons entamé la mise en place d'une nouvelle commande qui est plus complexe à mettre en place qu'elle n'en a l'air, mais qui devrait se révéler très utile:
Dans le menu "Edition > Mesures", après "Insérer mesures" et "Supprimer mesures", une nouvelle option "Fusionner mesure" permettra de mettre plusieurs mesures bout à bout dans une seule mesure plus grande.
En d'autre terme, cela fera disparaître physiquement les barres de mesures sur une zone.
|
|
|
| by Olivier Guillion | |
|
| |
|
Correction d'un problème quand la langue de l'interface n'était pas trouvée.
Dans certains cas les crescendi/decrescendi étaient mal reconnus et il arrivait que l'on confonde les deux types, à cause de cela nous avons effectué une
refonte complète de la localisation et du traitement des crescendi/decrescendi.
Dans Harmony, les raccourcis clavier de changement de mode d'édition ne mettaient pas à jour les icônes correspondantes dans la palette utilisateur, c'est corrigé. |
|
|
| by Didier Guillion | |
|
| |
|
I- L'abandon
Cela a commencé il y a quelques années, et s'accélère ces derniers mois. Un à un, les navigateurs abandonnent le système de plug-in historique, appelé NPAPI et supporté depuis 1995.
Après Chrome en 2015 ou Edge qui, lui, commet l'exploit d'abandonner son système propriétaire appelé ActiveX (mais qui permettait, moyennant astuce, de faire tourner les plug-ins NPAPI sur Internet Explorer), c'est maintenant au tour de Firefox, le dernier "gros" restant, d'annoncer l'abandon complet de NPAPI d'ici fin 2016. Cela est d'ores et déjà le cas pour les versions 64 bits de Firefox.
Là où ça commence à devenir rigolo, c'est qu'après les justifications de cet abandon, sur lesquelles nous ne reviendront pas (mais on vous assure que c'est pour votre bien), aucune solution de remplacement équivalente n'est proposée
II- Ce qu'on perd
Le système NPAPI permettait en effet de faire tourner assez simplement du code machine, issu de n'importe quel type de projet natif (C, C++, etc) sur quasiment n'importe quel navigateur.
D'accord, une version différente du plug-in devait être réalisée pour chaque système : une sur Windows, une autre sur MacOS et une troisième sur Linux.
Mais pour un développeur qui possédait déjà une application, comme c'est le cas pour nous, son code source pouvait être entièrement réutilisé, et de toute façon, ce code source devait déjà pouvoir générer des applications pour les 3 plateformes.
Développer un plug-in à partir d'une application existante était donc relativement simple.
Mais tout ceci semble terminé. Aucune alternative n'est proposée. Google semble proposer un système équivalent, qu'il a appelé Native Client (ou Pepper, PPAPI), mais qui a l'inconvénient de ne fonctionner que sous Chrome.
Tous les autres systèmes disponibles sont ainsi spécifiques à un navigateur, et/ou nécessitent la réécriture entière de l'application dans un autre langage. Pour un développeur, cela revient à réécrire l'intégralité de son application, et plusieurs fois s'il veut que son app fonctionne sur différents navigateurs.
III- Des pistes prometteuses ?
Sentant le vent tourner depuis plusieurs mois déjà, nous avons commencé à chercher des échappatoires :
- Compatibles avec un maximum de navigateurs
- Permettant de réutiliser au maximum nos codes source C existants.
C'est ainsi que nous avons essayé EmScripten, qui sur le papier, permet, à partir d'un code source en C, de générer une app en HTML5 + Javascript, donc compatible entre les différents navigateurs, et, cerise sur le gateau, multi-plateforme (donc une seule et unique version du plug-in).
Malheureusement, cela ne semble fonctionner réellement que sur le papier. Rapidement, le système atteint à ses limites en terme de complexité du projet et de fiabilité du résultat, et à la base, le HTML 5 n'est pas encore suffisamment normalisé, surtout au niveau de la gestion sonore, pour être réellement considéré comme compatible entre les divers navigateurs et plateformes.
IV- Et donc ?
Nous en sommes là. Pour l'instant, nous n'avons pas trouvé de solution de remplacement à notre plug-in NPAPI actuel. Rappelons que même s'il peut faire s'intéresser certains internautes à nos autres produits, il s'agit d'un freeware (gratuiciel) qui ne doit pas occuper notre petite équipe trop longtemps. Une réécriture complète de l'application est donc inenvisageable, et pour l'instant aucun système récent ne semble convenir à nos exigences. |
|
|
| by Olivier Guillion | |
|
| |
|
L'affichage du numéro de mesure tient maintenant compte des multi-silences.
Nouvelle commande pour rechercher la page contenant une mesure donnée et montrer la mesure dans cette page.
Intégration du nouveau vérificateur de ressources et générateur de lexique dans PDFtoMusic.
|
|
|
| by Didier Guillion | |
| |
|
Il y a quelque temps, un utilisateur nous avait contacté pour un problème d'installation de la police musicale Stoccata sur Windows 10 (voir ici).
Nous avions cherché, puis trouvé la solution, nous étions étonné de la bizarrerie de celle-ci, puis nous l'avions oubliée.
Voila qu'une autre personne rencontre le même problème. Ce n'est qu'après plusieurs échanges de courrier qu'il trouve par lui-même la solution, que nous aurions pu lui indiquer si notre mémoire avait été plus fiable.
Alors, la voici, pour aider les autres dans le même cas, et pas seulement pour nos logiciels. Attention, accrochez-vous aux branches, c'est du lourd !
Les symptômes sont les suivants : lorsque l'utilisateur essaie d'installer une nouvelle police de caractères (soit en la faisant glisser dans le dossier "Windows\Fonts", soit par clic droit - Installer), ou même essaie de visualiser un aperçu de celle-ci, il obtient le message
Le fichier Stoccata.ttf ne semble pas être une police valide
Cela se produit avec n'importe quel fichier de police, ce n'est donc pas lié spécifiquement à la Stoccata.
Que faire pour y remédier ? Roulements de tambour...
Réactiver le pare-feu ! 
Vous avez bien lu, les polices de caractères ne peuvent être installées sur Windows 10 que si le pare-feu, cette protection contre les actions malveillantes sur le réseau, est activé.
Pourquoi, et quel rapport ? La réponse est simple, personne ne sait. Les gars de chez Microsoft restent muets sur le sujet.
Peut-être l'ont-il d'ailleurs déjà corrigé en loucedé dans une mise à jour, puisque nous n'arrivons plus aujourd'hui à reproduire cette erreur, alors que nous y parvenions il y a encore quelques mois.
À tester, pour le fun... Désactivez le pare-feu et essayez d'installer une police. |
|
|
| by Olivier Guillion | |
| |
|
Nouvelles options de correction permettant d'ignorer les changements de tempi ou les nuances.
Correction de l'affichage du numéro de mesure en mode ruban. Cela survenait dans les passages où la première portées était cachée.
Correction d'un problème d'ascenseur en mode ruban.
Nous envisageons de proposer une bêta prochainement. |
|
|
| by Didier Guillion | |
| |
|
Pour démarrer la nouvelle année, nous nous sommes attaqués à la mise à jour de l'installateur de la base de sons GOLD en téléchargement, version Windows.
Cet installateur datait de 2008, et n'était pas signé numériquement. Sous Windows 8 et 10, son lancement après téléchargement faisait apparaître un blocage pour des raisons de sécurité.
Le bandeau bleu, assez anxiogène, barrait tout l'écran, et pour passer outre, il fallait cliquer sur "Plus d'information" et ainsi obtenir un bouton pour exécuter le programme en dépit des avertissements.
Nous avons donc recompacté tous les sons de la base, et recréé une archive en utilisant les dernières versions de l'installateur, et notre signature numérique.
C'est terminé et testé, nous sommes en train de l'envoyer sur notre site. Mais plus de 400 Mo, avec une liaison montante ADSL à 300 ko/s, ça prend un peu de temps.
Vivement la fibre !
|
|
|
| by Olivier Guillion | |
| |
|
| by Didier Guillion | |
|
| |
|
|
