Suite des ajustements sur MyrScript, sur lequel nous a été signalé un problème sur le script "Notation > Ruptures > Linéariser les ruptures". Il s'agissait d'une omission dans le code de la méthode "GlobalBarSetting.CopyTo(...) qui a été corrigée. Un problème de suppression des liaisons entre notes, lorsque celles-ci ne franchissaient pas une barre de mesure, a été signalé par François D. Il a été corrigé. Apparemment, une mauvaise manipulation avait fait "sauter" une ligne de code à ce niveau. Parfois, ça va chercher dans les coins, les choses qu'on ne reteste pas tous les jours : le curseur graphique "nwclike", qui permet de choisir la hauteur et la position de la note à insérer grâce aux touches fléchées du clavier laissait des traces "fantômes" sur la première portée. Ceci a été également corrigé. |
|
|
by Olivier Guillion | | | |
|

Deux problèmes ont été réglés sur MyrScript : - Lors du débuggage d'un script, l'examen avec la fenêtre des variables d'un objet de type "Score" générait une erreur et faisait sortir du mode pas à pas. Ceci était dû à une mauvaise prise en compte par l'afficheur de variables du champ "Views", qui permet d'accéder aux vues par l'intermédiaire d'un script. Cela a été corrigé, et les membres des objets de type "View" peuvent maintenant être examinés comme il faut - Problème ancien : lorsqu'une boîte est construite par le script en ajoutant des objets un par un (et non grâce à une définition par Interface Composer), les objets de type "case à cocher" ou "bouton radio", lorsqu'ils étaient définis après un objet contenant des ascenseur (texte long, sélecteur de longueur ou de forme de note par exemple), ne pouvaient pas être utilisés correctement. Ce sera corrigé dans la prochaine version. Solution temporaire: changer l'ordre de création des objets de la boîte, en faisant commencer par les cases à cocher et les boutons radio. Un problème de crash survenant lors de certains décalages d'octaves a été corrigés. Il était lié au recalcul d'accroches qui est limité, dans cette version, aux notes qui ont été modifiées. Enfin, un problème de calcul de la position par défaut des coulés a été corrigé. Ce problème avait été signalé plusieurs fois mais était assez difficile à reproduire sur demande. Voici la manière la plus simple que j'ai trouvée pour le constater: - "Fichier > Nouveau > Piano seul, main droite et main gauche" - Poser sur la portée en clé de fa une noire en Mi2 et une autre en Ré2 - Poser un coulé entre ces deux notes Cependant, cela dépendait du zoom courant lors de la pose du coulé, donc cela peut varier en fonction de la taille de la fenêtre d'Harmony Assistant. |
|
|
by Olivier Guillion | | | |
|

De petits détails cosmétiques ont été réglés (affichage des effets guitare par-dessus les coulés, même si ces effets avaient été marqués invisibles), et quelques remaniements sur la gestion des numéros de série ont été effectués. Ces remaniements sont nécessaires de temps en temps, afin que les pirates ne puissent pas réinvestir dans la version suivante tout ce qu'ils ont trouvé lors du piratage d'une version. Mais ce qui nous a tenus occupés ces derniers jours est un problème d'apparence assez anodin, mais qui se révèle un vrai mystère. On nous a signalé que les taquets de redimensionnement des portées et des mesures de l'aperçu avant impression n'étaient plus placés au bon endroit. Lors de la vérification des fichiers "source", nous avons suivi maintes fois l'algorithme pour en arriver toujours à la même conclusion : cela n'aurait jamais dû fonctionner jusqu'à maintenant. Imaginez que vous démontiez une montre qui vient de s'arrêter, et qu'à l'intérieur, vous ne trouviez rien d'autre qu'un aimant, un trombone et une bille de verre. Vous vous gratteriez la tête en vous demandant comment la montre a bien pu vous donner l'heure exacte pendant deux ans. C'est ce que nous avons fait ces derniers temps, nous gratter la tête en lisant et relisant les codes source du programme. Il est probable qu'une erreur de programmation avait été compensée exactement par une autre erreur de programmation. Nous avons donc maintenant commencé à réécrire le petit algorithme en fonction de ce qui nous paraitrait logique et en s'abstrayant de ce qui avait déjà été fait, et ça fonctionne. Comme quoi, tout n'est quand même pas si irrationnel. |
|
|
by Olivier Guillion | | | |
|

