À la question sur le recalcul de la liste des mesures imposées, dans le billet d'il y a trois jours, la réponse était qu'il n'y a pas de bonne réponse.
Cela dépend entièrement de ce que l'utilisateur aurait envie de faire, et que le programme ne peut pas deviner. Poser la question à l'utilisateur par le biais d'une boîte est bien entendu faisable, mais là aussi, si c'est informatiquement et logiquement correct, c'est humainement inadéquat.
Le programme, au moment où il est en mesure de traiter le problème, sait seulement combien de mesures sont ajoutées et à quel endroit.
Afin de réagir correctement quand l'utilisateur insère une mesure à la fin, ou sépare la mesure en deux en posant une barre de mesure, une clé ou un changement de tonalité au milieu de la mesure, priorité sera donnée à l'extension de la mesure précédente.
Par exemple, si 2 mesures sont insérées entre la mesure 14 et 15:
- lorsque les mesures 1 à 13 étaient jouées, elles le seront toujours
- lorsque la mesure 14 était jouées, cela jouera les mesures 14, 15 et 16 (les mesures 15 et 16 sont celles qui ont été insérées)
- Lorsque les mesures 15 à la fin étaient jouées, cela jouera les mesures 17 à la fin (nouvelle numérotation)
Mais, dans le cas où la mesure 14 n'était jamais jouées, les deux mesures ajoutées se placeront avant l'ancienne mesure 15. Lorsque cette dernière était jouée, cela jouera maintenant les mesures 15, 16 et 17
Dans l'immense majorité des cas, cela fera ce que l'utilisateur attendait. Pour les cas limites, il aura peut-être à reprendre la liste à la main.
Donc, pour ce qui est de la devinette d'il y a trois jours, nous avons opté pour (mais, je le rappelle, il n'y a pas de "bonne" réponse):
1-12, 5-8, 13-22
|
|
|
| by Olivier Guillion |  |
|
| |
|
Lorsque l'utilisateur impose une liste de mesure à jouer, le programme considère que la liste des mesures données est définitive.
Cela signifie que si on insère des mesures au milieu après avoir imposé la liste, ces nouvelles mesures ne seront pas jouées.
C'est informatiquement correct, logiquement pas complètement dénué de sens, mais... ce n'est pas ce qu'attend l'utilisateur.
S'il demande de jouer les mesures 2 à 20, puis qu'il insère 4 mesures en mesure 15, il s'attend à ce que le programme joue les mesures de 2 à 24, et non, comme c'est le cas actuellement, les mesures 2 à 14 puis 19 à 24.
Nous avons donc repris les algorithmes de recalcul des mesures jouées après insertion ou suppression de mesure afin de prendre ceci en compte.
Ce sera donc plus conforme aux attentes de l'utilisateur, même si dans certains cas limites, cela ne fera peut-être pas ce qui est attendu.
Par exemple, si la séquence suivante est jouée:
1-10, 5-8, 11-20
et qu'on ajoute deux mesures avant la mesure 11, doit-on obtenir:
1-10, 5-8, 11-22
ou bien
1-12, 5-8, 13-22 ?
J'en vois qui ne suivent pas, là, au fond !  |
|
|
| by Olivier Guillion | |
|
| |
|
Ca y est, l'algorithme de décomposition/recomposition des accords a été mis au point.
Il a été testé sur plusieurs dizaines d'accords les plus bizarres possibles (par exemple Dm#5b9#11#13 ) et n'a pas pu être mis en défaut jusqu'ici.
Nous corrigeons maintenant une série d'erreurs pouvant survenir lorsque le nom de l'accord proposé est vraiment hors bornes (un texte complet de plusieurs centaines de caractères ayant été pris comme un nom d'accord par exemple) afin d'éliminer les crashs dans ces cas limites.
|
|
|
| by Olivier Guillion | |
| |
|
Nous sommes en train de griller les rares neurones qu'il nous reste sur la nomenclature des accords.
Nous avons réussi à décomposer n'importe quel type d'accord (jusqu'à la 13e) en ses composantes à partir de son nom.
Mais, pour l'export XML, il s'agit maintenant de retrouver à quel accord de base (une trentaine de choix possibles) il correspond, et quels ajustements sont à apporter à cet accord de base pour reconstituer l'accord d'origine.
Il faut ici mettre en oeuvre toutes nos connaissances, et parfois cela ne suffit pas.
Sur l'accord, par exemple (notation anglo-saxonne) C9#5, on peut considérer qu'il s'agit d'un accord augmenté de septième auquel on ajoute une neuvième, ou un accord de neuvième dont on augmente la quinte d'un demi-ton.
Il y a très souvent plusieurs manières de parvenir au même accord, et certains logiciels qui lisent le MusicXML attendent le "bon".
Il va donc y avoir d'autres neurones de grillés d'ici demain.
|
|
|
| by Olivier Guillion | |
|
| |
|
Derniers ajustements sur les archives .deb installables en Linux 64 bits, pour assurer la compatibilité avec Ubuntu 13.10 :
- La base Gold a été reprise, afin de supprimer l'alerte de "paquet de mauvaise qualité" (sic !  ) ainsi que les messages d'erreur lors de l'installation. A noter que la base s'installait quand même, mais cela pouvait faire légitimement s'interroger l'utilisateur. Avec une taille de fichier considérable (l'adjectif nous fera bien rigoler dans 10 ans) de 470Mo, les différents tests ont pris un peu plus de temps que d'habitude.
- Le plug-in est en cours de correction. La liste des dépendances minimales a été trouvée par essai et erreur, ce qui semble être la procédure la plus carrée sur Linux. Il faut maintenant finir de tester le résultat en le réinstallant sur une machine tout neuve, ce qui semble être aussi le seul moyen d'être sûr que ça fonctionne.
Toutes ces opérations, qui nous ont occupé environ deux jours, sont seulement destinées à faire fonctionner les programmes exactement comme avant, pas à les améliorer. Mais nous avons vu d'autres logiciels où les programmeurs s'embêtaient apparemment moins que nous, fournissant simplement sur une page Web une vingtaine de commandes à taper à la main pour faire passer les anciens paquets. A vue de nez, un utilisateur Linux sur 3 est incapable de suivre ce genre de procédures et s'arrête au premier point : "1. Loguez-vous en root".
Bon week-end à tous ! |
|
|
| by Olivier Guillion | |
|
| |
|
Pour les versions Windows (et Linux) de nos programmes, nous avons créé un aspect "Windows 8" (en fait, Windows 8.1) :
Les amateurs de Windows 8 peuvent vérifier ici que la clarté esthétique a été parfaitement respectée. L'interface est tout aussi mal fichue que l'original.
Certains détails de l'interface (titres centrés, boutons au ras du bord...) ont nécessité une amélioration du module de personnalisation graphique de notre système ACAM.
|
|
|
| by Olivier Guillion | |
|
| |
|
Les nouvelles archives Linux d'Harmony/Melody pour Ubuntu 64 bits ont été à nouveau testées sur une installation fraîche. Nous essayons de résoudre le problème qui demeure sur le plug-in. Pour l'instant, nous n'avons eu aucun retour de Linuxiens à propos de cette mise à niveau.
Toujours dans le cadre de l'installation, un fichier manquant (gdiplus.dll) empêchait l'application de fonctionner juste après installation sur Windows 2000.
Pour permettre cela, nous avons dû reprendre le programme d'installation afin de lui faire gérer des tests de version plus finauds, par exemple, l'installation d'un fichier sur les versions de Windows allant de 6.0 (Windows Server 2008 ) à 6.1 (Windows 7) seulement.
A ce sujet, si vous désirez connaître les vrais numéros de version de Windows, vous pouvez aller voir ici. Car numéroter Windows 7 en 7.0 et Windows 8 en 8.0 eût été bien trop simple ! |
|
|
| by Olivier Guillion | |
| |
|
Le PC sous Windows est maintenant pleinement opérationnel. Toutes nos machines virtuelles (Linux, Windows 98, Windows 2000 ou XP) fonctionnent, et nous avons pu recompiler même les projets complexes, notamment la librairie qui permet à MyrScript de montrer des films et vidéos dans Harmony Assistant.
Les versions Windows 98 de nos programmes ont été recompilées, et modifiées de manière à continuer à fonctionner sur ce (très) vieux système.
Le plug-in a été testé sur Firefox et Internet Explorer sous Windows 8.1, et semble fonctionner sans problème. |
|
|
| by Olivier Guillion | |
|
| |
|
|
