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 |  |
|
| |
|
S'il est plaisant d'ajouter une fonctionnalité nouvelle, évident de corriger un problème, nous avons toujours plus de réticence à réécrire un module qui fonctionne parfaitement depuis des années. Depuis quelques versions, le déplacement sur la partition des titres, commentaires, remarques, se fait en direct, avec un système de lignes verticales et horizontales qui aident au positionnement. Ce même procédé à été étendu à plusieurs objets : textes, nuances, graphismes, diagrammes d'accord, pédales, etc.
L'ancien module montrait à la fois l'objet original et l'objet déplacé, ce qui entrainait des "surcharges" graphiques nuisant à la lisibilité. C'est donc plus clair et plus précis, mais aussi un peu plus gourmand en temps machine. Mais, depuis l'écriture du module original, la puissance de calcul des ordinateurs de base à considérablement évolué...
|
|
|
| by Didier Guillion |  |
|
| |
|
Comme d'habitude, la sortie d'une nouvelle version béta voit arriver sur nos boites de mails des dizaines de rapports perspicaces des béta testeurs. Nous les traitons au plus vite, mais certains demandent quelques réflexions et analyses, merci d'être patient dans l'attente de notre réponse.
En l'état actuel, et comme notre souci est de garantir un format stable de fichier jusqu'à la version publique, nous avons décidés de ne pas intégrer dans cette version les nouvelles demandes qui demanderaient une modification de ce format. Ce sera pour la 9.5...
Par contre toutes les demandes liées à l'ergonomie des fonctionnalités déjà implémentées sont étudiées avec soin. Par exemple, on nous a demandé la possibilité d un déplacement fin au clavier pour certains objets comme les textes associés aux portées. Cela a été fait pour la prochaine béta et à permis de mettre en évidence des problèmes d'imprécision dans le déplacement des objets : déplacer d'un pixel à droite puis à gauche ne redonnait pas exactement la même position... |
|
|
| by Didier 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 | |
|
| |
|
Voici notre coup de coeur du moment, un tout jeune blog qui s'augure prometteur. Basé sur la décoration de l'intérieur il donne un florilège de bonnes adresses dans notre région et assène des critiques justifiées.
Un lien a suivre :
http://www.blogdeco.info |
|
|
| by Didier Guillion | |
|
| |
|
Ces derniers jours notre travail a été spécialement basé sur la gestion des libellés associés au repères, initiée dans ce fil :
http://www.myriad-online.com/cgi-bin/workshop/YaBB.pl?board=beta;action= display;num=1184951353
Une solution a été implémentée qui nous semble couvrir la demande. Nous avons essayé de rendre la chose la plus flexible possible tout en restant compréhensible. J'espère que nous avons convenablement réussit. Dans tous les cas ceci sera à tester dans la prochaine béta, d'ailleurs très prochaine, puisque nous sommes en train de la poster sur le site.
Voilà près d'un mois écoulé depuis la béta précédente et de nombreuses améliorations ont été apportées. Il était temps de fournir aux testeurs une nouvelle version à se mettre sous la dent !
A noter que cette version devrait offrir un format stable des fichiers, ce qui permettra de réellement travailler avec.
Au passage, deux nouveaux chapitres dans la documentation décrivent en détail la notion de vues et de repères.
En particulier, le module d'impression sur Mac a été repensé afin de suppléer à des problèmes avec certains pilotes d'impression, ce devrait être un peu plus lent mais plus précis. A vous de tester.
Une question avait été soulevée sur la séquence d'encadrement des textes ($X). Cette séquence encadrait l'aire définie par l'utilisateur.
Une nouvelle séquence ($S) a été créée qui encadre l'aire utile du texte. Voici ce que cela donne :
A gauche, un texte avec la commande $X, à droite, le même texte avec la commande $S.
Bien sur, cette nouvelle commande a été utilisé pour l'affichage des libellés des repères. |
|
|
| by Didier Guillion | |
|
| |
|
Une solution est en cours d'essai pour afficher les libellés des repères. De nouvelles séquences dans le texte associé à la portée permettrait d'afficher des informations du repère en vis à vis : son nom, son rang.
Dans le menu du placard des commandes effacent tous les textes associés aux repères ou créent automatiquement un texte par repère.
Cette génération est paramétrable :
Ceci reste à finaliser et à tester en situation.
|
|
|
| by Didier Guillion | |
| |
|
Suite a une suggestion de l'atelier démocratique, l'édition des "tags" dans les textes est rendue plus aisée par un menu déroulant.
Rappelons que les "tags" sont des séquences commencées par le symbole "$" et qui permettent d'afficher des informations liées au document :
La sélection dans le menu insère la séquence adéquate à la position du curseur.
Nous essayons de répondre à la demande de l'atelier :
http://www.myriad-online.com/cgi-bin/workshop/YaBB.pl?board=request;acti on=display;num=1156197964
Une nouvelle commande a été définie qui affiche le nom de la cible associée à la mesure, est ce suffisant ?
Vous pouvez vous exprimer à ce sujet sur le fil de discussion.
|
|
|
| by Didier Guillion | |
| |
|
Notre objectif est de proposer, dans les jours qui viennent, une béta d'Harmony Assistant avec un format de fichier stable ce qui permettra aux béta testeurs de réellement travailler avec cette version. Il y a tout de même pas mal de nouveautés qui ont nécessité des remaniements en profondeur de certains modules et elles méritent d'être tester longuement, au moins jusqu'à l'Automne. En particulier les vues, les clic droits et les tuplets.
Donc, il faut être sur que rien ne devra être ajouté au format de fichier. Nous conseillons donc au béta testeurs de lire avec attention les demandes en attente et en particulier celles qui seraient succeptibles d'engendrer un changement de format.
Par exemple, la gestion de repère avec texte associé :
http://www.myriad-online.com/cgi-bin/workshop/YaBB.pl?board=request;acti on=display;num=1156197964
Serait ce un nouvel objet ou une extension des "cibles" ? La question est ouverte.
Enfin, il a été demandé à ce que le symbole de tête "+", voit sa tige alignée sur la droite et non sur le centre, comme c'était le cas dans les anciennes versions :
http://www.myriad-online.com/cgi-bin/workshop/YaBB.pl?board=request;acti on=display;num=1181300670
Faut il créer un nouveau symbole ou simplement revenir en arrière ? |
|
|
| by Didier Guillion | |
| |
|
La fonctionnalité permettant d'appliquer paramètres de vues ou options d'impression sur un ensemble de vue à progressé. Dans la liste des vues, plusieurs vues peuvent être sélectionnées simultanément par Majuscule+Clic. Ensuite un clic droit sur une vue ouvre un menu contextuel permettant d'appliquer les paramètres ou options d'impression de cette vue à toutes les vues du document ou aux vues sélectionnées. Ceci permettra je pense de couvrir l'ensemble des demandes.
La rédaction de la partie du manuel consacré aux vues à commencé. Voici l'état actuel de ce chapitre :
http://www.myriad-online.com/resources/docs/harmony/francais/views.htm
Il sera mis à jour régulièrement. Faites abstraction des fautes d'orthographe, ce texte est livré "brut".
Certaines fonctionnalités décrites ne sont pas encore présente dans la béta courante et toujours en développement.
|
|
|
| by Didier Guillion | |
| |
|
Voici les avancements et questionnement divers de ces derniers jours :
- Les ajustements automatique de la courbure des coulés s'appliquent également lors de la pose d'un coulé.
- Sur suggestion de Franck, un clic droit lors de l'insertion de la note permet de passer outre le mode "Limiter à la mesure".
- Des problèmes de précision de l'impression ont été rapportés sur Mac OS X, c'est apparemment un problème d'intéraction du QuickDraw avec certains pilotes d'impression. Nous travaillons activement sur le sujet.
- Une demande a été faite de pouvoir appliquer une mise en pages particulière sur un ensemble de vues,
http://www.myriad-online.com/cgi-bin/workshop/YaBB.pl?board=beta;action= display;num=1184314888;start=0
nous essayons de trouver une solution.
|
|
|
| by Didier Guillion | |
| |
|
A partir de l'analyse de l'étape 32 un module de remise en forme des coulés à été implémenté à titre expérimental dans la version de développement. Cette remise en forme intervient à plusieurs endroits. Tout d'abord dès que l'on demande une inversion de coulé, car c'est dans ce cas là que l'on est presque certain que le coulé obtenu ne sera pas correct. Ensuite, l'on peut l'appliquer directement sur un coulé existant sans changer son sens. Ceci passe par le clic droit sur le coulé :
Enfin, lors de l'application d'une modification de l'aspect général, une nouvelle case l'invoque sur demande :
Voici un exemple, on démarre d'un ensemble de coulés :
Les deux premiers sont simplement remis en forme, les deux autres inversés :
Il y a encore des améliorations à étudier, mais le résultat est, je pense, prometteur. |
|
|
| by Didier 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 | |
| |
|
Ces derniers jours, nous nous sommes consacrés à la généralisation du clic-droit sur les différents objets. Une bonne proportion des éléments de la partition sont maintenant accessibles par ce moyen. La dernière addition a été le clic droit sur la sélection.
Les propositions à ce sujet restent ouvertes...
Une demande intéressante est en cours sur la possibilité de poser des marqueurs visuels sur la partition :
http://www.myriad-online.com/cgi-bin/workshop/YaBB.pl?board=request;acti on=display;num=1156197964
Initiée il y a presque un an par Cri-Cri elle est revenue sur le devant de la scène. Doit on l'associer aux marqueurs logiques déjà implémentés ou serait ce un nouveau type d'objet ? Nous vous invitons à vous exprimer à ce sujet. |
|
|
| by Didier 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 | |
|
| |
|
Dans un billet précédent, nous exprimions notre volonté de généraliser plus profondément le clic droit. En effet, depuis quelques années les souris à deux boutons se sont généralisées, surtout depuis qu' Apple a décidé de s'y mettre. Comme c'est sur Windows que les premiers mulots de ce genre sont apparus, c'est l'ergonomie Windows qui est généralement utilisée dans les logiciels : clic gauche pour sélectionner, double clic gauche pour éditer, clic laissé appuyé pour déplacer. Certains ont utilisé le double clic et demi (double clic suivit d'un appui), mais c'est assez peu fréquent.
Le clic droit est en général simple (pas de double clic droit à ma connaissance), il ouvre un menu contextuel permettant de choisir rapidement les actions les plus courantes associées à l'objet. Cela évite de passer par le double clic pour éditer et la sélection du paramètre.
Il reste maintenant à définir, objet par objet, ce qu'est une "action la plus courante". Je vous invite à vous exprimer à ce sujet dans l'Atelier Démocratique en ouvrant un sujet par type d'objet. Gardez cependant à l'esprit qu'une sélection par menu rend possible la commutation d'un booléen (vrai ou faux, actif ou inactif, etc) mais pas l'édition d'une valeur.
|
|
|
| by Didier 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 | |
|
| |
|
|
