Myriad Blog 1.3.0 Saturday, Nov 1st, 2014 at 07:22am 

To be seen Friday, May 5th, 2006 at 04:35pm
Débranche, débranche tout
Ne vous êtes-vous jamais demandé quelle puissance électrique consomme votre ordinateur lorsque vous vous en servez ?
Et lorsque vous ne vous en servez pas ?
 
On nous rabat en permanence les oreilles avec la consommation des appareils en veille, mais jamais personne ne donne de valeur fiable, mesurée, et peu de gens ont eu l'occasion de le vérifier sur leurs propres appareils, chez eux.
 
Cela faisait longtemps que je pensais à me fabriquer une prise gigogne, connectée à un ampèremètre, qui me permettrait de faire cela. Trop longtemps. On trouve maintenant un peu partout des petits machins tout faits de ce genre. Outre la consommation instantanée, ils permettent de calculer la consommation cumulée sur une période, et même de donner le prix que cela a coûté.
 
Je vous livre donc les valeurs que j'ai pu collecter sur du matériel informatique, à titre d'info. Pour vous donner une idée, une puissance de 1W consommée jour et nuit pendant un an correspond approximativement à 1 euro sur la facture annuelle.
 
AppareilEteint (W)En veille (W)En marche (W)(1)
Ordinateur PC P-IV 3 GHz 2,34,190 à 160 (100)
Barebone PC AMD 2 GHz 2-70 à 90 (80)
Ordinateur PC P-III 1.6GHz4,3-60 à 110 (70)
Ordinateur Mac G4 Bipro 1.2GHz7,312,6130 à 150 (135)
Moniteur 19" cathodique Samsung 04,2580 à 100 (85)(2)
Moniteur 19" plat Viewsonic0022,3 à 24 (23)(2)
Freebox V4-9,49,4

(1) Les valeurs données sont : minumum, maximum et moyenne entre parenthèses
(2) La consommation varie en fonction de la luminosité de l'image.
 
Chose amusante, la consommation d'un ordinateur est dépendante du travail qu'il fournit. Un gros calcul peut lui faire consommer jusqu'à 40 à 60 W de plus que lorsqu'il attend simplement que vous bougiez la souris.
 
Encore plus surprenant, un ordinateur éteint (grâce au bouton de la face avant) continue à consommer pas mal d'énergie. Est-ce parce que le circuit primaire de l'alimentation reste sous tension ?
 
Et à titre de comparaison, quelques autres consommations d'appareils hi-fi ou vidéo courants:
 
AppareilEn veille (W)En marche (W)(1)
Téléviseur cathodique 70cm (années 90) 1680 à 130 (100)(2)
Graveur DVD de salon à disque dur328
Décodeur satellite413
Magnétoscope VHS29
Chaine Hifi Sony (années 90)9,720 à 24

 
En faisant la somme des consommations des appareils en veille, on arrive rapidement à un résultat non négligeable, même si les constructeurs ont fait de gros progrès en ce sens ces dernières années (à l'exception d'Apple, apparemment...). Cependant, je n'irai pas jusqu'à conseiller de débrancher tous les appareils lorsque vous ne vous en servez pas. Les magnétoscopes, par exemple, sont connus pour avoir des alimentations fragiles qui ne supportent pas bien ce traitement. Et la réparation de l'appareil risque de vous coûter plus que ce que vous auriez économisé...
by Olivier Guillion
 3 comments.

Dev News Sunday, May 7th, 2006 at 10:35am
Les mystères du "crash.log"
Si vous êtes utilisateurs de nos produits sur PC, vous avez peut-être eu la malchance de voir apparaître un jour, avant que le programme ne se ferme inopinément, une petite boîte d'alerte vous demandant de nous renvoyer un fichier appelé "crash.log".
De quoi s'agit-il exactement, et quels renseignements peut-il nous apporter?
Je vais tenter d'y répondre, sans trop entrer dans les détails techniques.
 
