Les fluctuations du dollar et de l'euro ne concernent pas que les spéculateurs, les grands groupes industriels et les touristes. Même les petites structures comme la nôtre doivent garder un oeil rivé sur ces courbes.
Les prix de nos produits étant indiqués dans les logiciels eux-mêmes ou dans la documentation qui les accompagne, il nous est assez difficile de faire varier nos tarifs fréquemment. Nous ne pouvons pas dire à quelqu'un qui édite un bon de commande et nous envoie son règlement : "désolé, vous avez téléchargé le programme avant-hier, mais le prix de la licence a augmenté hier", d'autant plus que des dizaines de sites, sur Internet, présentent notre logiciel, avec le prix mentionné à côté, impossible à modifier rapidement.
C'est pourquoi nos prix ne varient que très rarement. Nous avions également décidé d'appliquer une parité euro - dollar. Un produit vendu 1 euro à un client européen était vendu 1 dollar à quelqu'un en dehors de l'europe.
Avec l'euro légèrement plus fort que le dollar, ce n'était pas du favoritisme, mais simplement la prise en compte de l'absence de TVA sur des ventes hors Europe.
En effet, avec un euro aux alentours d'1,20 dollar, une vente, où qu'elle soit, revenait à peu près au même pour nous : En Europe, nous touchions 1 euro TTC, donc aux alentours de 84 centimes d'euro hors taxe, et hors Europe, nous touchions 1 dollar HT, soit aux alentours de 84 centimes d'euros également.
Bien sûr, il pouvait y avoir de petites fluctuations. D'août 2003 à juin 2007, le cours a varié entre 1,18 et 1,35 dollars pour un euro (voir ici). Nous pouvions nous en accomoder dans l'ensemble, la différence restant raisonnable.
Mais, lentement mais sûrement, le dollar descend (ou est-ce l'euro qui monte ?). Le cours a atteint aujourd'hui 1,52 dollars pour un euro. Les achats en dollars américains commencent à être de moins en moins rentables pour les européens que nous sommes, et cela revient pour nous à accorder contre notre gré une remise de 30% sur tout notre catalogue. Ce n'était plus gérable, et nous avons donc décidé de briser notre règle de parité.
Seuls les clients hors de l'Europe seront touchés par ce changement, qui n'est pas à proprement parler une hausse, mais plutôt un rééquilibrage.
Aujourd'hui nous avons finalisé le recalcul des positions des effets par rapports aux lignes de la portée quand on change le sens de la tige.
La gestion du déplacement des ruptures (coda, segno, parties ...) a été réécrite, le déplacement se fera "en direct" : on ne verra plus a la fois l'ancienne position et la nouvelle, ce sera donc beaucoup plus précis. Encore un très ancien module (d'au moins 8 ans) qui passe à la trappe..
Ce matin, en butinant à la recherche de documentations sur l'Internet, je suis tombé par hasard sur un groupe de chanteur que je ne connaissais pas. Créé dans les années 40, et dans le style des Frères Jacques, voici le groupe des Quatre Barbus. Désopilants, irrévérencieux, parfois grivois, souvent anarchistes, ils ne pouvaient que collaborer avec Francis Blanche pour pondre "La pince à linge" sur une musique du petit Ludwig V.B. Désolé, mais moi ça me fait tordre de rire... En voici une version illustrée :
- Création de repère à la mesure 1 - Affichage des repères après redimensionnement - Edition des effets associés à la note : la position par défaut a été supprimée. - Changement de l'orientation des lignes graphiques - Nouvel algorithme de positionnement des ornements afin qu'ils évitent les lignes de la portée - Sur Windows, meilleure prise en compte des polices s'affichant de droite à gauche, comme l'Arabe.
- Export MusicXML : Gestion des altérations entre parenthèses. - Export MusicXML : Exportation des "staff-details" uniquement quand nécessaire. - Export MusicXML : Changement de tonalité uniquement quand nécessaire. - Export MusicXML : Assignation des voies aux silences.
- Déplacement des poignées du coulé. - Aspect graphique de la partition : paramétrage des liaisons. - Apparition des paroles lors de l'édition des accords en texte.
De récentes études ont montré qu'un cadre de travail agréable augmente sensiblement la productivité, que les bugs sont corrigés 25% plus rapidement, les mails traités 30% plus vite et les réponses 42,56% plus pertinentes.
Forts de ces données scientifiques incontestables, collectées auprès d'un échantillon de 3 personnes représentatives de la population mondiale, nous nous sommes dits que le jardin, sur lequel donnent les fenêtres de nos bureaux, serait plus joli si les plantes étaient bien arrosées.
Dans le cadre d'une démarche éco-responsable, prenant en compte le développement durable, la gestion des ressources renouvelables et toutes ces sortes de choses, nous avons interrogé les vieux sages du quartier, qui nous ont dit que, dans le temps, il y avait eu un puits dans le jardin.
Il faut dire que la présence d'une pompe à bras en fonte, connectée à un gros tuyau de plomb s'enfonçant dans le sol, nous avait mis la puce à l'oreille. La pompe ne fonctionnait plus, mais il devait quand même y avoir un puits quelque part.
Un puisatier, qui semblait bien connaître son métier, nous a indiqué que l'eau devait être à 4m50 de profondeur, que le puits ne devait pas être très loin et qu'il devait s'agir d'un puits bâti et non d'un forage. Ce puits était probablement comblé, mais cela vaudrait le coup de le dégager et de le remettre en service. Il nous a alors conseillé de suivre le tuyau, et de rechercher une ouverture circulaire d'environ 90 cm de diamètre.
Après quelques trous percés dans la dalle en béton près de la pompe, nous sommes tombés sur une grosse pierre taillée d'environ 200 kg, ronde et plate, avec un petit évier gravé sur le dessus (probablement l'emplacement pour poser un sceau).
Une fois la dalle de béton enlevée à cet endroit et la pierre dégagée non sans mal, est apparu le haut du puits, bâti en briques de Toulouse, vous savez, ces briques rouge-orange qui ont valu à notre belle cité son surnom de ville rose.
Le puits était rempli de gravats divers et variés, jusqu'en haut, nous avons donc commencé à le dégager. Au bout d'une journée de travail, nous en sommes déjà à 3m de profondeur, mais n'avons pas fait de découverte archéologique majeure, à l'exception de morceaux de métal, de briques, de tuiles, une pierre à meuler, une tablette en marbre (cassée), une pince à linge (cassée aussi) et une capsule de bouteille de Vittel des années 70.
Plus qu'1m50 et nous devrions connaître le fond de l'affaire !
Vous pouvez voir une galerie photo de l'aventure ici.
La suite au prochain numéro, avec peut-être la réponse à toutes vos questions : - Vont-ils trouver de l'eau ou du pétrole ? - Lequel des deux frères a été tiré au sort pour rester au fond ? - Vont-ils monter une filiale "Myriad terrassement et curage de puits" ? - Et la version RC2 dans tout ça ?
Lors de l'édition des voix Virtual Singer les noms des chanteurs n'avaient jamais été traduits. Cela est maintenant fait.
Le problème spécifique à la version Mac PPC signalé à l'étape 136 est réapparu... Après une longue analyse nous avons découvert que cela provenait d'une cause tout à fait différente : dans certaines langues, une ressource était cassée.
Nous avons encore en chantier des problèmes assez ardus d'impression des vues et de positionnement des ornements. Dès que c'est au point nous passerons en RC2.
Aujourd'hui, nous avons continué à travailler sur le problème coriace décrit à l'étape précédente. Il devrait maintenant être complètement éradiqué.
Un beta-testeur par accident (il ne savait pas qu'il utilisait une version beta, ni où télécharger celle-ci) a permis de localiser et corriger une source de crash : si vous créiez un texte qui s'étend sur toute la largeur de la partition (de la première à la dernière mesure), vous risquiez d'avoir des problèmes lors de d'impression.
Un problème d'impression des vues lorsque celles-ci changent l'orientation de la page imprimée (portrait/paysage) avait été signalé il y a longtemps, et corrigé. Il a été signalé à nouveau, et il nous a fallu un peu de temps avant de nous apercevoir qu'il ne se produit que lorsque le document impose la taille de la page. Cela fonctionne apparemment quand le document utilise la taille par défaut de l'imprimante. Nous travaillons toujours là-dessus.
Un problème d'élimination des caractères accentués et non-occidentaux lors de l'export XML avait été corrigé, mais la correction était mal passée dans la version 9.4.0 RC1. Cela a donc été remis en place, et vérifié, cette fois
Un problème persistant, particulièrement coriace, nous a occupé aujourd'hui : l'aplatissement des coulés après certaines opérations.
Lorsque l'on active/désactive l'affichage de la partition transposée, les notes jouées par un instrument transpositeur changent de hauteur affichée, donc peuvent potentiellement changer de sens de tige.
Or, le positionnement automatique du coulé utilise le sens de tige pour savoir où placer les extrémités de ce coulé. Cela oblige donc à recalculer les positions de chaque coulé, à condition bien sûr que le positionnement automatique soit activé sur celui-ci.
Les vues peuvent choisir si, oui ou non, elles sont en affichage transposé, ou en "tonalité de concert". Changer de vue peut donc, dans certains cas, nécessiter de recalculer tous les coulés.
Enfin, "imprimer toutes les vues", par définition, change de vue lors de la procédure d'impression, donc peut également recalculer plusieurs fois les coulés de la partition.
Lors du changement de vue, les coulés se recalculaient mal. L'option "imprimer toutes les vues" fonctionne maintenant correctement, mais les tests intensifs des changements de vues ont fait apparaître d'autre cas qui, eux, ne sont toujours pas résolus. Nous y sommes donc toujours dessus.
Quand je vous disais qu'il était coriace, celui-ci...
Pour débuter la nouvelle semaine, ce sont de vieux problèmes enfouis qui ressortent :
- En mode page, taquets affichés, l'affichage "fantôme" de la clé, tonalité et métrique sur la première mesure est maintenant géré.
- Certaines opérations, comme l'ajout de clé, tonalité, signature temps, rupture, etc, lorsqu'on cliquait en dehors des aires de portées, s'appliquaient à la portée la plus proche trouvée. Il faut maintenant cliquer dans l'aire de la portée. Ce n'est pas très contraignant, et évite que ces objets se retrouvent insérés à un endroit non prévu par l'utilisateur.
- Des problèmes d'impression de copie multiple sur Vista ont été corrigés. Pour ceux que cela intéresse, voici l'explication.
Chaque système d'exploitation a deux manières de gérer les impressions multiples (plus d'une copie de chaque page):
La première, c'est de dire à l'application combien de copies sont demandées, et de laisser celle-ci envoyer plusieurs fois la même page au pilote d'impression. C'est la méthode employée sur Apple jusqu'à récemment, avant la version 10.4 ? (à faire confirmer par Didier).
La seconde, c'est de ne rien dire à l'application, la laisser imprimer une fois chaque page, et que ce soit le pilote d'impression, ou le spouleur/spooler qui se charge d'envoyer les pages plusieurs fois à l'imprimante. C'est la nouvelle méthode employée par MacOS, et la seule que nous avions rencontrée sur Windows jusqu'à XP.
Mais voila. Il semble que Vista, ou tout au moins certains pilotes d'impression sous Vista, ne gère plus la seconde méthode, et lui préfère la première. Donc, toute une partie de code, consistant à envoyer les pages en exemplaires multiples sous Windows, n'avait jamais été exécutée, donc jamais testée. Et, bien sûr, cela ne fonctionnait pas.
Cette partie de code a donc maintenant été corrigée et testée. La seule chose qui ne fonctionnera pas sur Vista, c'est l'impression multiple en copies assemblées, qui consiste par exemple, lorsqu'on veut imprimer en deux exemplaires un document de trois pages, à sortir les pages 1, 2,3 puis à nouveau 1,2,3 au lieu d'imprimer la page 1 en double, puis la page 2 en double, puis la page 3 en double.
Il n'est pas certain que nous ayons le temps de le faire d'ici la sortie de la version définitive, mais cela demeure tout de même un problème mineur, n'empêchant pas l'utilisation de l'application. Cela demandera à l'utilisateur de trier lui-même les pages imprimées, voila tout
- Le recalcul de la position des effets selon la tige, allait une note trop loin. - Correction de la prévisualisation en édition des paramètres de la note. -- Correction de la prise en compte du "tag" $V dans textes libres et entête/pied de page - Le style par defaut nom du groupe a été fixé à celui du nom des portees (préférences générales > Polices) - Correction d'un problème de mémoire quand on ajoute une piste numérique dans "Modifier orchestre" après "Fichier > Nouveau" - Après "modifier orchestre", remise à jour le l'aperçu pour visualiser les changements apportés. -En écriture "Shape note", les formes des notes dans les tonalités mineures se basent sur la tonique de la tonalité majeure équivalente. Il n'y a donc pas de différence de notation entre, par exemple, les notes dans une tonalité de Do majeur, et celles dans une tonalité de La mineur.
- Correction du positionnement des diagrammes d'accord en export MusicXML pour Harmony et PDFtoMusic - Annulation sur "Portées avec paroles" - La version Japonaise a été validée, la Néerlandaise terminée et en cours de vérification. - Le calcul de taille des paroles des chansons, permettant l'espacement automatique et le centrage sous les notes, a été repris. Il ne prend maintenant plus en compte les retours chariot, et gère correctement les accentués et les caractères non occidentaux. - La fonction recommandée par Microsoft (voir billet du 30 janvier) permettant de récupérer les chemins d'accès aux divers répertoires "standards" de l'utilisateurs (Mes Documents, Programmes, etc) ne fonctionne pas directement sur Windows 95. Nous sommes donc à nouveau en train de reprendre l'installateur afin de le faire fonctionner sur cette plateforme.
Voici les travaux de ce jour, ca vient lentement car c'est de plus en plus complexe...
- Correction de l'aspect graphique des fin de barre des multi-silence - Correction du calcul des tablatures accordéon - Affichage des ruptures de début et de fin de répétition en notation Gospel - Dans l'édition graphique des vélocités des notes, il n'est plus possible de modifier la vélocité des silences et silences fantômes. - Une opération de découpage de mesure sur une vue (insertion d'une barre de mesure ou d'une clé au milieu, ajout d'une mesure incomplète...), suivi de "Annuler" ne rétablissait les mesures que sur la vue concernée. Ceci produisait un décalage de mesure d'une vue à l'autre.
Aujourd'hui, pas mal de correspondance avec les différents traducteurs pour essayer de finaliser au maximum le programme avant la sortie publique. Si le Néerlandais et le Japonais sont en de bonnes voies, la traduction en Espagnol est encore largement incomplète.
Il faut savoir que les traductions sont réalisées bénévolement par des utilisateurs enthousiastes, que nous ne saurons trop remercier...
Quelques problèmes assez intéressant sont apparus sur l'Atelier ou par email, nous avons réglé les plus simples, les autres seront traités dans les jours qui viennent car ils risquent de mobiliser un peu plus de temps. En particulier, pour la RC1, nous avons décidés d'utiliser sur Mac deux compilateurs différents, XCode pour la partie Intel et Codewarrior pour la partie PPC. Le code généré par Codewarrior étant tout de même plus optimisé et plus rapide.
- Mauvaise option de configuration de la compilation pour la version Mac PPC, une nouvelle archive a été publiée. - Correction de problème d'affichage de la palette des ruptures. - Correction du déplacement des objets libres de type texte avec rotation. - Correction de problème apparaissant en version PPC sous 10.4 lors de l'édition de l'aspect graphique de la partition. C'était lié à une différence de réaction de la couche Carbon entre 10.4 et 10.5.
Les autres problèmes signalés sont en cours d'analyse et de traitement.
Ca y est la Release Candidate promise est disponible, et dans les délais prévus (j'en entends qui ricanent en douce, mais bon, on n'est pas pressé n'est ce pas ?) C'est d'ailleurs la première fois de notre existence informatique que nous faisons une Release Candidate.
C'est très tendance il paraît.
Il faut maintenant valider cette version et si des erreurs graves sont trouvées, on passera en RC2... Il est sur qu'il reste encore des portions à traduire dans différentes langues, mais cela ne peut en aucun cas avoir des répercutions sur le bon fonctionnement des logiciels.
Comme c'est bientôt le week- end , voici un petit lien à suivre où l'on trouve toute sorte d'instruments des plus étranges :
C'est définitif, les demandes d'améliorations sont au frigo, les bugs signalés ont été FlyToxés, les problèmes mineurs connus répertoriés, nous préparons les bons à tirer pour la première Release Candidate. Un rude chantier qu'il nous tarde de voir terminé afin de passer à autre chose. ScanToMusic est bien placé dans la liste de nos travaux envisagés pour 2008...
Ces derniers mois, nous avons perçu un changement très net dans la communauté des utilisateurs et nous en sommes ravis. Sur le Forum de discussion par exemple, plusieurs membres expérimentés ont pris notre relais dans les réponses aux questions des utilisateurs. Leur aide pertinente a allégé notre travail d'autant. Plusieurs personnes se sont mis à MyrScript et commencent à "pondre" des scripts de plus en plus pointus et grâce à eux un grand bond en avant à été fait. Merci à tous !
Beaucoup de petites corrections de ci-delà, voici la liste des principales :
- PDFtoMusic: prise en compte de l'option "Autoriser les portées multi-voix" lorsqu'elle est désactivée
- Possibilités de crash dans des calculs de position en mode gravure
- Correction de l'importeur de fichier au format Encore au niveau des espaces présents dans les paroles.
Nous avons également pas mal réfléchi à l'accessibilité de nos logiciels aux mal ou non voyants. Depuis quelques semaines nous avons eu des demandes en ce sens. Nous avons donc étudié ce qui existe sous Windows ou Macintosh. Sur Mac, c'est intégré depuis de nombreuses versions via la technologie VoiceOver et cela fonctionne sur 95% des éléments des interfaces de nos produits. Malheureusement, c'est en Anglais uniquement, donc difficilement exploitable. Sur Windows, c'est JAWS qui se charge de la lecture, malheureusement, ce n'est pas automatique comme sur Mac. C'est à l'application de définir les textes à lire. Un gros boulot donc. Nous ne désespérons pas et allons essayer de créer dans les prochains mois un petit groupe d'utilisateurs concernés par le problème pour essayer de dégager des solutions.
Voici la liste de ce qui a été fait ce jour-ci. Essentiellement des corrections de problèmes. Il n'y aura pas de nouvelles fonctionnalités ajoutés puisque nous visons maintenant une version Release Candidate.
- Problème de prise en compte de la marge droite des mesures lors de l'affichage des notes accrochées et le calcul des positions en mode gravure.
- Pas de possibilité d'annuler l'opération "Portées > Ajouter une portée", ce qui pouvait générer des résultats inattendus ou même un crash lorsqu'on utilisait Edition>Annuler après cette opération.
- Correction d'un décalage possible des notes après une opération "Couper"
- Saisie MIDI: suppression de la barre de mesure de fin de morceau apparaissant à la dernière mesure de la saisie
- Lors de la suppression de toutes les mesures, ou de l'insertion de mesures, les débuts de lignes pouvaient mordre sur la marge.
- Création d'un nouveau document : ajout d'un modèle dans la liste, changement du nom des portées.
- PDFtoMusic : jeu de la sélection sur les parties à portées multiples.
Voici tout juste un an que PDFtoMusic a été proposé au public après une longue gestation démarrée au printemps 2007. A l'époque, Michael Good, le créateur du format MusicXML s'était montré intéressé pour le diffuser de son coté en tant que produit innovant gérant le MusicXML. Il nous a demandé à quel prix nous contions le diffuser, nous avons répondu 40 euro (40 dollar). Cela ne lui a pas plu du tout ! Il nous a écrit que nous faisions une grosse c..., enfin, hem, une bêtise.
Les emails ont fusé, comme des guêpes d'une poire bien mûre.
Il nous a suggéré un prix beaucoup plus élevé qui nous a un peu stupéfait. Son objectif était de toucher les professionnels de l'écriture musicale. Ses arguments se tenaient et nous avons décidé de "tenter le coup" en divisant notre produit, au dernier moment, en deux versions:
Une version standard, qui ne pénaliserait pas nos utilisateurs habituels, et une version plus élaborée, avec des réglages fins de la reconnaissance et surtout une possibilité d'export MusicXML vers d'autres logiciels d'édition.
Nous en avons longuement discuté au sein de l'équipe. Cela nous faisait un peu peur quand nous voyions le temps passé avec certains utilisateurs qui avaient acquis une licence pour Melody à 20 euro et qui voulaient impérativement et catégoriquement une résolution immédiate à leur problème, nous nous disions, aie aie aie ! Les pros, cela va être terrible !
Et bien, nous nous trompions lourdement, jamais nous n'avons eu autant de courtoisie et de retenue dans nos échanges. Les demandes et rapports de problèmes étaient clairs, polis, circonstanciés. Nous avons discuté, analysé, corrigé, dépanné, et cela nous a fait plein de contacts sympa avec, par exemple, des compositeurs de musiques de films de la cote Est et Ouest des USA ainsi que du Canada. Et, surtout, nous avons appris plein de choses passionnantes. Alors, merci Michael !
Correction du déplacement des notes d'une sélection discontinue
Il était possible d'insérer des caractères invalides dans les textes des paroles lorsqu'elles étaient tapées sous la portée. Par exemple, la touche "Orig" (retour en début de ligne) générait un crash.
Windows Vista: le menu du CD-ROM de la base de sons GOLD ne parvenait pas à lancer l'installateur. Un "patch" a été inclus dans la nouvelle version de nos installateurs. Sur Vista, il suffira donc d'installer une version récente de n'importe laquelle de nos applications pour que le CD-ROM GOLD fonctionne par la suite.
Pistes numérique: correction de l'action "couper"
- Import XML: les liaisons à l'envers (depuis la fin de la partition vers le début) sont maintenant éliminées.
Le coloriage des objets graphiques était désactivé depuis quelques versions, cela a été rétabli.
Le déplacement d'objet graphique pouvait entrainer un changement de taille, c'est corrigé.
Dans certains cas de mise en page, les objets graphiques pouvaient être étirés horizontalement, corrigé également.
L'installation d'une palette MyrScript, via une archive .msa, mets automatiquement à jour la palette si elle est ouverte.
Nous espérons produire une première version pré-publique (RC) la semaine prochaine.
