Pour finir la semaine et nous changer les idées nous avons repris le projet Acam sur Macintosh. A terme, ceci nous permettrait de rendre nos applications indépendantes de la couche Carbon.
De plus Carbon n'ayant jamais été porté en 64bits par Apple, cela nous bloque si nous voulons un jour faire une version 64 bits de nos programmes.(Ce qui serait à peu près sans amélioration de performance mais suivrait la mode)
Un projet très simple, Myredit (petit éditeur de texte que nous avons écrit en 1992), a été compilé et fonctionne.
Nous allons essayer maintenant avec un projet un peu plus complexe : Melody Player.
Bon week-end ! |
|
|
| by Didier Guillion |  |
|
| |
|
Ce coup-ci, ça y est, la version 1.5.0 RC3 a été postée et annoncée sur le forum.
Sauf gros imprévu (fichiers qui se traitaient bien auparavant et qui ne se traitent plus, crash reproductible, etc) cette version devrait être très proche de ce que sera la prochaine version publique.
Nous attendons donc les derniers retours des beta-testeurs, et si rien d'embêtant n'arrive d'ici le début de la semaine prochaine, on envisage la sortie publique dans la foulée. |
|
|
| by Olivier Guillion |  |
| |
|
Nous préparons la version 1.5.0RC3 de PDFtoMusic et PDFtoMusic Pro sur Windows et Mac OS.
Cette version corrige les problèmes spécifiques qui nous ont été signalés, et intègre la première version de la documentation en Néerlandais.
Elle devrait être mise en ligne demain matin, dès que nous aurons fini de relire la doc néerlandaise  |
|
|
| by Olivier Guillion | |
| |
|
Certaines corrections appliquées au document n'entrainait pas un recalcul correct, c'est corrigé.
Les notes tracées en un seul glyphe pouvaient avoir un problème de localisation des altérations, c'est corrigé.
Tous les retours des testeurs ayant été traités, une Release Candidate devrait pouvoir être proposé demain.
|
|
|
| by Didier Guillion | |
| |
|
La recherche des irrégularités dans le code concernant les variables non initialisées, entamée en fin de semaine dernière, est enfin terminée. Elle a été effectuée non seulement sur Harmony/Melody et PDFtoMusic, mais également sur toutes les bibliothèque annexes dont nous nous servons (ACAM, compactage audio sans perte, Lua, etc)
Sur les centaines de portions de code examinées, moins d'une dizaine contenait de véritables erreurs. Dans la plupart des cas, il s'agissait de scénario très limite, qui ne survenait que par exemple lorsque la mémoire était pleine. Il arrivait alors qu'une variable non initialisée soit lue (mais pas toujours utilisée). Mais si la mémoire est vraiment pleine, il est improbable que le programme puisse de toute façon s'en sortir "proprement".
Les deux ou trois dernières étaient des cas rares. Une fonction MyrScript de récupération de processeur d'effet par défaut d'un instrument, apparemment jamais testée, un problème de fermeture de fichier lorsqu'une erreur d'écriture survenait, mais pas grand-chose de plus.
Quoi qu'il en soit, nous serons désormais prévenus lorsqu'une nouvelle erreur de ce type sera détectée lors de la compilation. Cela nous évitera donc de laisser passer un nouveau bug intermittent, si difficile à localiser après coup. |
|
|
| by Olivier Guillion | |
| |
|
Pour finir la semaine :
Amélioration de l'association des altérations à la tonalité.
Meilleure gestion des quotes et guillemets encodés Unicodes.
Correction d'un problème pouvant générer des barres de fin de musique au milieu du morceau.
Prise en compte des polices déformées horizontalement. Ceci entraîne un meilleur rendu de l'affichage mais également une meilleure concaténation des caractères en mots.
Bon week-end ! |
|
|
| by Didier Guillion | |
|
| |
|
Attention, ce billet est plutôt technique. La dernière partie nécessite de connaître le langage C.
Nous avons enfin trouvé l'erreur sur laquelle nous nous cassions les dents depuis plusieurs jours !
Comme nous l'avions déduit, il s'agissait de l'utilisation d'une variable non initialisée, dont la valeur était donc aléatoire, et qui conditionnait la logique de la détermination du type d'accord.
En conformité avec la loi de Murphy, dès que nous ajoutions dans le programme un test nous permettant de vérifier nos calculs, l'erreur ne se produisait plus.
Les symptômes nous ont cependant permis de réduire notre champ de recherche à seulement quelques fonctions, et là, bingo ! Un calcul sur une variable "score" non initialisée.
Il a suffi d'ajouter 2 caractères seulement, et changer :
float score;
par
float score=0;
pour que tout fonctionnne correctement.
Afin de nous assurer qu'il ne restait pas d'autres petites nuisances comme celle-ci dans nos programmes, nous avons soigneusement configuré notre compilateur pour qu'il détecte ce genre de cas et nous permette de les vérifier un à un.
________________
Pour les programmeurs sous Windows, il faut activer les alertes de niveau 4. Mais à ce moment-là, on est inondé de milliers de messages anxiogènes portant sur des détails sans importance.
Nous avons donc répertorié une à une puis masqué les alertes nous paraissant inutiles.
En voici la liste, dans Visual Studio Express 2012
4214;4206;4057;4200;4129;4390;4125;4245;4702;4706;4310;4389;4005;4127;41 89;4505;4100;4121;4068;4273;4244;4305;4996;4309;4018;4805;4101
(celle qui nous intéresse et ne doit donc pas être masquée est l'alerte n° 4701)
Ainsi configuré, si on compile cette fonction:
short fonction(short a)
{
short b,c;
if(a) b=c=1;
else b=0;
b=b+c;
return(b);
}
le compilateur inscrit à juste titre une alerte disant que la variable c peut être utilisée sans être initialisée.
En effet, si la variable d'entrée a est non nulle, b et c recevront la valeur 1, et le calcul b+c vaudra 2.
Mais si la variable a est nulle, c ne reçoit aucune valeur, et le calcul b+c est indéterminé.
Nous avons donc activé cette option et recompilé entièrement PDFtoMusic et Harmony Assistant.
Nous avons obtenu une centaine d'alertes pour le premier et plus de 600 pour le second !
Autant d'erreurs potentielles dans ces programmes ? Non, car le compilateur trouve énormément de "faux positifs".
Sa logique n'est pas très poussée, aussi certains cas ne peuvent pas être détectés correctement.
Par exemple, si on modifie la fonction précédente en :
short fonction(short a)
{
short b,c;
if(a) b=c=1;
else b=0;
if(b) b=b+c;
return(b);
}
Le compîlateur va prévenir qu'il peut y avoir un usage de c non initialisée. Mais c'est faux. Pour que c ne soit pas initialisé, il faut que b soit nul. Or, dans ce cas, le calcul n'est pas effectué.
C'est donc un faux positif.
Une variante est:
short fonction(short a)
{
short b;
if(a) b=1;
if(a) return(b);
return(0);
}
Le compilateur ne se rend pas compte que c'est le même test qui positionne b et qui l'utilise par la suite. Là aussi, alerte qui n'a pas lieu d'être.
En réalité, les cas sont beaucoup plus complexe, et chacun d'entre eux nous demande au moins 30 secondes à 1 minute de réflexion pour nous assurer qu'il n'y a pas de vraie erreur.
Pour l'instant, sur les 300 traités, nous n'en avons trouvé que 2 ou 3 de potentiellement dommageables, et encore ils ne surviennent que dans des opérations très rares.
Mais, par contre, le compte est facile à faire. 600 vérifications, à 1 mn par vérification, cela fait 10 heures consécutives de réflexion intense.
Il faut commence par nous assurer qu'il nous reste assez de paracétamol. |
|
|
| by Olivier Guillion | |
|
| |
|
Certains tous petits coulés pouvaient être confondu avec la tête de note en demi-cercle de la notation ShapeNote, c'est corrigé.
Correction d'un problème de reconnaissance de métrique.
Meilleure gestion des sens de tiges sur les notes tracées entièrement via un symbole. |
|
|
| by Didier Guillion | |
| |
|
Amélioration de la base de donnée de reconnaissance optique: discrimination entre certains coulés courts et têtes de notes demi-blanche de la notation FaSoLa
Amélioration du suivi des portées d'un système à l'autre lorsqu'une portée chantée était présente mais sans note
Un problème nous occupe depuis plusieurs jours : dans certains cas, le premier accord de la partition peut être incorrectement déterminé. Il semble s'agir d'un problème intermittent survenant aléatoirement. Nous avons donc pu le reproduire quelquefois, mais impossible de savoir d'où cela provient exactement.
Harmony Assistant, palette de Virtual Singer : maintenant que nous savons gérer les affichages en transparence partielle, nous avons amélioré l'aspect des chanteurs lorsqu'ils sont désactivés. Ils apparaissent maintenant comme des fantômes bleus semi-transparents. |
|
|
| by Olivier Guillion | |
| |
|
Correction d'un problème d'attribution de paroles aux portées.
Correction d'un problème de détection des trémolos.
Correction d'un problème de confusion de coulé.
Le tableau des mesures à jouer ne fonctionnait pas si les extensions au MusicXML étaient désactivées, c'est corrigé.
|
|
|
| by Didier Guillion | |
| |
|
Un problème de saisie et de manipulation des ornements de notes de type "texte" en mode ruban à partir d'une certaine position dans la musique a été corrigé.
Cela nous a également permis de corriger une erreur arithmétique dans le calcul des positions des ornements placés au-dessus de la portée. Contrairement au point précédent, cette erreur avait été introduite avec les versions beta
Dans PDFtoMusic (Std & Pro), correction d'un problème de positionnement d'appoggiatures sur les portées multivoix
Bon week-end ! |
|
|
| by Olivier Guillion | |
| |
|
Nous commençons à analyser les retours des testeurs.
Dans Harmony les tuplets 6:4 étaient transformés en 3:2, c'est corrigé.
Les tuplets abrégés notés "7" étaient considérés comme étant "7:2", ils seront désormais traités en "7:4".
Lorsque une appoggiature débutait une ligne de mesure, elle pouvait "voler" une altération de la tonalité, c'est corrigé.
|
|
|
| by Didier Guillion | |
| |
|
Nous avons corrigé des problèmes de menu dans la version standard de PDFtoMusic RC2 :
- L'option "Quitter" pouvait rester grisée lorsqu'aucun document n'était en mémoire
- L'option "Imprimer", quant à elle, pouvait être accessible, et générait un crash
- L'option "Mise en page" était inutile sur Windows. Elle a donc été supprimée de la version de PDFtoMusic et PDFtoMusic Pro sur cette plateforme.
|
|
|
| by Olivier Guillion | |
| |
|
Pour finir la semaine :
Correction d'un problème de décalage horizontal des accords sur la première ligne quand le titre était souligné (ouioui c'est possible)
Les lignes de mesures ne contenant que des informations textuelles étaient éliminé, c'est corrigé.
Enfin, la version 1.5.0 RC2 a été publiée et les utilisateurs de PDFtoMusic version standard prévenus.
Bon week-end ! |
|
|
| by Didier Guillion | |
| |
|
Après correction de quelques vilaines irrégularités dans certains cas limites, la version 1.5.0 RC2 est maintenant prête.
Malheureusement, un peu trop tard pour être mise à disposition ce soir, nous préférons en effet être en mesure de traiter les premiers retours dans les heures qui suivent la diffusion d'une version, même beta ou RC.
Elle devrait donc être disponible demain, en version Pro et non-pro, sur MacOS et Windows XP et plus.
Cette version a été testée sur Windows XP SP3 "sorti de boîte", afin de nous assurer que l'installation n'oublie aucun fichier et que le programme est resté compatible avec ces anciennes versions du système.
Demain, dès que nous aurons posté cette version, nous contacterons par e-mail tous les utilisateurs enregistrés de PDFtoMusic pour leur proposer de nous aider à traquer les derniers problèmes qui pourraient subsister. |
|
|
| by Olivier Guillion | |
| |
|
Nous progressons vers la Rc2
Amélioration de l'affichage des caractères quand la police n'est pas embarquée.
Amélioration de la reconnaissance des doigtés.
Correction d'un problème de signature temps.
Correction d'un problème de sauvegarde Mp3 dans la librairie.
|
|
|
| by Didier Guillion | |
| |
|
Aujourd'hui, en chemin vers la RC2 :
Correction de l'export MP3 et OGG (ne fonctionnait pas en RC1)
Correction de crash lors d'un clic droit sur le titre de la palette clavier
Crashs sur de grands fichiers scannés, aux dimensions incorrectes (dans notre exemple, 136 pages de 1m40 par 1m79) 
Amélioration des tests de saturation mémoire
Amélioration de la correspondance entre les portées d'un système (une ligne d'écriture) à l'autre, par leur nom. Le programme doit comprendre que le nom abrégé (par exemple Fl. & Pno) correspond au nom long (Flûte & Piano)
Nouveau calcul d'échelle pour la visualisation en "taille réelle", plus proche de la taille véritable de la page
Windows: problème de retours à la ligne des textes des info-bulles (correction bas niveau dans la gestion des largeurs des polices)
Amélioration de la recherche d'un nom utilisable pour les fichiers temporaires
|
|
|
| by Olivier Guillion | |
| |
|
Déjà pas mal de retours de l'équipe de testeurs.
Meilleure localisation des portées pour les crescendo/decrescendo.
Reconnaissances des doigtés pour guitare représentant les cordes : nombre entouré d'un cercle quand celui-ci est tracé manuellement.
Sauvegarde des indications de cordes en MusicXML. Chargement dans Harmony Assistant.
Dans certains cas les indications de tempo du genre noire=140 étaient tracés via une police non musicale et donc considéré comme des textes libres et encodés dans le MusicXML par "q=140". Un nouveau post-traitement tente de repérer cette séquence et la transforme en tempo. |
|
|
| by Didier Guillion | |
| |
|
|