Le microprocesseur de votre ordinateur, lorsqu'il est en train d'exécuter une application, utilise, pour stocker les valeurs intermédiaires de ses opérations, une série de mémoires internes appelées "registres".
Il sait à tout moment, grâce à ces registres, à quel endroit il est dans le programme (donc quelle sera la prochaine instruction à effectuer), quelles sont les zones de mémoire auxquelles il va accéder, en un mot tout ce qui définit son état à un instant donné.
 
Lorsqu'une erreur survient (division par zéro, tentative d'exécuter une instruction inconnue pour ce microprocesseur, tentative de lire ou d'écrire dans une zone de mémoire non valide), le programme s'arrête et génère une "exception".
Ces exceptions, donc la plus connue est numérotée "C0000005" (justement, lecture ou écriture dans une zone de mémoire non valide) sont traitées par défaut par Windows, et provoquent l'apparition d'une boîte disant qu'un problème a été rencontré, et qu'un rapport d'erreur peut être envoyé à Microsoft.
 
Aux dernières nouvelles, ces rapports d'erreur, à leur arrivée chez Bill, s'ils ne concernent pas des produits Microsoft (et même!), sont envoyés directement dans un dossier spécial, appelé poubelle, corbeille, ou classement vertical selon les jours. Ils ne sont donc d'aucun intérêt pour nous, ni pour personne d'autre, d'ailleurs.
 
Dans nos produits, nous avons donc remplacé ce traitement inutile par la génération d'un fichier "crash.log", qui contient tous les renseignements nous permettant de savoir ce qui s'est passé:
 
- Nom et version de l'application
- Date de création de l'application
- Version de Windows de l'utilisateur
- Date et heure du crash (GMT)
- Type d'erreur rencontrée
- Liste des registres du microprocesseur
- Instructions en cours d'exécution lors du crash
- Et enfin, contenu de la "pile", zone mémoire permettant de connaître le sous-programme ayant appelé la fonction en cause, ainsi que le sous-programme ayant appelé ce sous-programme, etc.
 
A partir de cela, nous pouvons généralement savoir:
- l'application ayant subi le crash, ainsi que sa version,
- la version de Windows,  
- approximativement quelle était l'opération effectuée lorsque le crash est survenu (mais pas toujours).
 
