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 |  |
| |
|
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 | |
| |
|
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 | |
|
| |
|
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 | |
| |
|
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 | |
| |
|
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 | |
|
| |
|
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 | |
| |
|
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 | |
|
| |
|
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 | |
| |
|
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 | |
|
| |
|
|
