Aujourd'hui nous avons travaillé notamment sur la manière de gérer des vues en MyrScript, le langage de programmation intégré à Harmony Assistant. Il fallait permettre de gérer tous les paramètres des vues, et d'altérer le contenu de chacune des vues, sans que les programmes déjà écrits en MyrScript ne nécessitent d'être repris. Nous avons donc opté pour une solution relativement simple, mais qui ne permet pas de travailler extrèmement facilement sur plusieurs vues simultanément : la gestion d'une "vue courante", qui conditionne toutes les opérations effectuées ensuite sur les paramètres auxquels on accède. Par exemple, pour faire apparaître la première portée du conducteur dans la première vue partielle, il faudra écrire quelque chose comme: -- L'index 1 correspond à la vue générale -- et l'index 2 à la premiere vue partielle vue=score.Views[2] -- Fixe la vue courante score.SetCurrentView(vue) -- A partir d'ici on travaille sur la vue n°2 (1e vue partielle) score.FirstStaff.IsPrinted=true -- La 1e portée est maintenant visible dans cette vue Le système a l'air de bien fonctionner, et d'être relativement simple d'emploi. Seule contrainte, lorsqu'on veut recopier un certain nombre de paramètres d'une vue sur une autre, il vaut mieux fixer la 1e vue comme vue courante, copier tous les paramètres désirés dans des variables locales, puis fixer la 2e vue comme vue courante et recopier les variables locales dans la 2e vue, plutôt que de passer d'une vue à l'autre à chaque paramètre. Il ne reste plus qu'à mettre en place la création, suppression et déplacement de vue, et MyrScript devrait alors être complet sur ce point. |
|
|
by Olivier Guillion | | |
| |
|

Plusieurs améliorations ont été finalisées ou entamées. - La possibilité de couper les barres d'accroche sous les crochets de tuplets a été finalisée, laissant toute latitude dans les découpes possibles : - Les appoggiatures en accord ont été mises en place. C'est encore à l'état de prototype, mais ces appoggiatures peuvent d'ores et déjà être affichées et jouées : - Il nous avait été demandé, lorsqu'on copie/colle un groupe de note et que l'option d'accroche automatique est désactivée, que les barres d'accroche restent identiques à ce qu'elles étaient à l'origine, sans modification. Cela est malheureusement impossible, car les tiges de notes marquées "automatique" vont se recalculer en fonction de la position des notes collées sur la nouvelle portée. Et si certaines tiges changent de sens, les groupes de notes accrochées vont créer un résultat très étrange. Alors, nous avons mis en place ceci: les accroches ne sont recalculées que si la portée sur laquelle on colle n'est pas de même type que celle depuis laquelle on a copié les notes. Ainsi, si on copie et on colle sur une portée en clé de sol, les accroches resteront identiques. Par contre, si on copie depuis une portée en clé de sol et qu'on colle sur une portée en clé de fa, les accroches risquent de se recalculer. |
|
|
by Olivier Guillion | | |
| |
|

