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 | |
| |
|
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 | |
|
| |
|
|