Lors de la recherche d'algorithmes de détection de formes, nous essayons des dizaines de voies possibles, essayons d'évaluer la qualité des résultats pour chacune d'elles, tout en sachant qu'à la fin, la plupart de ce que nous avons fait partira à la poubelle. Alors nous expérimentons, et essayons d'obtenir, graphiquement quelque chose qui nous permette de visualiser rapidement ce qu'on pourrait tirer de l'utilisation de chaque méthode envisagée. Ainsi, il y a déjà longtemps, lorsque nous travaillions sur la reconnaissance des caractères musicaux individuels dans PDFtoMusic, j'avais déjà posté sur ce blog une représentation en couleur de l'orientation des traits qui forment un caractère. Cette solution n'a pas été retenue dans PDFtoMusic, mais pourrait peut-être se révéler utile dans ScanToMusic. En effet, par rapport aux logiciels concurrents, ScanToMusic traite les images en niveaux de gris au lieu d'un simple noir ou blanc. Dans ce type d'image, où les objets sont un peu "flous" l'oeil humain repère la forme des objets, donc leur contour, et l'orientation précise de ce contour en chacun de ses points. L'algorithme recherché doit prendre en compte cela. Ainsi traité, un échantillon de page donne: En vert, les lignes ayant la direction "haut-gauche vers bas-droite", en rouge la direction "haut-droite vers bas-gauche". En marron, les contours plutôt verticaux. Pour l'instant, des points sur des droites horizontales peuvent donner un résultat indéterminer. Il faut s'attacher ici aux symboles musicaux. La connaissance de l'orientation des contours pourrait nous aider à reconnaître le symbole, le point d'orgue ou les rondes ayant apparemment un schéma de coloration bien spécifique et reconnaissable. Ce procédé sera-t-il utilisé dans la version finale ? Impossible de le dire pour l'instant. |
|
|
by Olivier Guillion | | |
| |
|

L'algorithme général de la reconnaissance commence à se préciser. Après un travail de débruitage, optimisation du contraste et compensation des déformations de la page, les lignes des portées sont repérées. Cela permet de connaître précisément la valeur de l'interligne, qui conditionne les dimensions de la plupart des symboles que l'on peut y trouver. Ensuite, les lignes verticales (tiges de notes, barres de mesures, etc) sont repérées assez grossièrement. Ces lignes servent alors de "guide" pour trouver les têtes de noires et de blanches. Là aussi, il peut y avoir des erreurs, qui seront compensées par les phases suivantes. La recherche des ligatures, par exemple, "effacera" les têtes de noires qui ont pu y être trouvées par erreur. On considère que la ligature n'est jamais en contact avec la tête de la note. Puis, c'est le tour des symboles isolés (silences, pointés) et des hampes non ligaturées. Enfin, les clés, signatures temps et altérations seront recherchées. Il y aura alors probablement une phase qui permettra de traiter la totalité des objets trouvés et de supprimés ceux qui ne suivent pas la logique d'une partition classique. Il restera alors à traiter les accolades, liaisons et textes, ainsi que divers ornements, pour obtenir une reconnaissance assez complète. L'idée est donc que la reconnaissance d'un type de symbole donné n'a pas à être parfaite, car le schéma d'une partition obéit à des règles assez figées, permettant de faire du ménage dans ce qui a été trouvé. Il vaut mieux trouver un symbole là où il n'est pas, que de ne pas le trouver là où il est. |
|
|
by Olivier Guillion | | | |
|
|