Après avoir examiné les alternatives aux pilotes Twain sur Macintosh, nous avons fait de même sur Windows. D'après ce que nous avons compris, c'est plus compliqué mais pas nécessairement mieux. Au tout début, chaque constructeur de scanner fournissait le logiciel d'acquisition spécifique. Puis très rapidement, tout le monde s'est mis à la norme TWAIN. Ensuite, à partir de Windows 98, Microsoft a introduit StillImage, une architecture de pilote permettant de gérer scanners, appareils photos, et tout autre périphérique permettant de produire une image fixe. Ces pilotes sont censés permettre un plus grand contrôle de l'interface graphique du pilote (boites de saisie, de configuration du scanner) dans un format normalisé. Et surtout, un pilote StillImage peut lancer l'application qui traite son acquisition d'image, alors que pour le TWAIN, c'est à l'application de demander au scanner. Par exemple, c'est grâce à StillImage que lorsque vous appuyez un bouton sur votre scanner, cela peut lancer l'application d'acquisition correspondante. TWAIN est donc considéré comme "obsolète" par Microsoft, mais il est demandé aux développeurs de pilotes de conserver la compatibilité. Donc, les pilotes compatibles StillImage sont censés offrir également un accès compatible TWAIN. Et c'est apparemment le cas. De toute façons, StillImage n'est disponible que sur Windows 98, ME, XP et probablement Vista, et absent de 95, NT et 2000. Mais d'autres sources le donnent disponible pour 95, 98 et 2000. Puis, histoire de simplifier tout cela, Microsoft, avec Windows Millenium (donc deux ans après StillImage) a sorti le "standard" WIA (Windows Image Acquisition), qui semble être une surcouche à StillImage. Là aussi, un pilote WIA est censé assurer une compatibilité TWAIN. WIA serait disponible sur Windows ME et XP, probablement Vista, et absent de 95,98, 2000 et NT. Donc, en conclusion, tous ces nouveaux types de pilotes, même s'ils pourraient faciliter l'acquisition d'images, ne sont pas disponibles sur tout les systèmes, et tous les constructeurs ne les ont peut-être pas adoptés. Donc, plutôt que d'écrire, dans ScanToMusic, un module d'acquisition TWAIN, un autre pour StillImage et un autre pour WIA, avec un test de présence de chacune de ces technologies, il est apparemment plus facile et plus sage de s'en tenir au TWAIN, même s'il peut apparaître un peu spartiate. Les trois technologies ayant un noyau commun, le TWAIN, on est donc à peu près assuré de respecter une compatibilité maximale en utilisant celui-ci. |
|
|
by Olivier Guillion | | | |
|

Nous avons commencé à regarder comment gérer le pilotage des scanners directement depuis le logiciel. L'expérience OMeR nous avait montré que l'utilisation des accès aux pilotes à la norme TWAIN faisait souvent apparaître des problèmes de compatibilité. Les pilotes, souvent assez mal écrits, ne suivent quasiment jamais les spécifications complètes de la norme. Ils sont testés par les constructeurs sur les logiciels ténor du marché de l'infographie, et apparemment débuggés spécifiquement sur ceux-ci. Cela veut dire en gros que si votre logiciel n'accède pas exactement aux mêmes fonctions du pilote du scanner, ou pas dans le même ordre que Photoshop, vous prenez le risque de rencontrer quelques problèmes sympas, qui ne surviendront par exemple qu'avec la version 3.94 du pilote du scanner Agfanon SuperFine 1293 S. Sur Mac OS X, le principe annoncé du système est de s'affranchir au maximum des accès direct au périphériques et d'offrir au développeurs des interfaces de haut niveau permettant de piloter les périphériques, par exemple, les scanners. Nous avons donc téléchargé le kit "Image Capture", présenté comme un sur-ensemble au TWAIN. Cela semblait alléchant, documentations, exemples en Carbon et Cocoa d'acquisition depuis un scanner, tout le toutim. Le kit gère lui-même l'interface d'acquisition et obtenir une image est des plus simple pour le développeur : un simple appel à ICAImportImage et Mac OS X gère les paramètres d'acquisition, la prévisualisation, le choix de la source. Magnifique ! En théorie... Car les applications d'exemple fournies ne fonctionnent pas et datent de 2005. Une recherche sur l'Internet montre que les problèmes sont évidents et signalés par tous les développeurs. Sans aucun correctif d'Apple. Il faut dire que le développement d'IPod et d'IPhone a du les épuiser, les pôôvres. Donc sur Mac OS X nous en resterons aux accès basiques au TWAIN, faute de mieux. |
|
|
by Olivier Guillion | | | |
|

