Nous avons reçu quelques dizaines de réponses à l'enquête sur l'application musicale pour smartphone/tablette, et nous avons commencé à mettre en place un frontal Web nous permettant d'analyser les résultats.
Pour l'instant, l'échantillon est insuffisant pour dégager une tendance claire sur ce qui serait majoritairement désiré.
Mais ceci ne nous empêche pas de chercher des solutions aux problèmes principaux que soulèverait dès le départ une telle application :
1- La réutilisation du code déjà écrit. Il faut absolument que nous puissions réutiliser directement tout ou partie des millions de lignes de C de nos applications "bureau". Une réécriture dans un autre langage serait un travail trop important.
2- Si possible, la portabilité entre les divers systèmes de smartphones (iOS, Android, Windows Phone). A moins de réduire dès le départ le parc potentiel à un seul système, il faudrait trouver une manière de développer simplement sur plusieurs systèmes en même temps
3- Enfin, contourner les coûts exorbitants des plateformes de mise à disposition des App (sauf pour Android qui permet d'installer des applications provenant d'ailleurs que leur propre boutique), qui augmentent mécaniquement le prix de l'App de plus de 30%, et les politiques arbitraires d'acceptation des Apps, qui pourraient conduire à notre bannissement si Apple ou Microsoft considèrent un jour que notre app fait concurrence à l'une des leurs (ou que notre tête ne leur revient pas)
Nous cherchons donc une solution satisfaisante à ces trois problèmes. Nous avons trouvé quelques pistes, rares mais prometteuses, que nous sommes en train d'explorer. |
|
|
| by Olivier Guillion |  |
| |
|
Quelques partitions posaient problème à PDFtoMusic, et nous ont contraint à nous replonger dans des fonctions complexes, et délicates à ajuster.
Il s'agit de l'attribution des voix dans une portée. Écrire plusieurs voix sur une même portée peut conduire à des notations peu claires, où seuls le contexte et la logique permettent de déterminer ce qu'il faut faire.
À la veille de ce week-end électoral, nous ne pouvions pas passer à coté d'un problème de comptage des voix 
Prenons par exemple ce cas, écrit dans une partition non mesurée (pas d'indication de métrique):
On voit tout de suite qu'il s'agit de 4 groupes de noires, avec deux voix sur la portée. Mais le "on voit" est un concept qu'un programme peut avoir quelques difficultés à appréhender.
Imaginons maintenant le même exemple, mais avec un espacement plus grand entre les notes des différentes voix :
Malgré l'espacement supplémentaire, on comprend qu'il s'agit du même schéma que précédemment, toujours une mesure en 4/4.
Mais si on a ceci :
ça devient beaucoup moins évident. Il est fort probable qu'il s'agisse là de 8 croches (mesure en 8/4) avec une seule voix. Le résultat est totalement différent de précédemment.
À partir de quel espacement doit-on considérer l'un ou l'autre cas ? C'est ce que nous avons essayé de résoudre. Même si le nouveau calcul n'est pas parfait, il devrait améliorer la détermination des voix de manière sensible.
Bon week-end ! |
|
|
| by Olivier Guillion | |
|
| |
|
La gestion des écrans Retina / 4k / 5k a été finalisée.
Le bouton dans la boîte configuration (rubrique "Ecran") d'Harmony Assistant permet de sélectionner / désélectionner ce mode.
Nous avons repris la correction des problèmes soumis par les alpha-testeurs :
Correction de l'espacement des polices en mode étendu et condensé
Accélération de l'affichage des fenêtres pour améliorer la fluidité des redimensionnements
Amélioration de l'aspect des textes dans l'édition des scripts (priorité a été donnée à la qualité au détriment de la précision)
Amélioration de la boîte de sélection de dossier (un simple clic suffit à ouvrir un sous-répertoire)
Correction d'une erreur dans la sélection de dossier depuis un script (fonction GetFolderName())
Dans un autre domaine, certains utilisateurs de Linux nous ont signalé des difficultés d'installation de la base GOLD téléchargée. Nous avons mis en place une procédure d'installation alternative qui devrait résoudre tous ces problèmes. Un message en ce sens sera indiqué sur la page de téléchargement de la base (réservé aux utilisateurs enregistrés).
Et enfin, le questionnaire au sujet d'une éventuelle application musicale made in Myriad pour smartphone ou tablette a été mis en ligne et est opérationnel.
Si vous êtes susceptible d'être intéressé par une telle application et que vous n'avez pas encore répondu à cette enquête, nous vous invitons à le faire depuis cette page. |
|
|
| by Olivier Guillion | |
| |
|
Le mode "loupe", annoncé dans un billet précédent, et destiné aux écrans haute définition, fonctionne maintenant. Il en reste plus qu'à corriger une poignée de bugs graphiques et nous pourrons alors considérer cette option comme terminée, et passer à autre chose.
Une belle liste de points à corriger, détectés par les alpha-testeurs, nous attend encore, mais la version Linux commence à devenir de plus en plus fonctionnelle.
|
|
|
| by Olivier Guillion | |
| |
|
Nous recevons régulièrement des demandes de portage de nos applications sur matériel nomade (smartphone ou tablette).
Une adaptation directe d'Harmony Assistant, avec menus et double-clic n'étant pas envisageable, nous essayons de comprendre quels sont les besoins exacts des personnes intéressées.
Pour cela, nous venons de mettre en place un système d'enquète/sondage/questionnaire, qui pourra éventuellement servir à l'avenir pour d'autres sujets.
Il vient d'être mis en ligne, mais n'est pas encore définitif. Nous vous invitons cependant à le tester, et à nous faire part de vos remarques. Si quelque chose ne fonctionne pas, si une question n'est pas claire, ou si vous pensez qu'on en a oublié une, n'hésitez pas à nous le dire, il est encore temps !
La version d'essai du questionnaire est ici :
http://www.myriad-online.com/cgi-bin/qcm.pl?n=app&l=fr
Allez-y sans crainte, les réponses au questionnaire que vous donnerez jusqu'au lancement de l'enquête le mardi 24 mars 2015 ne seront pas prises en compte, et vous serez alors invité à remplir à nouveau la fiche après cette date.
Merci d'avance ! |
|
|
| by Olivier Guillion | |
|
| |
|
Avec les iMac 5K, on commence à voir arriver des machines équipées d'écrans "Retina" haute définition (ici, le 27" en 5120 x 2880 pixels)
Ceci n'est cependant pas l'apanage d'Apple, puisque de tels écrans existent pour PC depuis quelques mois (à condition d'avoir une carte graphique qui tienne le choc), et leur prix commence à devenir abordable. Par exemple, Dell propose un 24" en 4k, et un 27" en 5k, équivalent à celui qu'Apple a intégré à l'iMac.
Sur de tels écrans, si on continue à afficher les fenêtres avec le même nombre de pixels, elles vont apparaître minuscules, et le tout sera difficilement lisible pour les plus de 40 ans.
Sur Mac, le système a été adapté. Les applications continuent à fonctionner comme si l'écran n'était pas aussi fin (elles croient que la résolution de l'écran est 2500 x 1400), et chaque pixel des objets manipulés occupe un carré de 2x2 points à l'écran.
Donc, si on ne touche pas à l'application, les objets restent lisibles, mais ils sont crénelés. Un petit travail est nécessaire pour rendre les applications compatibles avec Retina et affiner le rendu : il faut effectuer les tracés graphiques dans une zone deux fois plus précise avant de les transférer sur l'écran. Il y a ainsi une compatibilité dans les deux sens (une application prévue pour Retina fonctionne correctement sur des écrans classiques)
Sur Windows ou Linux, a priori rien de tel. Une ancienne application a de fortes chances de donner un résultat illisible sur des écrans haute définition (nous n'avons malheureusement pas pu le tester, n'ayant jamais eu un tel écran sous la main).
La solution que nous avons trouvée, après moulte cogitations, est de prévoir dans ACAM un mode spécial qui agrandisse tout d'un facteur 2 (réglable). Une sorte de loupe, qui donnera ceci, en grandeur réelle:
Ce mode pourra également être pratique pour les malvoyants.
Si vous possédez un tel écran, ou que quelqu'un dans vos connaissances en utilise un, nous serions fortement intéressés par les résultats de quelques tests
|
|
|
| by Olivier Guillion | |
| |
|
Nous faisons de notre mieux pour pouvoir poster une nouvelle version alpha avant ce soir. Si nous y parvenons, les beta-testeurs seront avertis individuellement par courrier électronique.
Nous avons grandement amélioré l'impression sous Linux, en permettant d'utiliser des polices de type Adobe Type 1 (PDB) en plus des polices TrueType (TTF).
Nous avons également géré les formats d'image compressés (jpg, png, etc) au niveau du thème graphique, ce qui permettra de proposer des images de fond de bureau moins pixellisées.
Nous avions bien avancé sur la prise en compte du thème graphique MacOS, qui commençait à bien fonctionner :
Mais il reste cependant quelques ajustements graphiques à réaliser, ce qui nous a conduit à exclure ce thème de la prochaine version alpha.
Bon week-end ! |
|
|
| by Olivier Guillion | |
| |
|
Depuis quelque temps, nous travaillons séparément sur trois versions d'ACAM:
La version d'origine, fonctionnant sous Windows
La prochaine version Linux, appelée ACAM-Winter, qui, en minimisant les dépendances avec le système, peut être facilement portée sur d'autres plateformes
Une version Mac (Acam Mac) destinée à remplacer à terme l'utilisation de la librairie de compatibilité "Carbon" avec les anciens systèmes Mac
Avec ACAM, on peut redéfinir complètement l'aspect de l'interface (onglet "Thèmes" des préférences générales d'Harmony)
Mais pour ne pas trop perturber les fragiles créatures que sont les utilisateurs Mac lorsqu'ils feront tourner nos programmes sur leur dernier système à la mode, nous travaillons à reproduire à l'identique l'aspect des fenêtres, des boutons, etc (voir billets précédents à propos d'ACAM Mac)
Afin de permettre de zoomer l'interface pour l'adapter aux écrans Retina, les graphismes ne sont pas stockés sous forme d'image, mais tracés à la demande à l'aide de commandes graphiques.
Ces commandes graphiques étant spécifiques au système Mac (Quartz), le thème en question ne pouvait fonctionner que sur Mac. Dommage de réserver ainsi un aspect (qui a en plus demandé pas mal de travail) à une seule plateforme.
Notre tâche d'aujourd'hui : remplacer les fonctions graphiques Mac/Quartz par des commandes standard ACAM, de manière à pouvoir utiliser le thème graphique Mac sur Windows ou Linux.
Bientôt les premières images... |
|
|
| by Olivier Guillion | |
| |
|
Les problèmes signalés sont presque tous corrigés.
En vrac :
- Amélioration de la gestion de la molette de la souris
- Messages d'avertissements intempestifs lors du décompactage automatique de l'installateur
- Apparition de l'alerte d'application mal terminée à chaque redémarrage
- Sortie incorrecte de l'application si on clique sur la case de fermeture de la fenêtre principale (là aussi, il a fallu fouiller dans les coins pour trouver)
De nombreuses fonctions ont également été accélérées, notamment le démarrage de l'application (entre l'apparition de la fenêtre principale et le moment où l'utilisateur peut commencer à travailler), les effets graphiques de disparition et d'apparition, ainsi que les redimensionnements, mises à jour et déplacement des fenêtres.
Il reste cependant quelques points qui doivent encore être corrigés avant de pouvoir proposer une nouvelle version alpha, et notamment une erreur complexe de décompactage des didacticiels.
Un point cosmétique a été confirmé, mais, n'étant pas crucial, attendra encore un peu: les types de fin de ligne et de connexion entre les segments des courbes de Bézier (bevel, miter et round) ne sont pour l'instant pas gérés.
|
|
|
| by Olivier Guillion | |
| |
|
Le système permettant d'afficher à l'écran des textes qui conservent leurs tailles relatives à toutes les échelles fonctionnant bien sous Linux, nous avons donc décidé de le généraliser, et donc de faire de même sur Windows et MacOS.
Mais pour pouvoir faire cela, il faut que le système permette l'affichage de texte avec une grande précision, au détriment s'il le faut de l'aspect des petites polices. Or, sur Windows, l'interface de tracé graphique GDI que nous utilisions jusque-là et datant de l'origine de Windows ne le permet pas.
Pour avoir ce style de fonctionnalité, il faut utiliser le nouveau système, baptisé GDI+ dans le moment de folie créatrice décennal chez Microsoft.
GDI+ se pîlote en C++, et constitue un jeu entièrement nouveau de fonctions graphiques. Nous avons donc dû entièrement réécrire le module de tracé de texte, dans chacune de ses configurations possibles : en couleur, ombré, détouré, souligné, selon un angle donné, etc.
Les fonctions de texte en GDI+ ne sont pas très bien conçues (c'est le moins qu'on puisse dire) mais nous y sommes tout de même parvenus. Il nous faut maintenant vérifier que notre code C++ est "propre" au niveau mémoire.
Quoi qu'il en soit, un paragraphe en objet libre plus ou moins justifié, dessiné avec un angle, donne maintenant ceci à différents zooms :
A comparer avec le même type d'objet dans la version publique actuelle d'Harmony. |
|
|
| by Olivier Guillion | |
| |
|
Lorsque le système de rendu de texte du système trace des petites polices à l'écran, il s'arrange pour que les petites lettres restent lisibles et soient bien séparées.
Par exemple, si quelqu'un s'amuse à choisir une toute petite police pour la barre de menu, ça va donner ceci :
En voici un détail zoomé à 300%
Même si elles sont petites, le système s'arrange pour que les lettres restent bien espacées et lisibles.
Hélas, cela se fait au détriment de la précision. les largeurs de caractères sont à un pixel près, ce qui peut entraîner des différences de largeur selon l'échelle de visualisation.
Par exemple, dans Harmony Assistant, voici le même texte visualisé à différents zooms :
D'accord, même en petit, les lettres sont bien séparées, mais la justification n'est pas conservée aux différents zooms. Les largeurs relatives des lignes ne sont plus égales.
La solution serait donc de calculer avec beaucoup de précision les largeurs de caractères, et privilégier la conservation des largeurs relatives au détriment de la lisibilité des petites polices.
Le même exemple donne alors ceci :
Là, les tailles relatives des lignes sont conservées aux différents zooms, même si, en petit, les lettres se touchent parfois.
Mais si nous utilisons ce type de tracé dans ACAM, notre exemple de menu du début, qui était :
devient
Ça a l'air tout juste un peu moins beau, mais croyez-moi, de telles petites imperfections sur la totalité de l'interface, ça fait très moche.
Il faudrait donc privilégier la précision dans tous les textes écrits sur les documents (la partition) ou destinés à être imprimés, alors qu'il faudrait privilégier l'espacement agréable des petites polices dans l'interface (boutons, menus, titres, etc).
C'est ce que nous sommes en train de mettre en place. |
|
|
| by Olivier Guillion | |
| |
|
|