En aucun cas nous ne pouvons connaître le détail de ce que faisait l'utilisateur à ce moment-là, sur quel fichier il travaillait, ce qu'il voyait à l'écran, quelle tête il a fait en voyant apparaître la fenêtre d'erreur (quoique, s'il avait sa webcam branchée...), donc une explication, même succinte, des conditions dans lesquelles cela s'est produit, le fichier en cause, bref tout ce qui nous permet de reproduire le problème chez nous, est absolument indispensable.
 
Dès que nous pouvons reproduire une erreur à volonté, 99% (ou même plus) du travail est déjà fait, et c'est donc l'assurance d'une correction rapide.  
Alors, en pensant à nous, vous pensez aussi à vous...
by Olivier Guillion

Myriad Life Tuesday, May 9th, 2006 at 07:15pm
B.A.T.
Les nouvelles versions d'Harmony Assistant (9.2), Melody Assistant (7.2), Myriad plug-in (5.2) et Melody Player (4.2) ont été mises à disposition aujourd'hui.
Cela concrétise une session de beta-test de quatre mois (la plus longue de notre histoire), accompagnée de centaines de corrections et améliorations diverses.
 
Une journée de sortie de nouvelle version n'est pas une journée habituelle. C'est un peu comme lorsqu'on part en voyage en emmenant tout un lot de valises : on fait attention à penser à tout, et lorsqu'on est enfin parti, on a toujours l'impression d'avoir oublié quelque chose, ce qui s'avère généralement être le cas, d'ailleurs.
 
Même chose ici : une dernière compilation, quelques tests pour voir si tout fonctionne, puis vérification des fichiers de données (où est donc passé le fichier d'accordage du dulcimer à bretelles ? Tu ne me l'as pas passé ?), et création des archives installables compactées.
Ici, nous appelons ça les B.A.T. (de Bon A Tirer), d'où les néologismes Myriadien "un bat" (prononcer "batt") et "bater":
"- C'est aujourd'hui qu'on bate
ou
- Quoi, t'as pas baté le plugin ? Ane bâté!"
 
Avec 4 plateformes différentes (Windows, Mac OS X Intel, Mac OS X powerPC et Mac OS 9) pour 4 produits, ça en fait un paquet, de "bats".  
 
J'ouvre alors ma "to do list", pour essayer de ne rien oublier.
 
Une dernière vérification "à blanc" de l'intégrité de ces archives en téléchargeant sur notre intranet et en les essayant, puis il faut les poster sur notre site externe. C'est gros et ça prend du temps, dont on profite pour préparer la mise à jour des numéros de version sur les pages Web, ainsi que les "quoi de neuf".
 
Suit la création des archives monobloc pour nos sites miroir. Il y en a une trentaine, et elles permettront de déporter une partie du trafic de téléchargement hors de notre site principal.  
 
C'est généralement aux alentours de ce moment qu'on reçoit un mail disant qu'il y a un gros problème dans la version beta, ce qui nous oblige à corriger en vitesse, et à tout recommencer depuis le début.
 
Ensuite, pour changer, vérification des archives postées: téléchargement et essai de chacun des produits (ce n'est jamais que la troisième fois).
 
Enfin, on poste les pages Web, on l'annonce dans le forum de discussion et on envoie les lettres d'information par e-mail.  
Et c'est alors qu'on s'aperçoit que la journée est finie, et qu'il est temps d'aller manger un sandwitch, prendre une bonne dose d'aspirine et aller au lit.
 
Le reste, ce sera pour les jours suivants. D'expérience, je peux vous dire qu'il y en aura toujours au moins un qui attend patiemment que la session de beta-test soit terminée pour entamer des essais en profondeur de la nouvelle version et dénicher les problèmes. Quand il ne se contente pas d'envoyer un message du type "l'import de fichier Finalius ne fonctionne toujours pas", alors qu'il ne nous en avait jamais averti auparavant...
 
On s'attend donc toujours à devoir sortir une sous-version dans la semaine qui suit. Une autre belle journée en perspective...
by Olivier Guillion
 1 comment.

Mood Friday, May 12th, 2006 at 07:54pm
Du sang, de la sueur et du code
Depuis quelque temps déjà, Metrowerks a abandonné sa version du compilateur C/C++ Codewarrior sur Windows et Mac OS.
C'était un produit excellent, tant en terme d'ergonomie que de performances, et qui n'est égalé par aucun des produits restant sur le marché.
 
Car le choix des compilateurs C (outils permettant de développer des programmes dans ce langage) s'est fortement réduit ces dernières années, ceci étant probablement lié à la complexité grandissante des "couches" propriétaires des systèmes d'exploitation (.NET, Cocoa...), et des langages spécifiques (C#, Objective C...) qui sont apparus.
Ces langages plus ou moins "propriétaires", s'ils ne sont pas mauvais en eux-mêmes, posent cependant le problème de la portabilité des applications d'une plateforme à l'autre. Alors qu'avec un bon vieux source C bien écrit, ce problème ne se posait -presque- pas.
 
Basiquement, sur PC il ne reste plus que Microsoft Visual C/C++, bien adapté à de gros projets, mais à l'ergonomie contestable, truffé de gadgets microsoftiens permettant de créer des objets très spécifiques, destinés à fonctionner uniquement sur Windows.
Quelques essais de portage d'interface graphique autour de compilateurs issus du monde du libre (GCC) on bien été tentés, mais jamais transformés.  
 
Sur Macintosh, cet essai a également été tenté, et a abouti à XCode, qui est bien meilleur que les timides tentatives sous Windows, mais malgré tout largement au-dessous de ce qu'avait réalisé Metrowerks en son temps, et qui pose la question cruciale du développement de gros projets sous Mac OS X. Le compilateur est extrèmement lent, ne génère pas un code très optimisé, et on sent bien le "raboutage" de parties disparates qui a été effectué pour créer ce produit.
Pour ce qui est de la rapidité et de l'optimisation, au moins sur MacTel, la solution pourrait passer par Intel, qui propose un compilateur utilisable dans XCode. Le prix semble cependant plutôt prohibitif ($400) pour un simple module de compilation. Nous n'avons pas encore eu l'occasion de tester cette solution.
 
Ce que je n'arrive pas à m'expliquer, c'est pourquoi, lorsqu'un éditeur de logiciels abandonne un produit sans espérer un jour le reprendre, il ne rend pas public le code source de l'application, laissant une communauté d'utilisateur (qui, de plus, sont ici tous des programmeurs) continuer son développement en "libre". Quelle perte financière cela entraînerait-il?
 
Et Metrowerks n'est pas le seul exemple. Apple a abandonné purement et simplement le développement de ses outils de développement Macintosh Programmer Worskhop. Pourtant, l'équipe Apple chargée de MPW était d'accord pour passer le logiciel en OpenSource et ne pas trancher la gorge aux développeurs qui avaient naïvement suivi leurs recommandations. C'est la division "juridique" qui a mis son véto au dernier moment. Apple semble vouloir agir de même avec son éditeur de ressources Resedit, préférant, pour des raisons obscures de copyright, laisser les programmeurs dans la mouise plutôt que de leur permettre de continuer à développer confortablement (sur des machines Apple, qui plus est).
 
Malheureusement, beaucoup de décisions de ce type sont plus politiques que dirigées par le bon sens, et, pour ces sociétés, le respect de leurs propres clients semble être le cadet de leurs soucis.
by Olivier Guillion

Dev News Saturday, May 20th, 2006 at 07:51pm
Du glyphe à l'Unicode (1)
Dans le cadre du projet "PDFToMusic" (voir les autres articles), nous avons été amenés à étudier les divers moyens d'effectuer une reconnaissance simple de caractères. Ceci permettrait, lorsqu'on trouve dans un fichier PDF un caractère dessinant par exemple une clé de sol, de savoir qu'il s'agit bien d'une clé de sol et pas d'autre chose.
 
Dans ce projet, contrairement à une véritable reconnaissance de textes scannés, nous avons seulement besoin de différencier les caractères individuels au sein d'une fonte, ce qui supprime d'un coup plusieurs problèmes inhérents aux reconnaissances optiques conventionnelles :  
 
1- Les caractères sont "propres", c'est-à-dire que tous les pixels sont à leur place, qu'il n'y a pas de possibilité de poussière, ou défaut de numérisation qui pourraient perturber la reconnaissance
 
2- Les caractères sont isolés. On connait exactement la taille et la position du caractère à analyser. Impossible d'avoir malencontreusement deux caractères consécutifs confondus avec un seul (notamment avec des paires commes "ff" ou "ft" dont les constituants se touchent graphiquement), ou un caractère coupé en morceaux comme par exemple avec les deux points de la clé de fa.
 
Une première étape, de pré-analyse, consiste à voir s'il n'y aurait pas des valeurs et paramètres quantifiables, indiscutables, permettant de se passer d'intelligence artificielle ou de calculs statistiques complexes pour identifier le caractère.
 
Une première maquette est écrite en MyrScript.
 
Le caractère est affiché, puis le nombre de pixels "noirs" sur chaque ligne et sur chaque colonne est calculé. Un double histogramme est alors tracé, avec des couleurs dépendant du nombre de "trous" détectés lors du balayage de la ligne ou de la colonne.
 
Ensuite, divers traitements sont essayés.
 
Le premier combine les histogrammes horizontaux et verticaux afin d'obtenir une "empreinte" du caractère. Nous la calculons avec le même caractère dans diverses fontes musicales, mais malgré d'assez importantes similitudes, cela ne semble pas être suffisamment "stable" pour permettre une reconnaissance.
 
Deuxième essai. L'aspect du caractère est analysé, et les "directions" des tracés sont extraites. Le graphe obtenu montre en rouge les lignes "plutôt verticales", en vert les lignes "plutôt horizontales" et en bleu les lignes "plutôt diagonales". Une comparaison directe de ces paramètres à un jeu-type semble difficile, mais les résultats sont suffisamment significatifs pour garder ceci dans un coin et ne pas le jeter tout de suite.
 
Troisième essai. Afin de s'abstraire de l'épaisseur des traits constituant le caractère, le script tente de le "fildefériser", de réduire tous les traits à un seul pixel d'épaisseur. Si cela ne permet pas de déterminer ce qu'est le caractère, cela pourrait au moins être utilisé pour simplifier une comparaison ultérieure.
 
Beaucoup des programmes que nous écrivons sont seulement des tests destinés à finir à la corbeille. C'est probablement le cas de ce petit outil d'analyse, qui nous a permis d'expérimenter quelques techniques, et d'essayer d'extraire des paramètres quantifiables du graphisme d'un caractère.
 
La reconnaissance du caractère s'avère cependant complexe (nous nous y attendions), et doit probablement passer par des algorithmes de discrimination un peu plus évolués qu'une simple série de comparaisons.  
 
Nous nous penchons donc sur les réseaux de neurones, qui semblent souvent employés dans les programmes d'OCR (Optical Character Recognition)...
by Olivier Guillion
 2 comments.

Dev News Wednesday, May 24th, 2006 at 04:55pm
Du glyphe à l'Unicode (2)
Le cerveau humain, à partir des informations visuelles qui lui sont transmises, distingue assez facilement (après un petit apprentissage), une clé de sol d'une clé de fa, un "M" d'un "T", etc.
L'idée de simuler le fonctionnement des neurones dans un programme coulait donc de source.  
 
Concrètement, un réseau de neurones "informatique" se présente en couches, comme un plat de lasagnes:
 
- Une série de neurones dits "d'entrée", chacun d'entre eux recevant une valeur quantifiable dépendant de l'objet à analyser. Ce peut être la luminosité d'un point, mais aussi un rapport largeur/hauteur du caractère,  l'épaisseur moyenne de ses traits, en fait tout paramètre pouvant avoir une utilité dans la discrimination.  
 
- Une série de neurones dits "de sortie", chaque neurone correspondant à une valeur possible à déterminer. Par exemple, si on veut que le réseau de neurones soit capable de trouver à quelle lettre (A-Z) correspond le caractère analysé, il faudra 26 neurones de sortie, un par lettre possible
 
- Entre l'entrée et la sortie, une ou plusieurs couches de neurones dits "cachés".
 
Chaque neurone de chaque couche est relié à chaque neurone de la couche suivante, par une liaison plus ou moins "forte". Au départ, la force de chacune des liaisons est choisie au hasard, et le réseau est incapable de reconnaître quoi que ce soit.
 
Ensuite, on présente au réseau des exemples de caractères à déterminer. Il essaie (et échoue). Il faut alors lui enseigner de quoi il s'agissait. Cet apprentissage affaiblit les liaisons qui ont conduit à l'erreur et renforce celles qui favorisent un résultat correct.
 
Si les valeurs alimentant la couche d'entrée sont bien choisies, si le réseau est correctement dimensionné, et si l'apprentissage est bien réglé, le réseau, petit à petit, apprend, et au bout de quelques milliers d'expérimentations et d'apprentissages, devient capable de distinguer quelque chose. Après 50 à 100000 apprentissages, il se débrouille pas mal.
 
Nous avons écrit un prototype d'un tel réseau en MyrScript, et l'avons fait travailler sur des exemples de caractères (comme les lettres de A à Z écrites en différentes tailles et différentes fontes). Une dizaine de milliers d'apprentissages plus tard, le réseau obtient un taux de fiabilité de 99% sur les exemples qui lui ont déjà été fournis, et plus de 90% sur des exemples issus d'autres fontes proches mais pas identiques.
 
Globalement, les résultats sont donc encourageants. Seul petit bémol : la masse de calculs devient assez conséquente. Pour un tout petit réseau de neurones de 3 couches de 26 neurones, il faut effectuer 1352 opérations pour obtenir un résultat. Si on passe le nombre  de neurones par couche à 120, il en faut 28800.
 
MyrScript commence à peiner un peu, et nous nous apercevons que le réglage du "taux d'apprentissage" s'avère crucial. Il détermine si le réseau apprend vite ou lentement de ses erreurs.
Trop vite, et une correction d'une de ses erreurs lui fait "oublier" ses apprentissages précédents, et trop lentement, il commet inlassablement la même faute, sans apprendre à se corriger.
 
Enfin, si on désire réduire le nombre de paramètres d'entrée pour simplifier le réseau, il faut choisir des critères quantifiables facilement extractibles du dessin du caractère. Quels qu'ils soient, leur choix sera dicté seulement par notre propre intuition, et risque de s'avérer moins performant qu'attendu.  
 
Cette méthode fonctionne donc, mais avant de passer à l'étape suivante de l'analyse, nous préférons explorer d'autres voies similaires, basées sur les statistiques de répartition des pixels dans chaque forme de caractère. Cela permettrait d'alléger les calculs et d'obtenir un apprentissage plus rapide qu'avec un réseau neuronal classique...
by Olivier Guillion
 7 comments.


Full view
Reduced view
Most recent first
Oldest first
All
Didier Guillion
Olivier Guillion
Sylvie Ricard
All
Dev News
Technical
Mood
Memories
Myriad Life
To be seen
30 previous days
Apr 2006
May 2006
Jun 2006
Jul 2006
Aug 2006
Sep 2006
Oct 2006
Nov 2006
Dec 2006
Jan 2007
Feb 2007
Mar 2007
Apr 2007
May 2007
Jun 2007
Jul 2007
Aug 2007
Sep 2007
Oct 2007
Nov 2007
Dec 2007
Jan 2008
Feb 2008
Mar 2008
Apr 2008
May 2008
Jun 2008
Jul 2008
Aug 2008
Sep 2008
Oct 2008
Nov 2008
Dec 2008
Jan 2009
Feb 2009
Mar 2009
Apr 2009
May 2009
Jun 2009
Jul 2009
Aug 2009
Sep 2009
Oct 2009
Nov 2009
Dec 2009
Jan 2010
Feb 2010
Mar 2010
Apr 2010
May 2010
Jun 2010
Jul 2010
Aug 2010
Sep 2010
Oct 2010
Nov 2010
Dec 2010
Jan 2011
Feb 2011
Mar 2011
Apr 2011
May 2011
Jun 2011
Jul 2011
Aug 2011
Sep 2011
Oct 2011
Nov 2011
Dec 2011
Jan 2012
Feb 2012
Mar 2012
Apr 2012
May 2012
Jun 2012
Jul 2012
Aug 2012
Sep 2012
Oct 2012
Nov 2012
Dec 2012
Jan 2013
Feb 2013
Mar 2013
Apr 2013
May 2013
Jun 2013
Jul 2013
Aug 2013
Sep 2013
Oct 2013
Nov 2013
Dec 2013
Jan 2014
Feb 2014
Mar 2014
Apr 2014
May 2014
Jun 2014
Jul 2014
Aug 2014
Sep 2014
Oct 2014
Nov 2014
Oct 31st, 2014 at 05:11pm 
Article from Olivier Guillion
PDFtoMusic 1.4.3
Oct 30th, 2014 at 04:57pm 
Article from Didier Guillion
PDFtoMusic 1.4.3
Oct 29th, 2014 at 05:03pm 
Article from Olivier Guillion
PDFtoMusic 1.4.3 RC1
Oct 28th, 2014 at 04:56pm 
Article from Didier Guillion
PDFtoMusic 1.4.3
Oct 27th, 2014 at 04:53pm 
Article from Olivier Guillion
Harmony 9.6 et autres étape 732
Oct 24th, 2014 at 04:53pm 
Article from Didier Guillion
PDFtoMusic 1.4.3
Oct 23rd, 2014 at 05:00pm 
Article from Olivier Guillion
PDFtoMusic 1.4.3
Oct 22nd, 2014 at 04:53pm 
Article from Didier Guillion
PDFtoMusic 1.4.3
Oct 21st, 2014 at 05:02pm 
Article from Olivier Guillion
PDFtoMusic 1.4.3
Oct 20th, 2014 at 08:43pm 
Comment from Antoine Bautista
et puis aussi...

Top of page
Last update:  (c) Myriad 2013