Nous avons mis en place, sur notre site, plusieurs protections permettant d'éviter qu'un utilisateur surcharge le serveur. Il faut garder en mémoire que l'accès à une page dynamique (blog, forum), fait tourner un petit programme sur le serveur, et donc que le résultat (la page) n'est pas délivré instantanément. Imaginons maintenant que quelqu'un demande 200 pages différentes d'un coup, cela va faire tourner 200 "instances" du programme en même temps, surchargeant et ralentissant le serveur. Cela peut arriver lorsque quelqu'un utilise un "aspirateur de site" (voir cet autre article du blog) Nous avons donc mis en place des barrières, qui bannissent d'office de notre site ces visiteurs indélicats. Cependant, les moteurs de recherche tels que Google, Yahoo ou Microsoft MSN doivent récupérer toutes les pages du site de temps en temps, et nous ne désirons pas les bannir. Ces "spiders" devant respecter certains critères, tels que la prise en compte du fichier "robots.txt"ou l'attente d'un certain délai entre deux saisies de pages, ils ne se faisaient pas prendre dans les pièges tendus aux aspirateurs de site personnels. En Anglais, de tels pièges sont appelés "honeypot" (pot de miel). Mais depuis quelques mois, le robot de MSN, appelé MSNBot, ne tient apparemment plus compte des interdictions qui lui sont adressées, et tombe alors dans le pot de miel. Résultat, les adresses MSN se retrouvent bannies et interdites d'accès à notre site, ce qui fait qu'à la visite suivante le robot croit que notre serveur ne fonctionne plus. Cela aura pour conséquence, à terme, de faire disparaître toutes nos pages des recherches par MSN. Etant donné qu'il me paraît difficile de contacter M. Microsoft pour lui demander gentiment de corriger ce problème, je suppose qu'une fois de plus, nous devrons mettre en place des systèmes spécifiques afin de tout faire fonctionner quand même. C'est l'éternelle histoire du pot de fer contre le pot de miel |
|
|
by Olivier Guillion | | |
| |
|

Le développement de ScanToMusic a repris. Une réorganisation complète des fichiers "source" de l'application a été entamée, afin de classer les différentes fonctions par thème. Cela devient obligatoire lorsqu'un projet grossit, afin de nous permettre de trouver rapidement l'endroit où chercher telle ou telle fonction lorsque nous avons besoin de l'améliorer ou de la débugger. Pour donner une idée, un projet comme Harmony Assistant est consitué de près de 700 fichiers source, et PDFtoMusic d'environ 250. Dans ScanToMusic, nous allons essayer de réutiliser au maximum le temps déjà investi dans PDFtoMusic. Toute la partie d'analyse de "haut niveau" de ce dernier, qui, à partir des commandes graphiques trouvées dans un PDF, reconstitue une partition éditable, va resservir. Le problème se résume donc ainsi : à partir d'une page scannée, recréer une collection de commandes graphiques (basiquement, tracé de ligne, affichage de caractère et affichage d'image) qui aurait pu être utilisée pour créer la page. En fait, "vectoriser" l'image scannée, mais de manière logique compte tenu des règles d'écriture musicale. Cela réduit le problème à sa portion congrue, mais ne le résout pas pour autant. Il faut maintenant attaquer les divers modules de détection/reconnaissance qui manquent, et améliorer ceux qui ont été déjà écrits. |
|
|
by Olivier Guillion | | |
| |
|

Avec mon nouveau PC, je me suis enfin décidé à franchir avec allégresse un fossé technologique, et j'ai pris un clavier et une souris sans fil. Auparavant, j'utilisais un bête clavier pas hype du tout, et une souris optique de base. Au premier abord, tout ceci fonctionne bien. La souris est précise, la frappe sur le clavier est agréable, et on peut les emporter à l'autre bout de la pièce, ça continue à fonctionner. Bon, d'accord, il n'y a aucun intérêt, puisqu'on ne voit plus ce qu'on tape ni le pointeur de la souris, mais c'est fun. Mais très vite, on se rend compte que toute médaille a son revers. Pour économiser les piles, le clavier ne consomme du courant que lorsqu'on tape sur une touche. Donc, exit les petites lumières du verrouillage des majuscules et du pavé numérique. C'est remplacé par un indicateur "logiciel" en bas de l'écran, et un gros texte vert en surimpression pendant quelques secondes lorsqu'on utilise ces touches de verrouillage. Pas toujours évident, surtout quand on utilise des machines virtuelles en fenêtre, où chacune a un état différent pour ces touches. r2SULTAT/ PARFOIS JE ME M2LANGE UN PEU LES PINCEAUX ; Pour la souris, ça se complique encore plus. Précise, d'accord. Mais alourdie par le poids des piles, on ressent l'inertie. Sinon, ergonomiquement ce n'est pas trop mal, même si, peut-être est-ce poussé par la force de l'habitude, je n'ai jamais utilisé les deux petits boutons supplémentaires au-dessous de la roulette, ni la possibilité de pousser cette roulette vers la droite ou vers la gauche pour faire je ne sais quelle opération. Mais le plus gros problème, ce sont les piles. Le petit animal en consomme une quantité étonnante, et régulièrement, la petite lumière clignotante qui annonce un niveau faible finit de sécher les derniers mW des alcalines longue durée. Lorsque je déplace la souris sur la table, il me semble même entendre un petit bruit de succion. Je sais, il y a des modèles avec des batteries, qu'on peut poser sur un support lorsqu'on ne s'en sert pas. Mais je me connais, je sais pertinemment que j'oublierais de la reposer sur sa base (si, si, je le sais, j'ai un téléphone sans fil). Alors, au prochain changement de pile, je crois que je vais exhumer ma bonne vieille souris filaire. Ca ne devrait pas être pour dans très longtemps, voila la petite lumière qui se remet à clignoter. |
|
|
by Olivier Guillion | | |
| |
|

