Même si les capacités des navigateurs se sont alignées ces dernières années, pour arriver à un résultat quasi-identique, il reste encore quelques fonctionnalités qui ne sont pas présentes sur tous, surtout quand on va faire un tour vers des navigateurs "exotiques" (principalement sur appareil mobile) ou sur d'anciennes versions. Il nous faut donc un moyen de savoir quelles fonctionnalités sont présentes sur le navigateur qui fait tourner nos apps, afin soit de supprimer proprement les options qui y sont liées, soit mettre en place une méthode de contournement. Dans ce but, nous avons commencé à mettre en place une structure d'"information système", qui répertorie hiérarchiquement les options techniques accessibles. Même si ce n'est pas très parlant pour un non initié, cela permet de voir si le navigateur utilisé est à la page. Dans la démo suivante: Informations système Toutes les rubriques devraient être vertes, sauf "Sound > Audio > Flac", le format audio "flac" n'étant à notre connaissance pris en compte par aucun navigateur actuel (nous avons testé cette option pour vérifier que nous détections bien son absence). Si vous avez du rouge partout, mauvais plan, c'est que vous utilisez Internet Explorer 8 |
|
|
by Olivier Guillion | | |
| |
|
Nous étions plutôt réticents au début, le format graphique SVG étant connu pour être très complexe, et n'étant pas pris en compte intégralement par beaucoup de logiciels. Il faut avouer que la compatibilité, même si elle n'est pas parfaite, s'est bien améliorée ces derniers temps. Il y a maintenant peu de différences dans le rendu graphique sur Chrome, Firefox, Safari ou IE. Quant à la complexité, c'est une légende. Le format est au contraire facilement exploitable, et sa structure XML rend les fichiers facilement explorables et modifiables manuellement, avec un simple éditeur de texte. Tellement facilement que ce format nous permet de réaliser très rapidement des maquettes graphiques, et combiné avec Javascript, de créer de petits algorithmes spécifiques destinés à être intégrés, plus tard (moyennant réécriture) au programme. Par exemple, pour enrichir graphiquement la nouvelle fonctionnalité d'annotation, nous avons créé des petits modules de mise en valeur du texte: Vous pouvez tester vous-même ces petits algorithmes ici : Surlignage et encadrements Malheureusement, le format SVG n'est interprété en natif par aucun système d'exploitation à notre connaissance. C'est bien dommage, car il n'existe aucun autre format de tracé vectoriel compatible entre les systèmes, à part, peut-être, le PDF, qui est lourd et difficilement manipulable. Cela nous oblige donc à créer notre propre standard de tracé graphique (ou écrire un interpréteur SVG) pour intégrer à nos programmes des algorithmes graphiques tels que ceux présentés dans la démo. Bon week-end ! |
|
|
by Olivier Guillion | | |
| |
|
Les système d'annotation par "PostIt" a bien avancé. Une passerelle a été écrite afin de pouvoir utiliser les palettes d'Harmony dans PDFtoMusic. La palette style à donc été intégré et les PostIt sont maintenant multi-styles avec une couleur de fond sélectionnable. L'export par lot a été optimisé afin de pouvoir utiliser PdfToMusic comme un convertisseur de lots de PDF vers le format SVG. |
|
|
by Didier Guillion | | | |
|
La première chose que nous ayions commencé à adapter en HTML5/Javascript, et qui nous a permis de jauger la quantité de travail à réaliser est notre lecteur de didacticiels. Il s'agissait d'une partie quasi-séparée de notre plug-in, mais qui faisait appel à pas mal de travaux sur les images, la lecture et le décompactage de fichier binaire, un peu de son, et quelques boutons cliquables. Une pré-pré version tourne donc depuis pas mal de temps, mais elle était trop brute de décoffrage pour être présentée. Ces derniers jours, nous nous y sommes remis et l'avons quasiment finalisée. Vous pouvez donc en voir la démo ici : Démo des didacticiels Les trois points principaux qui nous manquent sont détaillés dans la page de démo. Restera ensuite à terminer quelques détails, comme présenter quelque part le numéro de version et un lien vers Myriad, tester ça sur un maximum de navigateurs et, peut-être, ajouter une animation permettant de patienter pendant le téléchargement et la mise en place du didacticiel. |
|
|
by Olivier Guillion | | |
| |
|
L'export SVG commence à fonctionner plutôt bien et avec une précision très intéressante. Voici à gauche le fichier PDF original qui exporté en SVG par PDFtoMusic puis importé par Firefox donne le résultat à droite. Nous en avons donc profité pour sortir de nos cartons un concept assez ancien mais jamais mis en pratique : la possibilité d'annoter les fichiers PDFs. Une nouvelle palette fait donc son apparition elle permet d'ajouter des objets de différents type sur un PDF puis d'exporter le résultat en BMP mais surtout SVG. Voici un exemple de ce que l'on pourra faire : ajouter une note genre PostIt, contenant un texte stylé. On pourrait imaginer un type d'objet de type Stabilo pour surligner des passages. |
|
|
by Didier Guillion | | | |
|
Avec WebAudio, nous avons trouvé une méthode pour modifier à volonté les volumes gauche et droit d'une source stéréo. Ceci devrait nous permettre de proposer une table de mixage avec réglage de la position stéréo. Ce faisant, nous avons séché un bout de temps sur une implémentation bizarroïde d'un composant Webaudio. Ceci fera probablement l'objet d'un billet technique, par charité pour les autres programmeurs qui, comme nous, vont vainement parcourir le Web à la recherche de la solution à ce problème. Sinon, tout avance assez bien. L'app MyrWeb est quasiment opérationnelle en matière d'interface, il reste à finaliser le jeu de la musique, et à écrire la gestion de la barre de temps, avec sélection d'une partie, jeu en boucle, etc. Quelques points nous posent encore des problèmes de compatibilité entre navigateurs, notamment la prise en compte par l'app de la touche retour arrière (sur Chrome, elle fait revenir à la page Web visitée précédemment), et le téléchargement des fichiers inclus dans l'archive (sur Firefox, ça fonctionne en pas à pas, et ne fait rien lorsqu'on l'essaie vraiment). Encore un peu, et nous pourrons proposer une démo complète de l'interface. |
|
|
by Olivier Guillion | | |
| |
|
Dans PDFtoMusic export des images bitmaps embarquée dans les PDF dans les fichiers .SVG. Le calcul de la taille estimée a largement progressé. Correction de l'impression des images avec transparence sur Mac. Dans la boite de configuration de l'export MyrWeb, option pour calculer automatiquement les groupes selon différentes méthodes on retrouve ainsi les portées avec paroles chantées ensemble, la première portée à part, etc. Un nouveau bouton permet de prévisualiser le fichier .myrweb dans le navigateur web. Bon week-end ! |
|
|
by Didier Guillion | | | |
|
- LE POURQUOI DU COMMENT - L'abandon de la technologie (NPAPI) qui nous permettait de proposer le plug-in de visualisation et de jeu des partitions musicales nous contraint à adopter un nouveau système. Avec ce nouveau système, les fichiers de partitions seront plus volumineux, dans des proportions assez importantes. Là où on comptait en kilo-octets, un fichier de partition pourrait maintenant occuper plusieurs méga-octets. La licence d'Harmony Assistant inclut un espace de stockage des partitions offert à chaque utilisateur, sur un site baptisé MUSL (Myriad Users Score Library). Directement accessible depuis le logiciel, une interface graphique permet de publier quasi instantanément ses créations musicales sur Internet. Une limite d'espace (20Mo par utilisateur) permettait de stocker un nombre important de partitions sans souci. L'espace de stockage sur nos serveurs étant limité, nous avions calculé que tout le monde n'utiliserait pas la totalité de son espace, et donc que nous aurions de la marge. A l'heure actuelle, 14000 partitions sont ainsi hébergées chez nous (toutes ne sont pas visibles publiquement), sans que cela pose un problème de saturation de disque. Mais l'inflation des fichiers induite par le nouveau système pourrait bien changer la donne. - QU'EST-CE QUE CELA VA CHANGER ? - Tout d'abord, les 20Mo risquent de ne pas être suffisants pour beaucoup. Cela correspondrait en moyenne à entre 10 et 20 partitions par utilisateur (nous sommes en train de calculer des statistiques pour affiner ces chiffres), ce qui n'est pas énorme. Et encore, c'est calculé en considérant que les pistes audio sont stockées en basse qualité pour réduire au maximum la taille des fichiers. Sinon, ce serait plutôt entre 5 et 10 partitions. Même si nous conservons cette limite, notre serveur actuel risque de ne pas disposer d'un espace suffisamment confortable pour héberger tout cela dans des conditions sereines. Pour l'instant, cela suffirait, mais à peine. Il nous faut toujours prévoir une marge de manoeuvre. - QUELLES SOLUTIONS ? - Nous réfléchissons donc à une solution au problème. Pour l'instant, nous avons plusieurs options: 1- Fermer définitivement le MUSL C'est une solution de tout dernier recours. Le MUSL permet à tous ceux qui ne disposent pas d'un site personnel, ou qui n'ont pas les connaissances technique, le temps ou l'envie de mettre en place leurs propres pages de publier et partager leur travail. Ce serait vraiment dommage, pour tout le monde, de ne plus proposer ce service. 2- Continuer comme cela, avec des contraintes d'espace égales ou inférieures Cela peut fonctionner techniquement, mais beaucoup vont se retrouver bloqués par le manque d'espace. Pouvoir proposer seulement 5 à 10 fichiers risque de réduire fortement l'intérêt du système. 3- Changer d'hébergement Il est possible de déménager l'intégralité du MUSL vers un service disposant d'une beaucoup plus grande capacité de stockage. Les quotas pourrait alors être augmentés, afin de permettre à chaque utilisateur de stocker plusieurs dizaines de ses partitions (nombre, ou plutôt durée cumulée de jeu, à déterminer). Quatre sous-options ici: a) Conserver la gratuité Cet hébergement, nous devrions le payer, pour pouvoir continuer à proposer gratuitement un service à nos utilisateurs. Techniquement possible, financièrement un peu moins, même si on peut trouver des hébergements vraiment pas chers. b) Une gratuité partielle Un service de base (hébergement de quelques partitions et/ou son en basse qualité uniquement et/ou pas d'espace privé) serait offert avec la licence, et il serait possible, en s'acquittant d'un forfait annuel de quelques euros, d'opter pour une version "premium" qui éliminerait ces limites ou les pousserait vers le haut. c) Un service payant Même chose que précédemment, mais l'espace, doté de toutes les fonctionnalités et d'une place confortable ne serait accessible qu'après paiement dudit forfait annuel. d) Un service en contribution volontaire Ne pas demander automatiquement une contribution aux utilisateurs, mais laisser ceux qui le désirent contribuer (à vot' bon coeur, m'sieur-dame). Nous listons cette possibilité pour la forme, étant persuadés qu'à part une ou deux personnes très motivées, personne ne donnerait un kopek. Voilà pour l'instant où en sont nos réflexions. Qui serait prêt à payer, pour quel service, quel montant, dans quelles conditions ? Autant de questions auxquelles nous n'avons aucune réponse à l'heure actuelle. Et il y a peut-être d'autres solutions auxquelles nous n'avons pas pensé... |
|
|
by Olivier Guillion | | |
| |
|
Avec l'app Myrweb, nous bataillons avec les problèmes de "cross-origin". Pour comprendre, il faut entrer un peu dans les détails techniques. Ces détails, l'utilisateur final ne devrait pas avoir à s'en soucier, mais comprendre ce qui se passe ne nuit jamais. Une page Web peut demander d'afficher des images situées sur un autre site. Par exemple, je peux demander d'afficher ici n'importe quelle image située ailleurs que sur le site myriad-online.com. La preuve: Cette image est située sur myriad-users.com, donc un autre site, et cela ne pose pas de problème. Par contre, pour des raisons de sécurité, le navigateur refusera que j'intègre à ma page web un script situé sur un site extérieur qui n'a pas spécifié son accord pour ce genre de chose. Cela est censé empêcher à un site d'utiliser les scripts de quelqu'un d'autre en loucedé. J'avoue ne pas très bien comprendre. Les scripts étant des fichiers texte, ils sont lisibles, donc récupérables et copiables malgré tout. Mais bon, admettons. Enfin, un script qui demande de charger un fichier externe pour ensuite travailler sur les données se verra appliquer la même règle. Le fichier en question doit être situé sur un serveur qui donne son autorisation pour un accès depuis un script. Sinon, l'accès est refusé. Là où ça se complique, c'est que la plupart des navigateurs (tous sauf Firefox) empêchent également qu'un script accède à un fichier situé localement sur l'ordinateur (protocole file://), même si la page Web et/ou le script en question sont également situés en local sur file://. Même en tournant le problème dans tous les sens, cette restriction est complètement irrationnelle. Qu'est-ce que cela implique pour nous ? Nous voulions permettre à l'utilisateur, lorsqu'il exporte une partition en myrweb, de pouvoir visualiser ce que cela donne dans l'app. Nous pensions donc créer une petite page Web en local, qui accède au fichier myrweb sauvegardé, et qui le montre ainsi dans le navigateur. Mais la règle de cross-origin nous en empêche (impossible de lire depuis un script les données situées en local). Il reste donc quatre solution : 1- Envoyer (upload) le myrweb quelque part sur notre site, et le montrer depuis cet endroit (protocole HTTP habituel) Mais un envoi de plusieurs mega-octets, ça prend du temps, et ça monopolise de la bande passante et de l'espace sur nos serveurs pour une simple vérification d'aspect par l'utilisateur 2- Ouvrir un mini-serveur Web sur le poste de l'utilisateur, et lui montrer sa page en intranet (protole HTTP sur l'IP locale) Techniquement possible, mais beaucoup, beaucoup trop compliqué et lourd en pratique. 3- Ecrire nous-même un visualiseur de .myrweb qui ne passe pas par une page Web ou un script. Cela revient à réécrire l'app en C, avec les problèmes de différences d'aspect et de réaction que cela implique, tout ça pour un maigre résultat. 4- Parvenir à ce que le script n'ait pas à accéder au fichier .myrweb lui-même, mais que toutes les données soient contenues dans la page Web de test elle-même. Ainsi, pas d'accès à un fichier extérieur, donc pas de problème de cross-origin. Nous sommes en train de tester la faisabilité de cette dernière solution, avant de jeter complètement l'éponge sur ce point. |
|
|
by Olivier Guillion | | |
| |
|
Dans PDFtoMusic les barres de progression sont maintenant normalisées et identiques à celles d'Harmony. L'affichage des erreurs dans le drawer ne se fait que si l'affichage des résultats est demandé. La progression de l'export Myrweb est matérialisée par une double barre de progression. L'export MP3 se fait maintenant en une passe et est beaucoup plus rapide. Le calcul des aires du .myrweb est beaucoup plus précis dans PDFtoMusic. L'accès à la configuration de myrweb est proposé dans l'export par lot et l'export automatique de PDFtoMusic. |
|
|
by Didier Guillion | | | |
|
A chaque nouvelle fonction mise en place dans l'app MyrWeb, nous la testons sur différents navigateurs, notamment Firefox et Chrome sur Mac & Windows, Safari sur Mac et Internet Explorer sur Windows. Rapidement, nous avons dû éliminer les anciennes versions d'IE, qui ne permettent quasiment de ne rien faire, ni graphiquement, ni en audio. La version minimale d'IE sera donc la 10 ou peut-être la 11 (nous pouvons tester sur IE 11, mais n'avons pas d'IE 10 sous la main). Pour Safari sur Mac, les dernières versions ne tournent que sur les dernières versions de MacOS. Les mises à jour du système étant payantes, et ne s'installant pas sur certains vieux Macs, pas mal d'utilisateurs n'ont pas la dernière version de MacOS, et utilisent donc une ancienne version de Safari. La plus vieille que nous ayions à disposition est Safari 5.0.6, qui date de 2011. Elle permet de faire fonctionner l'app, avec quelques options qui sautent ou qui tournent en mode dégradé, mais ça fonctionne. Donc dès qu'une fonctionnalité a été ajoutée et testée sur Firefox et Chrome, nous l'adaptons pour qu'elle fonctionne aussi sur IE 11 et la vieille version de Safari. Dernière en date, les dégradés de couleur, donc voici une démo: Dégradés de couleurs Cette démo fonctionne sur toutes les configurations, mais il semble y avoir une différence dans la manière dont Safari prend en compte l'angle de dégradé. Ainsi, chaque petite fonction nous occupe environ 3 fois plus longtemps qu'elle aurait dû, mais, point positif, à la fin ça fonctionne. Ce n'était pas le cas il y a encore quelques années, avant HTML5. |
|
|
by Olivier Guillion | | |
| |
|
Le format MyrWeb continue de s'affiner. Les communications entre la librairie et PDFtoMusic sont maintenant au point : quand on demande d'inclure le MusicXML dans un fichier MyrWeb, c'est le MusicXML directement généré par PDFtoMusic qui est pris. De même l'image affiché ne sera pas une interprétation du fichier .myr mais bien une conversion directe du PDF en SVG. Nous avons donc choisi d'écrire un convertisseur PDF vers SVG, et cela fonctionne plutôt bien ! L'export en SVG sera proposée dans le menu des exports de PDFtoMusic. Il y aura même deux formats possible : le format proposant autant de fichiers que de pages et un format multi-pages. Bon week-end ! |
|
|
by Didier Guillion | | | |
|
Les deux équipe de forage du tunnel se sont rencontrées au milieu. D'un coté, la sauvegarde au format d'export Myrweb, de l'autre, l'utilisation de ces fichiers dans une app HTML5/CSS3/JS. Les fichiers sont maintenant lus, décompactés, analysés, et ils commencent à être interprétés. Nous avons mis en place une première version du clavier virtuel permettant de montrer le doigté du piano en fonction de la musique Cette toute première version peut être testée en vrai sur cette page: Démo du clavier virtuel Myrweb |
|
|
by Olivier Guillion | | |
| |
|
Les informations de métronome ont été ajouté aux fichiers myrweb. Les différents chunks peuvent être compactés si nécessaire afin de gagner de la place (la taille des fichiers va être le talon d'Achille de myrweb) Un fichier myrweb peut être généré depuis différents formats de fichiers et éventuellement inclure le fichier original. Par exemple, à partir d'un myr, on peut obtenir le fichier original plus le XML embarqué dans le .myrweb. L'utilisateur final aura le choix du fichier à extraire. Nous nous sommes rendu compte que cette technologie permettrait, si intégré à PDFtoMusic, de prendre un PDF et de l'exporter en format Myrweb. Cela donnerait un fichier PDF, affiché sur une page web, que l'on pourrait interpréter musicalement. Malheureusement tous les systèmes ne peuvent afficher des pages d'un PDF, il faudrait créer un convertisseur PDF vers PNG (facile mais lourd) ou mieux un convertisseur PDF vers SVG. Dans une première étape nous avons généralisé la boite de configuration de MyrWeb qui devient ainsi commune à Harmony et PDFtoMusic. Puis nous avons intégré l'export MyrWeb dans PDFtoMusic. Les premiers essais sont plus que concluant : nous avons cet après midi généré pour la première fois un fichier myrweb structurellement correct depuis PDFtoMusic. |
|
|
by Didier Guillion | | | |
|
Nous avons utilisé WebAudio pour générer des sons de clic et de cloche de métronome, puis pour jouer ces sons synchronisés avec deux pistes MP3. Le petit test qui suit permet donc de jouer un morceau avec le métronome, et de régler séparément les volumes de chaque piste: Métronome WebAudio Pour les navigateurs ne supportant pas le WebAudio, nous avons également prévu que le son du métronome puisse être calculé sur l'ensemble de la durée de la musique. Cela prend un peu de temps à générer, mais permet d'offrir une solution sur ces navigateurs. Hélas, nous avions oublié qu'Internet Explorer ne sait pas jouer les données brutes WAV (non compressées). Il ne peut donc pas jouer la piste de métronome que l'app a construite. Pour que cela fonctionne, il faudrait que nous créions des données MP3, mais là, créer des données sonores puis les encoder en MP3, tout ça en javascript, c'est un peu trop compliqué pour simplement pallier aux carences d'IE. |
|
|
by Olivier Guillion | | |
| |
|
A la manière des tunneliers sous la Manche deux parties de notre équipe travaillent de manière indépendante et visent à se rejoindre à peu près en face... L'une se débat avec le HTML5 et Javascript pour lire et traiter les fichiers .myrweb, l'autre remplit petit à petit ces mêmes fichiers depuis Harmony Assistant. Les nouvelles informations ajoutées et non testées sont : - Aire graphique des mesures sur l'image SVG, afin de pouvoir entre autre afficher le curseur de progression - Le tableau donnant la mesure écrite en fonction de la position temporelle jouée, pour le même but que si dessus. - L'image montrant le texte des paroles, pour le karaoké. - Le tableau donnant l'aire sélectionné dans les paroles en fonction de la position temporelle, pour le karaoké. - Le tableau donnant les positions temporelles jouées de lancement et d'arrêts de notes, pour le Clavier Virtuel. |
|
|
by Didier Guillion | | | |
|
Nous avons réalisé un petit essai de calcul de données numériques par WebAudio (non disponible sur IE): Génération de sons par WebAudio Ce procédé nous permettra de réécrire la partie sonore l'app de Kooplet que nous avions réalisée en ActionScript (Flash). En effet, le plug-in flash, lui aussi utilisant NPAPI, aurait dû ne plus être supporté en même temps que notre plug-in. Mais il continue à fonctionner encore, bénéficiant d'un traitement de faveur que nous trouvons assez injuste. Il est en effet le seul plug-in NPAPI à fonctionner encore sur Firefox 64 bits, ce navigateur le testant spécifiquement pour le laisser passer entre les mailles, et bloquant définitivement tous les autres. Pour en revenir à l'audio, nous allons faire d'autres tests sur WebAudio, pour voir s'il ne serait pas possible d'implémenter une fonction "métronome" par ce biais. Le métronome est en effet en sursis dans la nouvelle version du plug-in à moins de stocker une piste MP3 supplémentaire pour lui, ce qui ferait grossir encore le fichier. Bon week-end ! |
|
|
by Olivier Guillion | | | |
|
Ce n'est certainement pas la partie la plus cruciale du projet, mais nous avons commencé à réfléchir à l'interface. Il faut pouvoir afficher des boutons, des icônes, etc. En temps normal, chaque graphisme, dans chacun de ses états, c'est un fichier supplémentaire, qui doit être téléchargé par l'utilisateur. Mais nous nous sommes alors souvenu que pour construire l'image de la page de partition, nous avions utilisé le format SVG. Très compacts, les dessins sont zoomables à volonté, et cerise sur le gâteau, ils peuvent être animés automatiquement. Nous avons alors commencé à dessiner quelques icônes en SVG, et prévu des animations (transitions) pour les passages d'un état à l'autre. Une petite démo illustre cela: Icônes SVG et transitions Nous avons eu ainsi la confirmation que la mode actuelle des à-plats de couleur pour les icônes n'est pas une affaire d'esthétique ou d'ergonomie, mais bien de facilité de programmation. Mais plutôt que de dire : "On revient en arrière parce que ça facilite la vie des programmeurs", cela a été présenté comme une amélioration, le nec plus ultra de la hi-tech. Quoi qu'il en soit, nous commençons à savoir un peu créer des choses en SVG, et il se peut qu'à l'avenir, nous nous penchions sérieusement sur ce format pour une intégration dans nos produits (l'export existe maintenant, mais l'import est peut-être plus compliqué). |
|
|
by Olivier Guillion | | |
| |
|
Trois étapes importantes ont été franchies dans l'étude du nouveau plug-in ! Tout d'abord nous nous sommes mis d'accord sur le format du fichier qui aura comme extension .myrweb (la limitation à trois caractères a vraiment trop duré). Ce sera un fichier à "chunks", c'est à dire composé de paquets de données, avec pour chaque paquet, un type et une version. Un exemple célèbre de ce type de stockage est l'AIFF ou encore les fichiers QuickTime. On peut y ranger à peu près tous les types de données que l'on veut, audio, images, textes, etc. Chaque programme en extrait ce qui l'intéresse. Le gros avantage des "chunks"est une compatibilité descendante : une ancienne version du code ignorera les chunks plus récents et ne traitera que ceux qu'elle peut gérer. Une fois ce format à peu près établi sur le papier, nous avons écrit une première maquette succincte du module Harmony qui va convertir un document .myr en .myrweb. Nous avons également écrit une moulinette qui va lire ce genre de fichier et explorer ces données pour valider l'export. Enfin, nous avons commencé à bâtir la boite de configuration de l'export en .myrweb : On peut donc définir finement le type de données présente dans le fichier et créer par exemple des fichiers uniquement avec de l'audio, des paroles ou des images de la partition. On peut créer des groupes de portées qui seront exportés dans des flux audio différents et donc avec des volumes réglables séparément On peut spécifier le type de données originales embarquées dans le .myrweb ce qui permettra à la personne naviguant sur la page de le récupérer sur son poste de travail. Tout ceci n'est pour l'instant qu'un gros chantier et il reste des pans entiers à écrire. |
|
|
by Didier Guillion | | | |
|
Le son Nous avons conduit divers tests sur les possibilités sonores du HTML5. Dans ce domaine, la disparité entre les navigateurs semble assez forte. Un standard prometteur, appelé WebAudio, est en passe d'être implémenté sur la plupart d'entre eux, mais Microsoft semble avoir fait l'impasse sur Internet Explorer, pour ne s'intéresser qu'à Edge (Windows 10 uniquement). Pour le reste, WebAudio permet pas mal de choses, dont de la génération sonore à la volée. Voici le résultat de nos essais. Ces derniers étant codés à l'arrache, nous rechignons à les montrer, car nous recevrions probablement des commentaires sur l'aspect graphique, l'ergonomie ou les défauts de synchro. Nous vous demandons donc de nous croire sur paroles. Ceux qui sont intéressés peuvent cependant nous contacter en direct. I- WebAudio API Permet de créer un "graphe" audio, c'est-à-dire des noeud interconnectés. Par exemple, un noeud "données numériques" connecté à un noeud "filtre", lui-même connecté à un noeud "gain", lui-même connecté à la sortie. Lorsque le graphe est lancé, les données numériques sont filtrées, amplifiées, puis envoyées aux haut-parleurs. Ne pouvant pas recoder en Javascript l'intégralité de notre module de sortie audio, avec Virtual Singer et tous les effets numériques, nous ne pouvons pas envisager une génération sonore identique à Harmony. Nous avons tenté des solutions intermédiaires, mais sans succès. A priori, il faudra donc stocker l'intégralité de l'audio du morceau. Compatibilité: initialisations particulières sur Safari, non géré par IE II- Le tag <audio> HTML5 C'est une fonction de haut niveau du HTML5, beaucoup plus compatible que WebAudio API, mais beaucoup moins puissante. Elle permet de jouer un morceau numérique extérieur, en MP3, OGG (pas tous les navigateurs) ou WAV (tous, sauf apparemment IE qui gèrerait pas ce format créé par Microsoft !). En rusant pas mal, on peut s'arranger pour lui faire jouer des données MP3 extraites par le Javascript plutôt qu'un véritable fichier séparé. De tout cela, voici ce que nous en avons tiré: Le format spécial d'export de musique contiendrait les données MP3 de tout le morceau, ou plusieurs MP3 représentant les portées pouvant être jouées en solo L'app jouerait ce ou ces MP3. Il semblerait possible de varier la vitesse et/ou de transposer l'audio. Si le fichier contient plusieurs MP3, l'app pourrait les mixer, et faire varier le volume relatif de chacun Il serait sans doute possible de ne pas démarrer au début, et de boucler sur une portion Il ne serait pas possible de modifier leur position stéréo Pour pouvoir jouer le métronome, il faudrait une piste MP3 séparée Les fichiers pourraient devenir très volumineux, si beaucoup de pistes différentes étaient nécessaires (16 ko par seconde et par piste). Mais c'est pour l'instant la seule solution que nous ayions trouvée. |
|
|
by Olivier Guillion | | |
| |
|
Correction d'un problème d'intéraction entre les palettes Divers et Ottava. Classement des objets textes, graphiques & lignes et diagramme d'accords associés à la portée par ordre croissant de temps afin de rendre le balayage MyrScript plus propre. Mise à niveau des ressources dans les différentes langues, mise en place de la gestion des préférences du Dock, de l'export graphique en SVG et de l'export au format .myrweb (fichiers lisibles en HTML5). Afin de pouvoir passer à des tests en vraie grandeur, nous commençons l'implémentation du format MyrWeb parallèlement à l'écriture du module HTML d'affichage. Si les tests sont concluants, un prototype devrait arriver... |
|
|
by Didier Guillion | | | |
|
|