Le Dock peut maintenant être positionné sur n'importe quel bord de l'écran :
Toutes les opérations fonctionnent quelle que soit la position. Il reste quelques détails graphiques à régler (position dans la musique et ligne d'aide en mode vertical, notamment) |
|
|
| by Olivier Guillion |  |
| |
|
Premiers essais de configuration graphique du Dock, pour l'adapter aux goûts de l'utilisateur.
Il sera possible de modifier:
- La saturation des couleurs (déjà implémenté)
- Le fond simili-3d de chaque icône (absent dans la version beta)
- La vitesse d'animation des 3 icônes d'édition
- Le type d'animation des 3 icônes d'édition : aucune, fondu ou pivotement
- L'opacité des rappels d'outils qui défilent dans les 3 icônes d'édition
- La position du dock sur l'un des 4 cotés de l'écran
Ces réglages devraient se faire dans un onglet de la boite d'édition des préférences générales de l'application. |
|
|
| by Olivier Guillion | |
|
| |
|
Nos récents déboires avec un utilisateur coréen nous ont fait prendre conscience que nos installateurs sur Windows ne géraient pas les accentués dans les noms de fichiers et dossiers de manière satisfaisante.
Ils utilisaient les jeux de caractères 8 bits, qui pouvaient varier en fonction de la langue de l'utilisateur. Dès qu'un caractère accentué ou non latin était présent dans un nom de fichier ou de dossier, l'installateur risquait de ne pas fonctionner correctement.
Nous avons donc repris la totalité des accès aux noms des éléments (et dans un installateur, il y en a un paquet) pour les passer en Unicode, jeu de caractère étendu qui permet de gérer toutes les langues.
Cela a nécessité l'écriture de 1200 lignes de code supplémentaires.
Une fois testé, il a fallu faire en sorte que l'installateur fonctionne tout de même sur des systèmes ne gérant pas l'Unicode (Windows 98 et précédents).
Sur ces vieux systèmes, les utilisateurs Coréens risquent donc de rencontrer encore des problèmes d'installation, mais nous devons avouer que cela ne constitue pas l'une de nos priorités. |
|
|
| by Olivier Guillion | |
| |
|
L'une des simplifications d'écriture les plus fréquente, et la plus génératrice d'erreurs est l'utilisation de tuplets (triolets) sous-entendus.
Dans cette notation, les triolets sont écrits comme il faut, avec un petit "3" au-dessus, uniquement sur la première mesure. Le "3" est ensuite omis sur tous les triolets qui suivent, l'interprète étant supposé comprendre qu'il faut continuer à appliquer les triolets tout pareil.
Parfois, le premier "3" n'est même pas présent. Ce sont les ligatures, la métrique et la comparaison rythmique avec les autres portées qui doivent indiquer qu'il s'agit de triolets.
Inutile de préciser que ce genre de notation, du type "on voit que", ou "parce que c'est plus logique" n'est pas vraiment du goût d'un programme de reconnaissance optique comme PDFtoMusic. Les ratages sur cette notation sous-entendue sont clairement audibles, et difficilement réparables après coup.
Nous avons donc pas mal travaillé sur la détection de ce genre de cas, et notamment sur la correction par comparaison avec les autres portées. Les triolets sous-entendus sont détectés plus souvent, et le traitement de certaines partitions s'en voit grandement amélioré.
Mais comme d'habitude avec ce type de modification profonde, il faut maintenant s'assurer, en traitant quelques milliers de fichiers, que la détection ne s'opère jamais à mauvais escient. |
|
|
| by Olivier Guillion | |
| |
|
Un utilisateur Coréen nous a contacté pour nous avertir que la version d'Harmony Beta ne s'installait pas correctement sur son Windows 10 version coréenne.
Le message d'erreur indiquait qu'un fichier, dont le nom contenait des accentués (les versions précédentes de l'application ne contenaient aucun nom de ce type) ne pouvait pas être copié correctement.
Par chance, Windows 10 permet facilement de changer de langue. Nous sommes donc passés en Coréen, et avons alors obtenu des boîtes de ce type:
Tant bien que mal, nous sommes parvenus à tester l'installation d'Harmony Beta... qui s'est déroulée sans problème.
Nous avons donc cherché, avec l'utilisateur, quel autre paramètre pouvait produire une erreur, et après plusieurs essais infructueux, l'avons trouvé au même moment :
Il s'agit de la langue pour les programmes non Unicode, cerclée en rouge sur l'image. Lorsque ce paramètre est fixé à une langue qui n'utilise pas l'alphabet latin, les accentués dans les noms des fichiers ne sont pas correctement pris en compte. Le problème doit donc se produire également en Chinois, Japonais, mais peut-être aussi en Russe ou en Grec.
Le point très positif est que nous n'aurons pas à changer la langue de Windows pour tester l'installateur, ce qui devrait nous permettre de vérifier le fonctionnement directement sur notre machine de développement.
Parce que ouvrir quelques boîtes et cliquer sur quelques boutons en Coréen, cela peut se faire par essai et erreur, mais utiliser vraiment le système aurait probablement posé quelques problèmes. Ne pas comprendre qu'il est écrit "Désirez-vous supprimer définitivement ce dossier?" peut facilement provoquer une catastrophe. |
|
|
| by Olivier Guillion | |
| |
|
Journée optimisations et accélérations:
L'export MIDI de partitions très longues, contenant de nombreuses répétitions (donc un grand nombre de mesures jouées) pouvait prendre un temps considérable, jusqu'à plusieurs minutes.
Un pré-calcul de correspondance entre temps joué et mesure écrite a permis de diviser ce temps par environ 50.
Le programme effectue souvent des recherches dans des tableaux organisés selon une valeur croissante. Lorsque le temps de traitement était crucial, nous avions mis en place une recherche dichotomique (pour un tableau de 1000 éléments, cette recherche n'effectue que 10 comparaisons au lieu de 500 en moyenne).
Une comparaison dichotomique polyvalente a maintenant été écrite, et nous permettra d'accélérer aussi les recherches de moindre importance.
Bon week-end ! |
|
|
| by Olivier Guillion | |
|
| |
|
- Travail sur le Dock, pour répertorier les icônes dont le placement n'est pas logique et mériterait d'être amélioré, ainsi que des icônes encore absentes.
- Finalisation de la refonte de nos pages de commande, mais pas encore mise en ligne publiquement
|
|
|
| by Olivier Guillion | |
| |
|
Nous nous sommes à nouveau heurtés à un problème de détermination automatique de langue par Virtual Singer.
Le filtre de détermination Bayésien évalue les probabilité de présence de groupes de lettres consécutives dans le flux de caractères des paroles des chansons. Par exemple, s'il y a écrit : "Le temps des cerises", il va étudier le flux : "LETEMPSDESCERISES", en évaluant la probabilité de trouver tout à tour dans des textes français, anglais, italiens... les combinaisons LE, ET, TE, EM, PS, SD, DE, ES, ... ainsi que LET, ETE, TEM, EMP, MPS...
En comparant les résultats de chacune des langues, il détermine laquelle est la plus probable.
Mais, si les paroles contiennent une syllabe répétée de nombreuses fois par exemple: "You Oh La La La La La La Oh Yeah La La La La La La", le résultat dépendra principalement de la probabilité de rencontrer la syllabe "La" dans chacune des langues.
Le texte d'exemple est en anglais, mais "La" a plus de chance de se trouver dans des textes français (ou espagnols). Etant donné que cette syllabe est surreprésentée dans le texte à analyser, le calcul est faussé et tend à trouver "français" plutôt qu'anglais.
Nous avons donc mis en place un système qui limite le nombre de combinaisons identiques à analyser dans un même texte. Dans l'exemple, le programme analysera donc "YOUOHLAYEAH", en supprimant les "La" et "Oh" répétés, et trouvera probablement l'anglais.
Ceci devrait donc permettre une meilleure détermination de la langue, mais devra d'abord être testé sur un maximum de fichiers avant d'être validé.
|
|
|
| by Olivier Guillion | |
|
| |
|
|
