La dernière fonction utilisant des "pict" (commandes graphiques au format MacOS) vient d'être réécrite en utilisant nos nouvelles méthodes.
Il s'agissait de la fonction permettant d'afficher des picts de la couleur qu'on désire, utilisée dans l'affichage des objets graphiques liés à la portée et certaines têtes de notes "exotiques".
Nous en avons profité pour améliorer le résultat.
Dans la version publique courante :
- Les objets graphiques ne géraient la transparence que si on changeait leur couleur (observez les lignes de portée devant les pieds du musicien dessiné en noir)
- Les objets graphiques étaient mal colorisés, tous les pixels ne prenaient pas la couleur demandée
- Les têtes de notes spéciales effaçaient les lignes de portée
Dans la version Alpha-1 64 bits
- Toutes les transparences étaient inopérantes (on avait oublié de les traiter)
- Les objets graphiques étaient mieux colorisés
Dans la prochaine version Alpha 64 bits
- Les transparences sont gérées comme il faut sur les têtes de notes et les objets graphiques, quelle que soit leur couleur
Ceci va donc changer légèrement l'aspect des anciennes partitions utilisant ces fonctionnalités
Bon week-end ! |
|
|
| by Olivier Guillion |  |
| |
|
La version 9.8.2 alpha 1 d'Harmony Assistant pour Windows 64 bit peut être téléchargée depuis hier : Plus de renseignements ici
Avec les premiers retours, nous avons corrigé un crash dans une fonction d'affichage de dessins en mode "16 bits par couleur", mode très très peu utilisé.
Malheureusement, une seule icône de l'interface, l'outil "seringue" dans le jeu d'icône "2004" utilisait ce mode.
Et 2004 est le jeu d'icône par défaut de l'application depuis devinez quand.
Donc, crashs au démarrage lors de l'utilisation de ce jeu. Ce sera corrigé dans la prochaine, en attendant, il suffit de changer de jeu d'icône avec la version publique et le tour est joué.
Nous avons également corrigé le désinstallateur, qui ne faisait rien. Là il faudra attendre la prochaine version pour tester ça.
Coté Harmony Assistant lui-même, dans toutes les versions, le "fading" (balance avant-arrière) des instruments n'était pas sauvegardé. Ce sera fait dans la prochaine, mais au prix d'un changement de format de fichier, ce qui implique que les anciennes versions du programme ne chargeront pas ces nouveaux fichiers. |
|
|
| by Olivier Guillion | |
| |
|
Tant qu'on y était, on s'est dit qu'on pouvait faire les grosses modifications de structure qu'on rechignait à entreprendre jusqu'ici.
Celle-ci ne change pas les fonctionnalités, mais clarifie notre code source:
historiquement, sur Mac OS, les premières gestion des transparences, c'est-à-dire les zones qui, sur une image, laissent voir ce qu'il y a derrière, ont été construites avec
0 = opaque,
et
valeur maximum = transparent
Donc une valeur de transparence à 0 montrait ce pixel de l'image, et une valeur de transparence au maximum laissait voir ce qu'il y avait derrière
Or, avec l'arrivée de la "couche alpha", les valeurs de transparence stockées dans les images graphiques de type PNG, les valeurs correspondaient à l'opacité, soit
0 = transparent
et
valeur maximum = opaque
ACAM, notre système de compatibilité entre plateformes, est vieux, et lorsque nous avons commencé à mettre en place notre propre système de transparence, devançant celui système, nous avons choisi d'utiliser les valeurs de transparence que nous connaissions à l'époque.
Résultat, dans ACAM, il y avait en permanence des conversions de couche alpha d'un système à l'autre : chargement d'un PNG, inversion de la couche alpha, et à nouveau inversion pour le faire apparaître à l'écran. A tel point que nous étions nous-même perdus et ne savions plus si 0 était transparent ou opaque.
Nous avons donc repris tout cela, pour toujours utiliser la nouvelle nomenclature, soit 0=transparent.
Mais cela se situait à un très bas niveau, donc impactant la totalité des affichages graphiques, et nécessitant une bonne cinquantaine de modifications.
Cela retarde la sortie de la version alpha d'un jour ou deux, mais cela permettra de le faire tester nos modifications en profondeur. |
|
|
| by Olivier Guillion | |
| |
|
Dans les jours qui viennent, nous envisageons de fournir aux personnes intéressées une première version alpha d'Harmony Assistant pour Windows en 64 bits
Sur la feuille de route, les points suivants ont été remplis:
Création d'une version 64 bits du programme d'installation
Création d'une version 64 bits du désinstallateur
Mise au point des opérations de scellement / Contrôle d'intégrité des versions 64 bits
Création des premières archives complètes en 64 bits
Vérification du résultat de l'installation de ces archives
Restent encore à faire :
Correction de problème dans l'installateur en version publique (non déboguable)
Tests de la procédure de désinstallation
Correction d'un problème de rafraîchissement graphique sur le "splash screen" d'Harmony Assistant
Gestion des codes d'enregistrements pour cette version alpha - x64, afin de permettre de tester dans de bonnes conditions |
|
|
| by Olivier Guillion | |
|
| |
|
On termine sur les exports vectoriels améliorés.
Export SVG
L'export SVG a été validé, la taille des fichiers générés est à peu près identique à auparavant
Une erreur d'analyse des tracés de caractères faisait "oublier" certains traits lors de l'affichage de police en mode "relief" (contour). Ceci a été corrigé
Export PDF
Certaines configurations pouvaient amener à des fichiers PDF illisibles (vrai dans la version publique courante). Ces cas ont été traités
Les caractères dessinés en mode "relief" (contour) disparaissaient du PDF. Les gérer demanderait une duplication de toutes les polices encapsulées en version pleine et version contour. Pour l'instant, nous avons donc simplement éliminé cette information de style, et les caractères apparaissent pleins.
Export Myrweb
Cet export a été repris pour gérer les nouveaux fichiers SVG (dessin de la partition) générés.
Bon week-end à tous ! |
|
|
| by Olivier Guillion | |
| |
|
Pour finir la série "export graphique des partitions en vectoriel", nous avons donc réécrit l'export SVG, qui sert également à l'export Myrweb et à l'export PDF.
Cet export a sans doute été le plus rapide à être fonctionnel (on commence à avoir le coup de main, maintenant)
Il va cependant demander des ajustements et optimisations, car contrairement aux exports WMF ou EPS, celui-ci sert à l'affichage en temps réel des partitions dans Myrweb. Il faut donc que les données SVG soient compactes et bien optimisées. Pas question, par exemple, de tout tracer en courbes de Bezier, comme pour les autres exports. On peut en effet s'attendre que pour tracer une ligne horizontale, ce soit plus rapide de passer par la commande "Line" que par un tracé de Bezier avec 2 points et 2 autres points d'inflexion confondus, même si, graphiquement, le résultat est identique. |
|
|
| by Olivier Guillion | |
| |
|
Puisque nous sommes dans la normalisation de toutes les fonctions qui exportent la partition au format graphique, nous continuons tant qu'il en reste.
Après les affichages à l'écran, l'export au format PCT, l'impression sur MacOS, l'impression sur Windows, puis les exports WMF et EMF, nous avons attaqué l'export EPS
Là aussi, même topo, il s'agit d'écrire 3 ou 4 fonctions spécifiques (fenêtrage, tracés de courbes de Bézier, tracés de textes, tracés d'image) qui vont compléter un tronc commun à tous ces exports.
Si on ne regarde pas de trop près (quelques petits détails graphiques sont encore à améliorer), l'export EPS est fonctionnel.
A noter que cet export sert également aux impressions sur Linux.
Il restera ensuite à réécrire de la même façon l'export SVG, sur lequel sont basés l'export PDF et l'export Myrweb. |
|
|
| by Olivier Guillion | |
|
| |
|
L'impression sur Windows fonctionne.
Nous avons donc entamé une fonctionnalité qui en dépend, l'export WMF/EMF. Il est maintenant terminé, mais nous nous posons des questions sur l'opportunité de conserver cet export.
En effet, ce format vectoriel ne permet apparemment pas d'inclure les polices de caractères utilisées. Il faut donc, pour visualiser un fichier WMF / EMF exporté, il faut donc que les polices musicales (SToccata, etc) soient installées dans le système de la personne qui le visualise.
Pas très pratique... |
|
|
| by Olivier Guillion | |
| |
|
L'impression sur Windows est presque fonctionnelle. La totalité des objets se tracent, seuls demeurent des problèmes de masque d'image, qui ne sont pas gérés directement par l'imprimante : alors qu'à l'écran on voit au travers des zones transparentes de l'image, sur l'impression l'image efface le texte
Tout le reste fonctionne correctement. |
|
|
| by Olivier Guillion | |
| |
|
Nous avons re-compilés nos librairies et 32+64 bits ainsi qu'Harmony Assistant. Les installateurs ont été créés et testé.
Une version 32+64 release d'Harmony Assistant a été installée.
L'utilisateur peut choisir s'il lance la version 32 bits ou la version 64 bits.
Il reste à passer maintenant nos installateurs en 64 bits.
Bon week end ! |
|
|
| by Didier Guillion |  |
| |
|
Nous avons profité du passage en 64 bits pour uniformiser les fonctions internes d'impression, afin de faciliter le portage entre les diverses plateformes.
Ainsi, nous avons maintenant besoin, au minimum, de seulement 3 fonctions de tracé graphique sur l'imprimante pour définir une nouvelle plateforme:
- Tracé de courbes de Bézier
- Tracé de texte
- Tracé d'image
Sur Windows, nous avons donc pour ainsi dire mis à la poubelle toute la partie gérant l'impression, pour réécrire seulement ces trois fonctions.
Le tracé des courbes de Bézier est écrit et fonctionnel
Le tracé de textes est quasiment terminé
Le tracé d'image reste à écrire |
|
|
| by Olivier Guillion | |
| |
|
L'impression est totalement fonctionnelle.
Correction du calcul des scan-codes clavier.
Ouverture du manuel depuis la boite de recherche.
Connection avec PDFtoMusic et traitement des fichiers PDF
Gestion des touches de déplacement dans les textes.
|
|
|
| by Didier Guillion | |
| |
|
Une version "diffusion" d'Harmony Assistant en 64 bits pour Windows a été générée, et fonctionne correctement, à quelques petits détails graphique près.
Nous envisageons donc une version alpha pour très bientôt, dès que nous aurons fini de compiler en 64 bits la pléthore de petits programmes satellites nécessaires : installateur, désinstallateur, scellement, décompacteurs audio, etc
Bon week-end ! |
|
|
| by Olivier Guillion | |
|
| |
|
Nous avons travaillé sur la palette de changement de style et en particulier sur la liste des polices.
Nous avons commencé a reprendre l'impression en utilisant le kit générique d'interprétation des pictures. Cela devrait nous apporter une meilleure precision.
Bon week end ! |
|
|
| by Didier Guillion | |
| |
|
La version 64 bit pour Windows fonctionne maintenant très bien, en version débogage (version lente et lourde, destinée à nous permettre de repérer les problèmes).
Nous tentons une première compilation en version "diffusion", celle qui peut être proposée au public. Cela met en évidence quelques problèmes graphiques, et un gros, gros problème dans la nouvelle gestion de la mémoire, reprise à l'occasion du portage 64 bits. Ce problème est en passe d'être corrigé.
Lorsque la version "diffusion" sera un peu plus stable, il sera possible de proposer une version alpha, que ceux qui le veulent pourront tester. Elle ne sera, dans un premier temps, disponible que sur Windows (Vista, 7, 8 et 10).
Si certains d'entre vous utilisent une version 64 bits de Windows XP, qu'ils se fassent connaître, ils pourront nous dire si le programme fonctionne dessus. |
|
|
| by Olivier Guillion | |
| |
|
Nous reprenons un à un les différents éléments de l'interface Acam Mac pour les faire ressembler le plus possible à l'aspect attendu.
En particulier les potentiomètres linéaires, les ascenseurs, les barres de titre.
Cela commence à plutôt bien fonctionner ! |
|
|
| by Didier Guillion | |
| |
|
L'export SVG/PDF rencontre des problèmes dans la gestion de l'encapsulation de polices OTF (Open Type Font).
Certaines de ces polices contiennent les tracés de caractères en format CFF (Compact Font File) qui n'est pas reconnu par Harmony Assistant.
Dans ce cas, ce dernier devrait simplement ne pas inclure la police dans le fichier résultat et la traiter comme un texte standard (qui ne serait visualisé correctement que si la police en question est installée sur le système de celui qui visualise le fichier).
Un problème dans la gestion empêche ce système de fonctionner correctement, et génère alors des fichiers corrompus.
Le problème sera corrigé dans la prochaine version, mais les polices OTF/CFF ne seront tout de même pas incluses, car cela nous obligerait à écrire des fonctions très complexes d'extraction de données graphiques, ce qui n'est pas dans nos priorités.
Mais les fichiers générés devraient alors être valides.
|
|
|
| by Olivier Guillion | |
| |
|
La version Acam sur Mac permettra aux applications de proposer différents aspects de l'interface. Un de ses aspects sera le plus proche possible de ce que l'on trouve dans les différentes interfaces MacOs. Apple a pour coutume de changer quelques détails à chaque version de son OS.
Il y a eut une rupture entre mac OS 9 et les premiers aspects de mac OS X: éléments avec beaucoup de dégradés, de relief, d'ombres.
De version en version, l'interface s'est lissée pour se rapprocher de se que l'on trouve sur téléphone mobile et pour aboutir à quelque chose d'encore plus minimaliste que mac OS 9 et certainement moins lisible.
Nous travaillons donc actuellement sur cet aspect "mac OS X" d'Acam.
|
|
|
| by Didier Guillion | |
| |
|
Nous avons réécrit une fonction de très bas niveau de notre couche système, le "rescaling d'image" : lorsqu'un élément graphique est affiché à l'écran à une taille différente que celle d'origine, il faut faire une mise à l'échelle, en calculant des valeurs de couleur intermédiaire entre les pixels.
Sur les éléments de l'interface, ou chaque pixel compte, le rescaling rapide que nous utilisions montrait quelques faiblesses. La nouvelle fonction, plus exacte mathématiquement, est aussi plus lente. Il va falloir que nous vérifions que le ralentissement n'est pas trop important.
Graphiquement, voici une image avant-après de certains éléments:
Pour gérer correctement les fenêtres à bords arrondis sur MacOS (sur ce système, il est théoriquement possible de créer des fenêtres circulaires, ou bien trouées comme de l'emmental), nous devons reprendre l'ensemble des thèmes graphiques proposés avec l'application. C'est en cours.
Enfin, coté serveur Web, notre durcissement des tests lors de l'inscription sur notre forum semble avoir endigué l'avalanche d'inscriptions de bots et de comptes bidons que nous avions observée ces derniers mois. Profitons-en, avant qu'ils ne trouvent la parade...
Bon week-end ! |
|
|
| by Olivier Guillion | |
|
| |
|
Mise en place des boîtes système de sélection de police et de couleur.
Gestion de l'ordre des fenêtres et des fenêtres flottantes.
|
|
|
| by Didier Guillion | |
| |
|
Des imprécisions mathématiques nuisent à la qualité d'affichage des objets de l'interface réduits ou agrandis.
Par exemple, les cases à cocher existent en deux formats, normal et petit, le second utilisant les mêmes graphismes que le premier, mais en les réduisant à l'affichage.
Nous essayons donc que le résultat à l'écran soit plus satisfaisant (dès que ça fonctionne, on vous montre des captures d'écran, promis) |
|
|
| by Olivier Guillion | |
| |
|
|
