De petits problèmes ont été corrigés ça et là :
- la prise en compte des triolets lors du changement global de la durée des notes contenues dans la sélection
- des erreurs de "timing" dans l'application d'une forme d'onde rectangulaire sur les courbes de paramètres
- des recalculs de sens de tiges et d'accroches qui manquaient après certaines opérations d'édition
- la correction et l'ajustement des paramètres d'interprétation du staccato, mezzo staccato et staccatissimo...
bref, la routine...  |
|
|
| by Olivier Guillion |  |
|
| |
|
Des problèmes de sauvegarde de métrique et de tonalité dans l'export MusicXML nous ont été signalés par un utilisateur.
En effet, l'export se mélangeait un peu les pinceaux avec les anacrouses, et repassait automatiquement en tonalité de Do majeur, mais rendait ce changement invisible. Résultat : une partition graphiquement correcte, mais jouant inexplicablement faux 
Ce problème a donc été corrigé, et nous en avons également profité pour régler plus finement la taille des tiges de notes exportées en MusicXML.
Maintenant que les notes contenues dans les tuplets (triolets, quintolets...) peuvent être accrochées ou décrochées à loisir, nous avons implémenté une demande de l'Atelier Démocratique : ne pas accrocher les noires (et notes plus longues) à l'intérieur des groupes de tuplets.
Cela a cependant une conséquence : le système d'accroche automatique traitant maintenant les accroches dans les tuplets, si l'utilisateur les définit "à la main", il risque de voir son travail effacé lors du prochain calcul d'accroches. |
|
|
| by Olivier Guillion | |
| |
|
Aujourd'hui, correction des quelques problèmes signalés sur la version beta-4, et notamment sur les vues. Par exemple, toutes les portées doivent être jouées dans la vue générale, même si elles sont masquées, et la grille des portées imprimables des options d'impression doit pouvoir être utilisée pour masquer et autoriser des portées dans la vue courante.
Le positionnement des notes (réglage fin horizontal de -100% à +100%) a été repris en mode gravure "amélioré", afin de fournir une aire de déplacement centrée sur la position zéro.
Nous avons également analysé la possibilité de décaler automatiquement, dans les portées multi-voix les notes qui chevauchent celles d'une autre voix (intervalle de seconde ou moins). Malheureusement, nous n'avons trouvé aucune solution satisfaisante permettant de mettre en oeuvre cela. Dans l'état actuel de nos réflexions, seul un script (par exemple, celui qui gère la remise en forme de partition) pourrait prendre cela en charge après coup. |
|
|
| by Olivier Guillion | |
|
| |
|
Aujourd'hui, plusieurs détails ont été réglés, notamment:
- La pose sur la partition d'un signe de répétition des deux mesures précédentes pouvait décaler les notes qui suivaient. Il s'agissait d'un problème de prise en compte des silences fantômes.
Nous en avons également profité pour corriger la pose de ce signe sur des mesures contenant des notes débordant sur la mesure suivante (liés)
- Nous avons repris le script "Tête de note entre parenthèses" pour caler finement la position des parenthèses, et décaler altération et appoggiatures afin d'éviter les chevauchements avec la parenthèse ouvrante.
A titre anecdotique, sachant que nous sortons régulièrement de nouvelles versions, nous avons mis dans le programme un test sur "l'âge" de la version utilisée.
Si le programme a été créé (compilé, chez nous) plus de 6 mois (je crois) avant la date courante, une alerte apparaît, conseillant d'effectuer une mise à jour.
Cette date est arrivée pour tous ceux qui n'ont pas encore effectué la mise à jour en 9.3 (Melody 7.3).
Ce que nous n'avions pas prévu, c'est que cela apparaît exactement le même jour pour tout le monde.
Donc nous avons un afflux brutal de personnes qui ne savent pas comment faire, certaines pensant que quelque chose ne va pas sur leur ordinateur (ceux-là commencent par reformater leur disque dur avant de continuer, c'est un réflexe  ).
Pour éviter cet afflux, ce test de date est supprimé des prochaines versions. |
|
|
| by Olivier Guillion | |
|
| |
|
Une demande dans l'Atelier Démocratique concerne les coulés. Le programme doit pouvoir positionner verticalement le point de contrôle médian du coulé, afin de faire éviter automatiquement à ce dernier les symboles de la partition.
Effectivement, un calcul exact ne serait pas simple, puisqu'il faudrait suivre la courbe et déterminer si elle passe bien au-dessus (ou au-dessous) de tous les points correspondant aux objets à contourner.
Mais parfois, mieux vaut une approximation simple qu'une exactitude compliquée
Si on assimile le coulé à deux segments de droites, le considérant comme une sorte d'accent circonflexe, on peut facilement calculer la hauteur à donner au point médian du coulé pour que tous les objets soient tous au-dessous (ou au-dessus, pour un coulé bas) de la figure.
Lors du véritable tracé, l'arrondi du coulé débordant toujours vers l'extérieur de la figure, le coulé sera simplement un peu plus éloigné des points qu'il évite. Une petite marge de sécurité en quelque sorte. Et je suis sûr que tout le mondre croira que c'est fait exprès
Exemple:
En rouge, la position "standard" du coulé, avant ajustement
En gris (pointillé) la verticale sur laquelle on doit bouger le point médian
En bleu, l'approximation du coulé en ligne brisée. La position du point médian est calculée pour éviter les têtes des notes.
En vert, le coulé tracé à la nouvelle position. |
|
|
| by Olivier Guillion | |
|
| |
|
Nous nous sommes aperçus que le script "Altérations microtonales" donnait des résultats graphiques étranges, et cela depuis plusieurs versions.
Ce script a été corrigé pour prendre en compte les encodages de textes en "Unicode", mais nous avons dû également corriger une mauvaise position par défaut des effets "Texte" attachés à une note.
Cette modification risque donc, dans certains cas, de décaler verticalement les effets texte qui avaient été posés, et ajustés, sur des partitions créées avec les version 9.0 à 9.3. Ceci sera plus particulièrement sensible si ces textes sont écrits en utilisant la fonte musicale "SToccata".
Autre problème mineur détecté, lors d'un changement de clé ou de tonalité, une transposition du type "laisser les notes graphiquement en place" pouvait faire disparaître les altérations des notes si celles-ci portaient une appoggiature de la même hauteur (note) qu'elles.
Cela devait se produire depuis de nombreuses versions. Ce sera corrigé dans la suivante.
|
|
|
| by Olivier Guillion | |
| |
|
Aujourd'hui, la totalité de l'affichage et de l'impression des "splines", c'est-à-dire les formes courbes (accolades, liés, coulés, etc) qui peuvent apparaître sur la partition ont été repris.
Pour des raisons de temps de calcul, toutes les opérations mathématiques liées au tracé de ces formes se faisaient sur des nombres entiers. Les processeurs récents étant extrèmement rapides pour les calculs de nombres à virgule, cette restriction ne s'imposait plus. A noter que ces fonctions avaient été écrites il y a plus de 15 ans, et reprises il y a 6 ans pour y ajouter l'effet de lissage sur l'écran.
La précision de ces tracés, et leur impression, a donc été améliorée. Cela devrait être surtout sensible sur les imprimantes à faible précision (inférieures à 600 dpi) et sur l'aperçu avant impression.
La différence graphique reste pour l'essentiel extrèmement ténue. Donc personne ne bondira de sa chaise en voyant le résultat
Cela méritait cependant d'être fait. |
|
|
| by Olivier Guillion | |
| |
|
Nous recevons régulièrement des demandes de personnes non-voyantes, ou malvoyantes, qui souhaiteraient que nos produits soient plus adaptés à leur handicap.
Sur Mac OS X, le système intègre une lecture des textes apparaissant à l'écran, mais apparemment, cela ne fonctionne pas en français.
Sur Windows, des logiciels (généralement assez chers, soit dit en passant), permettent de "zoomer" l'écran, et / ou de faire dire à l'ordinateur le contenu des menus, boîtes de dialogue, qui apparaissent à l'écran.
Problème : ces logiciels ne fonctionnent que sur des applications "standards" pour Windows. Elles interceptent les appels que n'importe quel programme fait au système pour afficher un bouton ou un menu, et "lisent" ce texte grâce à une synthèse de voix parlée (probablement qu'elles peuvent également faire afficher ce texte sur un afficheur braille)
Mais nos applications n'utilisent pas les accès standards au système, donc les logiciels de lecture pour malvoyants restent désespérément muets.
Nous pensions prendre cela en compte dans notre système d'interfaçage graphique, et faire appel nous-même au logiciel de lecture en lui envoyant ce que nous montrons à l'écran.
Hélas, chaque logiciel semble avoir ses propres méthodes, sa propre architecture, et aucun jeu de "points d'accès" communs ne semble permettre à une application de faire dire quelque chose au logiciel de lecture par défaut installé sur l'ordinateur de l'utilisateur.
Nous pourrions tester duquel il s'agit, mais les documentations techniques ne sont pas facilement disponibles, les logiciels sont nombreux (citons Jaws ou ZoomText), et probablement que chaque pays, en fonction de sa langue, a porté son choix sur l'un, l'autre, ou un troisième.
En résumé, c'est un peu la galère, et même si nous parvenions à le faire fonctionner, cela ne permettrait que de faire lire les textes qui s'affichent à l'écran, et non, dans Harmony Assistant, de permettre une navigation aisée dans une partition, où la souris reste encore indispensable.
Peut-être que la solution serait une version spéciale de nos produits, qui intègrerait sa propre synthèse vocale, et/ou un script qui permettrait la navigation et l'édition d'une partition sans nécessiter un quelconque pointage avec la souris.
Nous réfléchissons au problème depuis des années, mais n'avons pas encore réussi à trouver de solution satisfaisante. |
|
|
| by Olivier Guillion | |
|
| |
|
Une journée comme les autres. Notre serveur Web tourne tranquillement, montrant les pages du site à qui veut les voir, fournissant les dernières versions des logiciels en téléchargement. Quelques personnes lisent le dernier article du blog, d'autres postent des messages sur le forum de discussion. Nous lisons les derniers e-mails qui viennent d'arriver...
Ce calme n'est qu'apparent. Derrière cet aspect tranquille, en quasi permanence le serveur pare des tentatives de spam, de pollution des forums, d'inscriptions par des robots ou même d''intrusion.
Nous avons des fichiers-journaux (logs) de tout ce qui se passe, en tout cas de tout ce que nous pouvons voir, à notre niveau. Ce qui permet de faire, de temps en temps, quelques statistiques:
Dans la seule journée, l'image déformée dont il faut taper le contenu pour s'inscrire sur le forum a empêché 55 inscriptions automatiques par des robots posteurs de spam. Nos tests de conformité ont bloqué l'accès à 11 messages de spam sur ce blog même, et près de 1500 e-mails ont été détruits avant d'atteindre nos boîtes de courrier électronique.
Au total, ce sont 36 adresses IP qui sont interdites d'accès à la totalité de notre site Web, et 80 fournisseurs de boîtes aux lettres électroniques dont les utilisateurs ne sont pas autorisés à s'inscrire sur nos forums.
Si la fonction de Webmaster n'exigeait pas, à la base, d'être un peu parano, il y aurait vraiment de quoi le devenir... |
|
|
| by Olivier Guillion | |
|
| |
|
Parfois, trop de demande tue la demande.
Lors des préparations des versions beta, chacun en profite pour expliquer les améliorations qu'il désirerait voir apporter au logiciel, comme le prouve le regain d'activité sur l'Atelier Démocratique.
Cela donne lieu à des échanges instructifs, parfois passionnés, parfois un peu confus.
De notre coté, nous nous attachons à plusieurs points fondamentaux, qui sont, dans le désordre :
- L'utilité de la fonction, et l'évaluation du pourcentage d'utilisateurs auxquels elle s'adresse
- La cohérence dans l'agencement des options du logiciel. Il y a un tel nombre de fonctionnalités que leur organisation doit rester logique, afin que l'option demandée se retrouve à un endroit où on puisse la retrouver facilement
- La cohérence ergonomique, pour éviter qu'un double-clic, un clic droit, un majuscule-clic, ou une touche du clavier n'active des fonctions très différentes selon l'objet concerné
- La simplicité de l'interface. Une boîte très complète, qui va dans le détail de tous les paramètres qui peuvent être ajustés, mais qui prend la moitié de l'écran et devient illisible, ne serait pas judicieuse.
- Le rapport travail/amélioration. Une option qui demande de notre part peu de travail, mais procure une amélioration conséquente sera privilégiée au détriment d'une option qui va nous demander des mois de développement et la refonte complète de modules déjà écrits, pour éviter un clic supplémentaire dans une édition.
Parfois, une demande simple et aisée à mettre en oeuvre surgit. Chacun imagine ce qu'il pourrait en faire, et propose ses propres idées, suggestions, ainsi que la manière dont elle pourrait apparaître dans le logiciel. De notre coté, nous évaluons les points cités au-dessus et commençons à nous faire une idée du travail nécessaire.
Malheureusement, la discussion amène parfois à une "complexification" de l'option, ou une généralisation qui modifierait le comportement général du logiciel. Nous ne savons pas, dans la demande, ce qui est du domaine du "absolument nécessaire" et du "probablement utile, mais on pourrait s'en passer". Les expressions telles que "indispensable", "tout logiciel d'édition de partition digne de ce nom doit...", "il faut absolument...", utilisées avec un peu trop d'enthousiasme, peuvent également ajouter à la confusion.
Il est alors arrivé que nous soyons contraints d'abandonner l'idée (au moins pour un temps), car sa mise en oeuvre s'avérait trop complexe au final, alors qu'au départ, elle était parfaitement réalisable. Ce n'est ni de la paresse, ni de la mauvaise volonté, seulement le désir de ne pas faire du travail "jetable", en implémentant une fonction qui ne satisferait pas pleinement la demande, et qui devrait être réécrite entièrement par la suite.
Vous comprenez alors maintenant le sens de ma première phrase : "parfois, trop de demande tue la demande". |
|
|
| by Olivier Guillion | |
|
| |
|
|