Sur notre serveur Web (l'ordinateur qui vous délivre les pages que vous voyez en ce moment), de petits programmes permettent d'obtenir des pages "dynamiques", c'est-à-dire qui dépendent de choix effectués par l'utilisateur. Certains scripts tournent depuis si longtemps que nous finissons -presque- par en oublier l'existence. Ainsi, il y a plus de 3 ans, nous mettions en place celui que nous appelons "lostcode", et qui permet aux clients qui ont égaré leur code d'enregistrement de le retrouver automatiquement par e-mail. Ce petit programme nous fait économiser un temps considérable, en nous évitant de rechercher à la main quotidiennement plusieurs dizaines de demandes. Il y a donc sur notre serveur une base de données fortement cryptée (au cas où un hacker ne passe par là), contenant les adresses e-mail de nos clients et les codes d'enregistrement associés à chacune d'elles. Nous mettons cette base de données à jour manuellement de temps en temps, ce qui explique que cette recherche automatique risque de ne pas donner de résultat si votre achat date de moins d'un mois. De même, les personnes qui ont, depuis l'époque de leur achat, changé d'adresse e-mail doivent demander une recherche manuelle qui est généralement traitée rapidement. Les cas les plus complexes, du type : "j'ai déménagé et changé d'adresse e-mail, je m'appelais M. Sapue, mais j'ai fait changer mon nom - vous imaginez pourquoi - et je m'appelle maintenant M. Sassan", quelques échanges d'e-mails sont nécessaire afin que nous vérifiions que ce n'est pas un voisin ou une connaissance qui essaie de "piquer" le code d'un utilisateur dûment enregistré. Il y a malheureusement encore énormément de personnes qui n'ont pas connaissance de notre robot "lostcode" et qui écrivent directement au support technique. Nous en recevons plusieurs chaque jour, et dans 99% des cas, le message est du type : "Mon PC est mort, et j'avais tout dessus. J'ai dû reformater mon disque dur, et j'ai perdu le mail contenant mes code,". Nous les dirigeons alors vers "lostcode". Mais, au risque de nous répéter... faites régulièrement des copies de vos documents et de vos e-mails, ou, mieux, imprimez le mail contenant vos numéros d'enregistrement, rangez-le dans un classeur, et effacez l'e-mail, comme nous le préconisons. Ce n'est pas de la paranoïa, mais l'espérance de vie d'un disque dur est largement inférieure à celle d'une simple feuille de papier rangée au sec et à l'obscurité, et il nous est arrivé de voir passer des codes d'enregistrement dans des messages envoyés à leur insu par des clients infectés par un virus. |
|
|
by Olivier Guillion | | | |
|

Nous avons travaillé sur des améliorations de la mise en page. Certains changements que nous avons apportés pourront changer la taille des mesures, donc modifier la disposition sur le papier de documents créés avec les versions précédente. - Les tailles du couple de mesures affectées à un signe de répétition des deux mesures précédentes ont été réglées de manière à obtenir deux mesures de égales. Ceci peut changer la taille d'une ligne de mesures, donc générer des retours à la ligne là où il n'y en avait pas auparavant. - Lorsque des altérations étaient écrites entre parenthèses, la taille des symboles de parenthèses n'était pas prise en compte dans les calculs permettant d'éviter le chevauchement des symboles. C'est maintenant chose faite, mais cela peut entraîner un changement dans la mise en page de ces mesures. - Enfin, le paramétrage du mode gravure lors d'un export MYR depuis PDFtoMusic / PDFtoMusic Pro a été corrigé. Les fichier .myr qui seront exportés avec la nouvelle version, une chargés dans Harmony Assistant, se retrouveront en mode gravure, avec les paramètres par défaut. Donc avec la prochaine version de PDFtoMusic, si vous exportez un fichier que vous aviez déjà traité auparavant, son aspect graphique sous Harmony Assistant sera différent. |
|
|
by Olivier Guillion | | |
| |
|

On nous a fait remarquer que la police de caractères utilisée pour montrer les résultats de la reconnaissance n'était pas celle du document original. En effet, le résultat de la reconnaissance est destiné à montrer le texte qui a été déterminé par l'analyse, et nous avions considéré que l'afficher en police "Times" était suffisant. Mais, pour l'export XML ou Harmony, le programme choisit une police "standard" qui est supposée être proche de la police originale, encapsulée dans le document PDF. Donc, utiliser cette information dans l'affichage des résultats de la reconnaissance était possible, et permettait d'obtenir un meilleur aspect. A partir d'un PDF qui contient ceci : la version actuelle montre ceci : alors que la prochaine version montrera cela : ce qui "colle" beaucoup plus à l'aspect original. |
|
|
by Olivier Guillion | | |
| |
|

Après plusieurs jours passés à tenter vainement de contacter France Télécom, nous avons enfin réussi à avoir quelqu'un. Comme nous nous y attendions, nous nous sommes vus opposer un refus catégorique: "Nous connectons là où il y a de la place. L'abonné ne peut pas décider de l'endroit où il est connecté." On pourrait se satisfaire de cette réponse si la "cartographie" du réseau était claire et bien établie. Mais dans une rue où, dans un même bâtiment, les différentes lignes téléphoniques sont connectées à des noeuds différents, on peut se dire qu'ils choisissent en fonction de leurs petites contraintes techniques (2m de fil à tirer en plus, 2 connexions à faire au lieu d'une) et s'assoient sur la demande de leur client, sans se soucier de ce qui a pu être promis avant. Donc, pour le déménagement futur de notre ligne principale, même si on nous affirme que cette ligne sera connectée là où on veut, on ne le saura vraiment qu'au moment où ça sera fait. Il faut trouver une autre solution. Nous lorgnons donc vers Internet par le câble. J'ai eu quelques échos diffus me laissant à penser que cela ne fonctionne pas très bien, et le fait que les offres les plus puissantes (100 Mbps) aient un quota maximal mensuel de trafic de 50 Go de données me conforte dans le sentiment qu'ils redoutent l'effondrement total de leur réseau si les clients se mettent à s'en servir vraiment. L'interdiction, dans les Conditions Générales de Vente, d'héberger un serveur sur la connexion câble est proprement ahurissante, et m'amène à penser qu'ils ont vraiment des problèmes. 50 Go, c'est ce que nous avons fait en 8 jours en proposant le CD-ROM en Peer-to-Peer (à propos, doit-on considérer qu'utiliser le P2P équivaut à faire tourner un serveur?). Si cela continuait à ce rythme-là pendant un mois, la même chose sur un abonnement câble à 100Mbps nous reviendrait à 170¤ (30¤ d'abonnement + 14 tranches de 10 Go au-delà des 50 permis, à 10¤ chacune). Nous allons donc probablement nous orienter sur la formule 30 Mbps à 20¤ par mois, qui, elle, n'est pas limitée par un quota. Et puis de toute façon, après vérification, l'offre 100Mbps n'est pas disponible sur Toulouse Si l'un d'entre vous a déjà pu tester ce type de connexion à Internet, les opinions, témoignages et avis sont bienvenus. |
|
|
by Olivier Guillion | | |
| |
|
|