La copie complète du serveur MUSL sur notre machine locale est terminée. Ce nouveau serveur, hébergé ici, servira donc de bac à sable pour les tests des versions beta.
Nous avons vérifié qu'il fonctionne bien, et qu'il n'y a plus de mixage avec le serveur MUSL public (certains liens menaient encore vers la version publique).
Nous avons pu alors continuer à mettre au point la conversion automatique de l'ancien format de partitions en lignes vers le nouveau. Cela fonctionne, mais les commentaires des utilisateurs sur chaque morceau sont alors perdus. Une fois ce détail réglé, nous pourrons nous attaquer à de nouvelles options induites par le nouveau format.
|
|
|
| by Olivier Guillion |  |
| |
|
Notre compilateur sous XCode a été configuré en mode "sensible" et nous sommes en train d'analyser et de corriger chacun des points qu'il soupçonne d'être une erreur. Parfois ils s'agit simplement de réécrire une ligne qui pouvait prêter à confusion mais dans de nombreux cas, il s'agit manifestement d'un problème. Cela fait tout de même plus de 2000 points à analyser à la main. |
|
|
| by Didier Guillion |  |
| |
|
Dans la prochaine version beta, nous voulons permettre aux testeurs d'essayer la procédure de conversion de leur espace MUSL vers les nouveaux formats de fichiers en ligne.
Mais nous voulons à tout prix préserver leur espace d'origine, pour éviter que s'il y a un grain de sable dans les rouages, ils ne se retrouvent pas avec un espace Web à moitié fonctionnel.
Il faut donc que la version beta travaille sur une copie du MUSL. Cela nécessite de recopier les quelques gigaoctets de données sur un serveur à part, de permettre d'y travailler comme s'il s'agissait du serveur public, et d'en vérifier les résultats.
Après mûre réflexion, nous avons opté pour une copie hébergée directement ici, dans nos bureaux. Les avantages sont multiples:
La place n'est pas un souci (on a de gros disques dur)
Il nous est facile de recopier l'intégralité du MUSL pour tout remettre au propre, puisqu'il s'agit alors de copies de fichiers en local, beaucoup plus rapide qu'un upload
Nous avons plus de contrôle sur ce qui se passe
La mise à jour des scripts et des données est instantanée, puisque le serveur utilise directement les fichiers et les scripts en cours de développement
Il y a cependant aussi quelques inconvénients qu'il faudra prendre en compte:
Notre accès Internet ADSL n'est pas un gros tuyau de datacenter. Si beaucoup d'utilisateurs transfèrent leurs fichiers en même temps, ce ne sera pas rapide, et ça réduira le débit de nos accès Internet, ici.
Le serveur est localisé sur une machine toujours allumée, mais moins fiable et moins tolérante aux pannes qu'un serveur dédié
Lorsque nous travaillerons sur les scripts, il se peut qu'ils se trouvent momentanément dans un état instable, empêchant les utilisateurs d'y accéder correctement. Il nous faut trouver une procédure pour éviter au maximum ces désagréments.
Il est cependant à noter qu'il s'agit d'une première, jamais auparavant nous n'avions mis en place un accès Web public vers une de nos machines locales. Si la fibre free était arrivée jusqu'à nous, cela aurait peut-être été fait depuis longtemps... |
|
|
| by Olivier Guillion | |
| |
|
Gestion de l'évitement de la palette style sur des multi-écrans.
Localisation des méthodes MyrScript non réflexives (par exemple orthographiées différemment en lecture et en écriture) ou non classées (par exemple définies hors d'une section) et correction.
Amélioration de la rapidité de l'export MyrWeb et gestion de la qualité d'export.
|
|
|
| by Didier Guillion | |
| |
|
Pour rendre la gestion des espaces utilisateurs beaucoup plus souple, nous avons écrit un module en Perl qui permet au serveur principal du MUSL de communiquer avec des serveurs secondaires, et d'échanger des fichiers.
Ceci va nous permettre de répartir sur plusieurs sites les fichiers de données, qui peuvent être très volumineux. Cette répartition nous permettra :
- d'offrir par défaut aux utilisateurs un espace plus confortable pour loger leurs partitions
- d'augmenter plus facilement l'espace total disponible lorsque cela devient nécessaire, par l'adjonction de nouveaux serveurs
Mais la mise au point de tout cela s'avère difficile, car les opérations de gestion du MUSL étaient déjà assez compliquées, et, étant intimement liées à Harmony, ne peuvent pas être testées en dehors du programme. Mais on avance...
Bon week-end ! |
|
|
| by Olivier Guillion | |
|
| |
|
Nous avons finalisé l'intégration du format MyrWeb aux espaces Utilisateurs. Ceci a été validé sur le dossier des démos qui représente près de 3000 fichiers classés et créé un site web complet présentant ces fichiers.
Au passage des corrections ont été appliquées aux barres de progression, accès internet, etc.
Les chaines de caractères qui étaient en "dur" ont été passé en ressources.
|
|
|
| by Didier Guillion | |
| |
|
Correction de l'export SVG/Myrweb de petites images noir et blanc
Correction de la gestion de la palette "Altérations", en palette individuelle et dans le Dock
Correction d'un crash du dock lorsque le dernier document était fermé
Enfin, autre registre, la base GOLD s'installait difficilement lorsqu'elle était téléchargée avec Edge depuis Windows 10. Ce dernier semble extrèmement sensible à la moindre irrégularité dans les signatures électroniques. La base GOLD a donc été re-signée, et la nouvelle version a été mise à disposition. |
|
|
| by Olivier Guillion | |
| |
|
Correction d'un problème d'affichage du pointé sur la note à poser.
Meilleure gestion du multi-écran sur Macos : les fenêtres filles respectent l'écran de la fenêtre mère.
Dans l'export MyrWeb, traitement du cas où la musique avait une durée nulle.
Mise en place de la configuration MyrWeb dans la gestion du MUSL.
|
|
|
| by Didier Guillion | |
| |
|
Le traitement des fichiers du MUSL est enfin arrivé au bout à 18h43 ce jour. Il nous reste une dizaine de fichiers "exotiques" à valider individuellement.
Nous avons donc un site web généré pour plus de six semaines ininterrompue de musique et près de 14 000 fichiers validés !
Yes !
|
|
|
| by Didier Guillion | |
| |
|
Dans l'export SVG et Myrweb, des irrégularités ont été détectées dans la gestion de certaines images. Un problème ainsi repéré sur les images en couleurs directes 15/16 bits (5 bits par composante) nous a fait remarquer que ces images n'étaient pas affichées, à l'écran, avec les bonnes couleurs sur Windows et Linux. Le problème date probablement des origines de notre librairie de compatibilité "ACAM", dans les années 90-91. Preuve que ce format d'image n'est pas si courant !
Les instruments utilisateurs de certains très vieux fichiers refusaient de se charger. Un contournement nous permet maintenant de les lire sans crash, mais leurs données semblent abîmées, dans les premiers dixièmes de seconde. Nous ne savons pas si les données sont réellement abîmées ou si nous les lisons mal, et nous ne savons pas non plus combien de fichiers sont ainsi affectés. |
|
|
| by Olivier Guillion | |
| |
|
La prévisualisation des notes collées dans l'album était défectueuse, c'est corrigé.
L'unification du format MyrWeb a été appliqué à PDFtoMusic Pro.
Chacun des fichiers de données nécessaires à PDFtoMusic peuvent maintenant être substitué par une nouvelle version téléchargée sans avoir à réinstaller l'application.
Les tablatures pour instrument de plus de 6 cordes (Luth par exemple) faisait planter l'export MusicXML, c'est corrigé.
Le MUSL s'exporte maintenant jusqu'à la lettre D.
Bon week -end ! |
|
|
| by Didier Guillion | |
|
| |
|
Nous avons beaucoup réfléchi à la manière la plus simple de présenter le format Myrweb, qui permet de proposer des partitions visibles dans un navigateur Internet. Ces réflexions nous ont amené à quelques changements d'optique.
Comment ça marche ?
Techniquement, la partition est exportée sous forme d'un bloc binaire (métafichier) contenant toutes les informations nécessaire à son affichage et à son jeu. Nous avions baptisé ce format binaire "myrweb"
Pour lire ces informations et les traduire en une page de musique à l'écran, ou faire entendre l'audio depuis un navigateur Internet, on a besoin d'une app, écrite en Javascript, qui ne nécessite pas que l'utilisateur installe un quelconque programme ou plug-in sur son ordinateur.
On a alors deux possibilités:
- Soit les données des partitions sont stockées à part, et on a alors d'un coté des pages Web, contenant les textes explicatifs et autres habillage, et de l'autre les fichiers de données, un par partition. La page Web, lorsqu'elle est visualisée, lit alors les données de la partition et les présent à l'écran ou les joue
- Soit les données binaires des partitions sont stockées à l'intérieur de la page Web elle-même. On obtient alors un fichier totalement autonome. Un double-clic dessus ouvre un navigateur et montre la partition jouable. Ce fichier peut facilement être transmis par mail, sur une clé USB, etc.
Ce que nous avions prévu de faire
Nous comptions donc proposer à l'utilisateur deux exports de partition:
- Un export du bloc binaire Myrweb, qui nécessitait ensuite d'être chargé par une page Web distincte pour être visualisé
- Un export de la page Web autonome, contenant les données Myrweb, et destinée à être échangée, transmise par mail, etc
Mais les deux notions étaient un peu trop complexes, difficiles à expliquer, et l'export binaire n'était utile qu'aux Webmasters.
Ce que nous allons faire à la place
Un seul format d'export sera disponible, le format en page Web autonome. Les fichiers de ce format porteront l'extension .myrweb.html et seront double-cliquables pour être visualisées dans un navigateur, sans rien nécessiter de plus.
C'est ce format qui prendra, dans Harmony Assistant, le nom d'export "myrweb"
L'export sous forme de bloc binaire disparaîtra, et ne sera plus proposé.
Les webmasters qui désirent séparer les pages Web des partitions qu'elles présentent pourront toujours le faire. Dans ce cas, l'app lira le fichier .myrweb.html, récupèrera à l'intérieur les données du bloc binaire qui y sont stockées, et utilisera ces données comme avant.
Du point de vue du webmaster, il n'y aura donc aucune difficulté supplémentaire par rapport à la solution que nous envisagions précédemment.
En conclusion
Mis à part une légère augmentation de la taille des fichiers exportés, cette nouvelle manière d'envisager l'export n'aura que des avantages, le principal étant que l'utilisateur de base n'aura pas à se soucier de la technologie employée. Il exportera sa partition, et pourra la transmettre à n'importe qui, en étant certain que le morceau sera visible et jouable par son correspondant, par simple double-clic. |
|
|
| by Olivier Guillion | |
|
| |
|
Déplacer une note avec parenthèses autour de l'altération effaçait l'information de parenthèses.
Nouvelle icône dans la palette des altérations pour choisir le mode "altération entre parenthèses".
Correction de divers problèmes de débordement en exportation SVG d'images non vectorielles cassées.
Le MUSL s'exporte maintenant jusqu'à la lettre B. |
|
|
| by Didier Guillion | |
| |
|
Correction d'une saturation mémoire lors de l'export en MusicXML d'images incluses dans une partition :
Harmony Assistant gère les formats d'image vectoriels ou compressés. Ces images peuvent être extrêmement grandes, mais être gérées sans avoir besoin d'une place mémoire importante.
En export MusicXML, nous sommes obligés de tracer ces images sur une zone mémoire non compressés, pour ensuite les inclure dans le fichier.
Imaginons une image de 12000 par 10000 pixels. La zone mémoire de tracé devra faire 12000x10000 = 120 000 000 (120 millions) de pixels. A raison de 3 composantes (rouge, vert, bleu) par pixel, la zone mémoire devra faire 120x2= 360 Mo. S'il y a 10 images comme ça dans la partition, on atteint les 3.6 Go. Lourd. La mémoire sature, et la gestion de cette zone énorme prend un temps tout aussi énorme.
Nous avons donc modifié l'export afin de limiter la taille des grandes images, en dégradant un peu leur qualité, et minimisant ainsi l'empreinte mémoire (ainsi que la taille du fichier MusicXML résultat, par la même occasion) |
|
|
| by Olivier Guillion | |
| |
|
Mise en place des restrictions de la version d'évaluation pour les exports MyrWeb : une seule page et les premières secondes de la musique.
Dans l'export HTML depuis le plug-in, un nouveau tag pour exporter le style de musique.
En explorant le contenu du MUSL nous avons découvert des fichiers assez spéciaux : un utilisateur utilise des sauts au segno pour faire boucler la musique des milliers de fois (certainement pour s'entrainer à jouer dessus) pour une durée de plusieurs jours. Tant que nous étions au format .myr cela ne posait aucun problème mais maintenant que l'audio est mémorisé en MP3 dans le MyrWeb cela donnait des fichiers de taille hallucinante ! Nous avons donc mis en place une protection qui limite la taille maximum de l'audio.
Un mécanisme commence a être mis en place permettant de mettre à jour à distance certains fichiers de données sensible sans avoir à réinstaller l'application. Par exemple cela permettrait de diffuser régulièrement de nouvelles version de la base de donnée des reconnaissance de caractères dans PDFtoMusic.
Bon week-end ! |
|
|
| by Didier Guillion | |
|
| |
|
Nous avons pu établir quelques statistiques sur l'état actuel des espaces utilisateur, et projeter ce que cela pourra donner après conversion des partitions au format Myrweb.
L'espace actuellement réservé à chaque compte d'utilisateur est de 20Mo. Inutile de dire qu'avec le nouveau format, qui inclut les données MP3 de l'ensemble du morceau, une capacité aussi faible poserait quelques problèmes.
Nous avons donc fait des projections sur les comptes existants.
Si on fixe la limite à :
100 Mo, 25% des comptes dépassent
200 Mo, 20% des comptes dépassent
500 Mo, 10% des comptes dépassent
1 Go, 5% des comptes dépassent
Si on analyse ces gros, gros comptes, on se rend compte que plusieurs d'entre eux parviennent à une telle taille parce que certaines partitions durent plusieurs heures, et un MP3 de plusieurs heures, ça occupe de la place. Il s'agit de partitions bouclées de manière infinie par un saut inconditionnel au début lorsqu'on atteint la fin. Ainsi la palme revient à un utilisateur, qui cumule ainsi 260 heures de musique (14 Go) !
Nous cherchons un moyen de détecter et de traiter particulièrement ces morceaux pour éviter qu'ils n'explosent tous les quotas.
Malgré cela, l'ensemble des morceaux du MUSL va tout de même occuper plusieurs dizaines de Go, trop pour être supportable sur notre hébergement actuel.
Nous allons donc probablement:
- Fixer un quota assez élevé, entre 300 Mo et 1 Go
- Prendre un autre hébergement pour stocker les fichiers myrweb
- Proposer une option "premium" payante (peut-être par un abonnement annuel très peu cher), avec par exemple un quota de 10 Go, qui nous aidera à payer le nouvel hébergement.
L'avantage est que plus il y aura d'abonnements premium au MUSL, plus nous aurons besoin d'espace, mais plus nous aurons de sous pour le payer 
Reste enfin le problème de l'espace privé, qui permet d'avoir une section accessible seulement par mot de passe. Lorsque les pages Web et les fichiers étaient au même endroit, la même authentification protégeait les deux. Mais si les données sont délocalisées ailleurs, ça devient plus compliqué de protéger les .myrweb eux-mêmes. Pour l'instant, trois options :
- soit ils ne sont pas protégés, et quelqu'un qui connaît leur URL peut alors les récupérer,
- soit les fichiers de l'espace privé restent sur le même serveur que les pages, mais on doit en limiter drastiquement la taille
- soit on supprime la fonctionnalité d'espace privé |
|
|
| by Olivier Guillion | |
|
| |
|
Dans la configuration avancé de l'export MyrWeb on peut spécifier une valeur même si c'est la valeur par défaut et revenir ensuite à la valeur par défaut.
Grace au jukebox qui nous permet de traiter de manière automatique plusieurs milliers de fichiers nous sommes en train de traquer les fuites de mémoire et les débordements de mémoire. C'est un travail assez fastidieux mais qui améliore grandement la stabilité du logiciel.
Les informations associées aux commentaires ont été agrandis en taille et sont plus conviviales.
Certains chaines de textes n'avaient pas été traduites, c'est corrigé.
L'export hiérarchique (avec arborescence) des fichiers MyrWeb indépendant des HTML depuis le jukebox a été généralisé et est maintenant disponible pour les MyrWeb embarqués dans les pages HTML.
|
|
|
| by Didier Guillion | |
| |
|
Comme entamé la semaine dernière, nous traitons, par le Jukebox, des listes de plusieurs milliers de documents musicaux que nous lisons, exportons, et dont nous récupérons toutes les informations possibles.
Sur Windows, en phase de développement, nous avons créé un outil de gestion mémoire qui protège physiquement de tous les accès illégaux (lecture ou écriture qui dépasse une zone mémoire normalement allouée). Alors qu'une version publique pourrait fonctionner, et ne planter qu'une fois sur 100, cette gestion mémoire est hypersensible, et génèrera un crash à la moindre irrégularité.
Sur un traitement de plusieurs milliers de fichiers, il y a donc de bonnes chances que, s'il y a un bug quelque part, il soit mis en évidence. Ceci nous a d'ailleurs d'ores et déjà permis d'en trouver et corriger quelques-uns.
Seule ombre au tableau : les opérations très demandeuses en mémoire deviennent de 5 à 10 fois plus lentes, ce qui, pour des traitements en masse, signifie que nous devons attendre le résultat de l'opération 1/4h au lieu de 2 mn. |
|
|
| by Olivier Guillion | |
| |
|
L'export myrweb de la liste du jukebox est quasiment finalisé. Nous l'avons testé sur les musiques de démonstration puis sur une copie locale du MUSL.
La présentation des résultats est voulue simple et sobre.
Nous avons généré toutes les pages HTMl correspondant au MUSL ce qui représente plus de 5 semaines de musiques.
Des estimations de temps de calcul ont été faites pour voir s'il nous était possible d'assurer nous même la conversion en block du Musl. Hélas cela représente plus de 5 jours de calcul ininterrompus Il va falloir déléguer les conversions des .myr en .myrweb chez chacun des utilisateurs.
Bon week-end ! |
|
|
| by Didier Guillion | |
|
| |
|
Nous avons commencé à convertir les accès au MUSL vers le nouveau format d'export de partitions, le format myrweb.
Nous avons mis en place une version "bac à sable" du site sur nos machines locales afin de pouvoir travailler sans crainte de casser des pages visibles publiquement.
Coté serveur, les script qui s'occupent de la génération des pages Web ont été repris, ainsi que les modèles de pages. Globalement, il y a eu très peu de modifications à faire.
Coté Harmony Assistant, c'est à peine plus compliqué. Il a fallu, plutôt que d'envoyer directement le fichier MYR, le convertir d'abord en format myrweb.
Mais deux problèmes demeurent :
- Comment convertir l'intégralité des fichiers déjà publiés par chaque utilisateur ?
Une procédure automatique effectuera-t-elle cette conversion à la première connexion de l'utilisateur sur son espace avec la nouvelle version d'Harmony ? Que se passera-t-il si la place occupée dépasse le quota attribué (pour l'instant, 20Mo)?
Ou bien doit-on se charger nous-mêmes de la conversion de l'ensemble du MUSL ? Avec ses centaines d'heures de musique cumulées, cela va alors probablement prendre au moins une journée complète (probablement plusieurs jours) !
- Comment faire tester le nouveau MUSL dans la prochaine beta, sans altérer les pages Web existantes ? Cela va probablement nous obliger à mettre en place un bac à sable, public cette fois, qui permettra aux beta-testeurs de procéder sans crainte à leurs essais.
|
|
|
| by Olivier Guillion | |
|
| |
|
Nous avons bien avancé dans l'export MyrWeb depuis le jukebox. Par rapport à la version utilisant le plug-in, un avantage de taille se dessine : il n'est plus nécessaire de fournir le .myr puisque celui-ci est convertit en MyrWeb qui lui est publié. A partir de l'arborescence définie dans le jukebox on génère donc une arborescence similaire dans un autre dossier, c'est ce dossier qui sera publié par l'utilisateur.
L'aspect des différentes pages d'index a penché vers la sobriété. Le tout sera bien entendu configurable par les utilisateurs maitrisant le HTML.
|
|
|
| by Didier Guillion | |
| |
|
|
