HomeProductsDownloadOrderSupportSearch
  
 
 Myriad Blog 1.3.0 Saturday, Oct 12th, 2024 at 04:56am 

Memories Wednesday, May 31st, 2006 at 04:36pm
Véga, l'Etoile à suivre.

1984. Entièrement dédié au Commodore 64, Véga sera notre premier jeu vidéo publié. C'est un jeu de "scrolling" (défilement) de la catégorie "Shoot them up" (Dégomme tout ce qui bouge). Un petit vaisseau se déplace sur le sol d'une planète éloignée, le joueur peut choisir son mode de propulsion, roues, ressorts, pattes d'araignées... Des myriades d'aliens vindicatifs attaquent bien entendu le vaisseau... Vous pouvez voir des captures d'écran ici.
Nous avions été très fortement impressionnés par le jeu "Attack of the mutant camels" de "Llamasoft", du grand gourou Jeff Minter, Yak pour les intimes...
Comme d'hab' on écrit un assembleur/désassembleur en Basic, puis on s'en sert pour le réécrire en assembleur, ainsi que tous les outils associés : dessin des différents niveaux, éditeur graphique, enfin, on écrit le programme sur papier et on le saisit.
Vers la fin du développement, nous n'avions toujours pas de musique pour le sonoriser. Un membre du club informatique, Marc Tarabbia, utilisa la première version de "K-Muse" pour transcrire la Toccata et Fugue de J.S. Bach. Aussitôt adopté, ce morceau sera la musique de Véga.
Nous envoyons une version de notre création à différents éditeurs de jeux du moment. Loriciels y répond favorablement, mais nous demande une version sur disquette. Nous achetons donc un lecteur de disquette 5 "1/4 (le "1541"), et créons une protection anti-copie. Au passage le 1541 était un vrai ordinateur autonome avec ROM/RAM et processeur 6502... Des fadas avaient même écrit un programme, qui, lancé sur le lecteur de disquette, faisait jouer God Save The Queen par des vibrations de la tête de lecture... Et ça continuait à jouer même quand on éteignait l'ordinateur.
 
Véga sort dans les bacs. Il est même vendu à la FNAC. Pour nous, cela fait tout drôle...
Sur un logiciel vendu 120FF en magasin, nous touchons 10FF. Le succès de Véga sera modeste mais le chèque reçu permettra à Olivier de s'acheter son premier synthé, un Casio CZ 101, et moi un poste de radio stéréo.
Véga sera surtout pour nous la révélation que notre travail de programmation était plus qu'un hobby ou une simple passion, mais qu'il pouvait peut être aussi devenir un métier...
by Didier Guillion

Dev News Tuesday, May 30th, 2006 at 04:50pm
Projet PDFToMusic, étape 4.
Nous sommes toujours dans l'étape qui consiste à analyser les polices de caractères présentes dans un fichier PDF.
Comme le format "Adobe Type 1C", le  format "Adobe Type 1" utilise un interpréteur PostScript pour dessiner les formes de caractères. La différence entre les deux formats est que le "Adobe Type 1C" est compacté, le "Adobe Type 1", est au format texte, non compacté. Par contre, le format "Adobe Type 1" est encrypté (certaines polices peuvent être protégées). Heureusement, l'algorithme d'encryptage/décryptage est public. Après quelques tatonnements et fausses pistes, le format "Adobe Type 1" est décodé. Nous écrivons alors un interpréteur PostScript rudimentaire pour tracer les caractères. Le résultat semble correct et utilisable.  
Maintenant, il va falloir analyser un autre type de police : le type 3, c'est un format où les caractères sont dessinés avec des commandes PDF. L'intention générale est d'uniformiser tout ceci et de convertir "Type 1", "Type 1C", "Type 3" en un format de description commun et homogène qui permettra un tracé plus uniformisé.  
Parallèlement à ceci, Olivier a essayé d'autres voies que le réseau neuronal pour la reconnaissance et obtient des résultats prometteurs...
by Didier Guillion

Memories Monday, May 29th, 2006 at 04:51pm
Le Commodore 64

En 1984, nous faisons l'acquisition d'un Commodore 64, le grand frère du Vic 20. C'est une machine qui nous marquera profondément. Seul l' Amiga 500, quelques années plus tard, nous fera le même choc. La mémoire du CBM 64 est confortable, le clavier est solide et ergonomique, mais surtout les circuits vidéo et sonore sont futuristes. Comme le processeur de ces machines est encore lent (6510 à 1.023 Mhz), les concepteurs ont décidés de "doper" les circuits annexes. Par exemple est proposé une notion révolutionnaire, récemment créée par Atari, les Sprites. Ce sont des graphismes indépendants, de 24 pixels par 21 pixels, que l'on peut afficher où l'on veut sur l'écran, en plusieurs plans. C'est le circuit vidéo qui gère les transparence, opacité et... collisions ! C'est proprement fabuleux ! Et offre des possibilités inimaginables pour les jeux vidéo. Deux "pokes" bien placés et le sprite change instantanément de position et de forme.
Le circuit sonore n'est pas à la traîne. Un vrai circuit polyphonique trois voix. Nous écrivons notre premier programme de composition musicale K-Muse. La saisie de la musique se fait sous forme d'un texte décrivant les hauteurs de notes. C'est d'ailleurs très proche de ce qui sera plus tard le format musical ABC.
Cet éditeur évoluera au cours des années. Jamais publié mais jamais oublié, il sera utilisé par Gilles Soulet notre compositeur attitré pour sonoriser les jeux qui suivront.  
Emballés par cette machine stupéfiante, nous nous lançons dans notre premier jeu vidéo "sérieux": Véga.
by Didier Guillion
 3 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.

Dev News Tuesday, May 23rd, 2006 at 04:58pm
Projet PDFToMusic, étape 3.
Nous sommes dans l'étape qui consiste à analyser les polices de caractères présentes dans un fichier PDF.
Le format de police "Adobe Type 1C" (C pour compacté) est public. A partir de cette documentation, un extracteur et interpréteur de commande graphique a été écrit pour pouvoir dessiner grossièrement les caractères. En effet, nous avons progressé dans la reflexion sur l'association "numéro de caractère" vers "signification du caractère". Une solution serait de procéder en deux étapes :
1- Rechercher des données similaires dans une base de données, pour savoir si le caractère à déjà été rencontré.
2- Si le caractère est nouveau, tracé du caractère et reconnaissance automatique de celui-ci. S'il est reconnu, alors nous alimenterons la base de donnée utilisée en étape 1.
 
La reconnaissance de caractère passera peut-être par des réseaux neuronaux. Un réseau neuronal a été écrit (en MyrScript, c'est un excellent langage pour faire rapidement des maquettes) et donne des résultats intéressants...
 
Entretemps un nouveau type de police est rencontré, le format "Adobe Type 1". La prochaine étape sera l'analyse de ce format.
by Didier Guillion
 2 comments.

Memories Monday, May 22nd, 2006 at 04:54pm
Le Club
1983. Alors que l'Internet n'était qu'une vision futuriste, que télématique rimait avec Minitel, les échanges entre passionnés d'informatique passaient par les revues spécialisées, ou mieux encore par les clubs d'informatique. Il y avait de nombreux clubs sur Toulouse, ce qui les différenciait, c'était ce que l'on venait y échanger...
Un samedi, dans un club, le père d'un des membres vient le chercher. Ce monsieur a travaillé toute l'après-midi et n'a pas eu le temps de se changer. Il est gendarme... Quand il entre dans la salle du club, on entend crier "Les flics !" et tout le monde s'enfuit en courant par la porte de derrière, laissant sur place les piles de disquettes encore chaudes et les machines à copier.
 
Pas de "copie party" dans notre club. C'était Basic ou Assembleur selon la salle. Et pourtant il y avait du monde. Certains après-midi plus d'une trentaine de personnes de tous âges.
Le club était hébergé par une école élémentaire, l'école Pierre et Marie Curie, qui, sur nos conseils, avait acheté un ensemble de 4 ou 5 Vic-20. De notre coté nous leur avions développé un genre de petit Logo, assez proche d'un Basic en Français mais purement graphique : le Logic 1.
Le club était donc bicéphale, en semaine, les enfants de l'école, le samedi après-midi, tout public. Les ordinateurs n'avaient guère l'occasion de refroidir...
Les élèves de 8 à 11 ans pouvaient ainsi s'initier à la programmation. Pour situer, tout ceci se passait bien avant le plan "Informatique pour Tous" qui allait s'imposer quelques années plus tard et interdire bien entendu ce genre d'initiatives individuelles au nom de l'uniformisation et de la standardisation.  
Et du même mouvement, dégoûter définitivement plusieurs générations d'élèves et d'enseignants de l'informatique.
Le Logic 1 devint rapidement Logic 2, avec une souris graphique "haute résolution" et de nouvelles fonctionnalités comme les sons et les sprites.
Logic 1 et 2 seront proposés à des éditeurs pour publication, et l'un d'eux, No Man's Land,  les prit dans son catalogue, après les avoir renommés "Logo-Logic 1" et "Logo-Logic 2" pour être sûr que tout le monde comprenne.
Le club a duré jusqu'en 1988 pour la partie tout public. Nous avons à cette époque décidé de créer Myriad ce qui nous a pris tout notre temps. Par contre, les enfants ont continué à s'initier à l'informatique bien plus longtemps.  
Je ne sais pas ce que sont devenus les membres du Club. Ont-ils persévéré dans l'informatique ? Elèvent-ils des chèvres au Larzac ?  
Si vous vous reconnaissez, si vous vous rappellez de ce temps où l'on cherchait, même à 10 ans, à maîtriser la machine et pas simplement à l'utiliser, envoyez-moi un petit mot...
by Didier 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 Friday, May 19th, 2006 at 05:08pm
Projet PDFToMusic, étape 2.
Nous sommes dans l'étape qui consiste à analyser les polices de caractères présentes dans un fichier PDF.
Cette étape de l'étude vise à extraire les données graphiques d'une police au format TrueType. Heureusement, la documentation est disponible. En première analyse, le format a l'air très complet et complexe. Mais avons-nous besoin de toutes ces informations ? Nous nous intéressons en premier lieu à la manière dont les glyphes (rendu graphique d'un caractère d'une police) sont encodés. Après quelques tatonnements, nous arrivons à extraire les données des glyphes et à tracer les caractères pour vérification. Cette phase est donc validée, même si nous laissons plusieurs problèmes dans l'ombre : rencontrerons-nous des polices non TrueType ? Des polices qui encoderaient les formes en passant par le bytecode TrueType ?
Maintenant que nous avons les données qui définissent la forme des caractères, il faut associer le caractère mémorisé dans le document PDF au numéro de glyphe. En effet le format PDF ne stocke pas toute la police mais uniquement les caractères présents dans le document. Ceci passe par les "Cmaps" du fichier TrueType.  
Quelques recherches sur l'Internet nous font découvrir un site présentant des centaines de partitions au format PDF. Il apparaît qu'une bonne proportion de ces fichiers utilisent une police de type "Adobe Type1C". La prochaine étape sera l'analyse de ce format.
by Didier Guillion

Mood Thursday, May 18th, 2006 at 04:52pm
Galère et Galerie
En matière de développement, il faut faire des choix au départ. Choix que l'on devra assumer parfois pendant plusieurs années. En général, que ce soit lors de la sélection d'une technologie ou d'un logiciel, nous nous posons les questions suivantes : "Si nous faisons ce choix, serons-nous bloqués, ou au contraire pourrons nous migrer vers des solutions compatibles ?", "Cette technologie existe-t-elle sur plusieurs plateformes ?". On peut dire, puisque nous maintenons certains logiciels "en vie" depuis plus de vingt ans, que nous avons eu la chance de ne pas trop nous tromper.  
Pourtant un faux pas existe, c'est Galerie. Au tout début, heureux nouveau possesseur d'un appareil photo numérique, je cherchais un moyen simple de générer des galeries de photos pour la famille. Une recherche approfondie m'a vite fait découvrir les limitations en ce domaine sur Macintosh. Alors je me suis dit, pourquoi ne pas bricoler quelque chose moi-même. J'avais un Mac, XCode que j'avais "tatouillé" un peu, quelques notions d'AppleScript, et je me suis lancé.
Petit à petit, le logiciel à évolué, il a intégré du C, de l'objective-C, du JavaScript, des transfert FTP, des accés QuickTime. Des passionnés m'ont rejoint, m'apportant une rigueur plus que bienvenue (surtout au niveau du code HTML), des modèles plus que sympas, des conseils, des suggestions. Et rapidement, le petit script à usage personnel est devenu une vraie application, s'enrichissant sans cesse.
Et encore plus rapidement, je me suis heurté à de sévères limitations. Un exemple.
Personne, à ma connaissance, ne peut écrire plusieurs milliers de lignes de code sans erreur. Pour localiser les erreurs et les corriger il existe depuis les années 1980 ce que l'on appelle un "débogueur".  Pour les non initiés, c'est la possibilité de voir pas à pas ce que fait un programme. Apple a maintenu pendant plus de trois ans sur son site les pages indiquant que l'on pouvait déboguer des applications AppleScript Studio. Mais personne ne pouvait le faire fonctionner. Finalement, Apple a réagi, et... a ajouté dans ses documentations que le débogueur AppleScript ne fonctionnait pas ! Point. C'est tout. Cela fait quatre ans. Pourtant c'est un concept Apple, spécifique à Apple, développé par Apple. Et depuis plus rien.
Devant tant d'immobilisme on pourrait se dire, "bon, on change de plateforme". Ah, mais non, ce n'est pas possible. Objective-C ne fonctionne que sur Macintosh, AppleScript ne fonctionne que sur Macintosh, le format des fichiers "ressource" est privé, jamais publié. Impossible de migrer vers d'autres plateformes.
Alors ami développeur, fais gaffe, ne commets pas la même erreur. Réfléchis à deux fois avant de te lancer...
by Didier Guillion

Dev News Wednesday, May 17th, 2006 at 05:05pm
Projet PDFToMusic, étape 1.
L'étude du PDF a débuté (voir le billet "On échange ?"), une première ébauche du parseur (analyseur ou butineur qui balaye un fichier pour en extraire les informations) a été écrite et l'on commence à extraire les différents éléments des fichiers PDF. Il apparaît que, du point de vue de l'utilisation que nous voulons en faire, trois catégories de documents se dégagent.  
La catégorie 0 (zéro): Ce sont les PDF n'incluant qu'une seule image de la partition par page du document. Ils ont vraisemblablement été générées directement depuis un scanner. La seule chose que l'on pourrait faire de ces documents serait d'exporter les images de manière séparée et de les faire traiter par OMeR.
La catégorie 1 : Ce sont les PDF, incluant des objets graphiques (lignes, rectangles, etc), et les objets musicaux (tête de note, nuance, etc) dessinés à partir d'une police de caractère. Ce sont des fichiers issus de l'exportation directe depuis un logiciel de musique, comme ce que l'on obtient depuis Harmony Assistant par exemple. L'interprétation des objets semble possible. Le problème est que la police incluse dans le document PDF est "remappé" (seuls les caractères utilisés dans le document sont présents) et ne semble pas utilisable directement.
La catégorie 2 : Ce sont les PDF n'incluant que des objets graphiques : les objets musicaux sont dessinés avec des primitives graphiques simples et non avec des polices. Je n'ai aucune idée de la façon dont ces fichiers ont été générés. Il va falloir isoler ces objets et construire un système expert de reconnaissance de forme ? Probablement.
 
La catégorie 1 semble la plus répandue. La catégorie 2 vient ensuite nettement moins souvent. La catégorie 0 est très rare à ma connaissance. La pierre d'achoppement de la catégorie 1 va être l'extraction des données brutes des fichiers de polices inclus dans le document et leur analyse. Apparemment, la plupart de ces fichiers sont des polices au format TrueType qui est un format public. Bon point. Cela va être la prochaine étape de l'analyse : serons-nous capables d'extraire ces données et de reconnaître la forme que ces données dessinent ?
by Didier Guillion
 3 comments.

Myriad Life Tuesday, May 16th, 2006 at 05:33pm
Allo la Lune ? 3/3
Grâce a MyrScript, le langage intégré à Harmony Assistant et basé sur le Lua (voir les chapitres précédents), le créateur de script peut agir sur n'importe lequel des objets du logiciel, et sur cet objet, accéder à tous ses paramètres.
 
MyrScript propose également des objets qui ne sont pas des objets musicaux, et en particulier la possibilité de créer des boîtes de dialogues pour interfacer les scripts. Ceci passe par l'Interface Composer qui permet de définir des boîtes de dialogue. Chaque objet de l'interface ainsi défini contient ses propres méthodes de traitement.
Avant de lancer le script, toutes les méthodes sont précompilées, et lorsque l'une d'entre elle est invoquée, le code associé est exécuté. Ceci n'est possible que grâce à l'extrème rapidité de Lua.
 
Enfin, afin de faciliter le développement, nous avons intégré un débogueur pas à pas avec affichage des variables locales, globales et de leurs membres éventuels. Un mode spécial de fonctionnement du Lua, permet d'invoquer une routine C à chaque ligne du programme. Quand on vous dit que c'est bien pensé !
 
MyrScript est fourni avec un manuel conséquent. A ce sujet nous avons utilisé une astuce amusante. Plutôt que de le mettre à jour manuellement, ce sont les commentaires de nos propres sources C qui sont extraits et constituent les différents chapitres.
 
De notre coté, après presque quatre ans d'utilisation, nous ne pouvons que nous féliciter d'avoir fait le choix de Lua. Les rares "plantages" survenus étaient tous de notre fait, et c'est vraiment rassurant pour un programmeur de travailler sur des bases saines et fiables. Un grand nombre de fonctionnalités "pointues" sont ainsi développées à la demande et fournies à l'utilisateur très rapidement, sans avoir à attendre une mise à jour du programme.
 
La facilité d'utilisation de ce langage nous permet même de nous en servir en interne comme plate-forme d'expérimentation sur les traitements de sons numériques, de données statistiques, ou pour réaliser des petits programmes "jetables" pour un usage ponctuel.
by Didier Guillion

Memories Monday, May 15th, 2006 at 05:02pm
L'époque épique du pique et poque.

Ca y est nous avons notre premier ordinateur ! Bien à nous ! C'est un Commodore Vic-20.  
Les débuts se font en Basic, mais avec une mémoire faramineuse de 3500 octets, on ne va pas très loin et il faut ruser et encore ruser. Très vite nous récupérons quelques adresses clef qui moyennant un "Poke" (écriture) ou un "Peek" (lecture) permettent de faire une quantité de choses, changer les couleurs du bord de l'écran, la couleur du fond, changer de mode vidéo, accéder au circuit sonore (un vrai circuit trois voix tout de même) etc.
Il était possible de faire des graphismes, comme tracer une courbe à l'écran, en reprogrammant l'affichage graphique des caractères. Il arrivait souvent d'avoir un "Out of memory" au milieu du tracé d'une courbe un peu complexe.  
Nous avons écrit quelques petits programmes, comme un simulateur de système solaire, où les planètes s'attiraient en fonction de leur masse.  
Après l'acquisition d'un lecteur de cassette qui servait de mémoire de masse, nous accédons à quelques démos (Ah! La chanson des Beatles jouée par l' ordinateur !). Parmi ces programmes, la révélation, "Invaders fall", des petits martiens qui dévalent l'écran  avec en bas un vaisseau qui tire des missiles pour les anéantir. Et cela va de plus en plus vite ! Plus vite que ne peut le faire le Basic. Alors nous décortiquons le programme et, fantastique, c'est écrit en assembleur !
Nous passons plusieurs jours/nuit à désassembler à la main le code, le retranscrire sur une grande feuille de papier et à le commenter. C'est décidé, nous allons nous mettre à l'assembleur. Pour ceux qui n'ont pas connu cette époque glorieuse, je rappelle que les ordinateurs étaient livrés, avec comme seul logiciel, un Basic en ROM. Donc, nous commençons par écrire un assembleur/désassembleur en Basic. Puis, lorsqu'il est fonctionnel, nous nous en servons pour écrire... un assembleur/désassembleur en assembleur.
Ensuite, pour écrire un programme, il faut faire cohabiter l'assembleur/désassembleur, le programme lui-même, plus ses graphismes dans 3500 octets. Le programme est d'abord écrit sur une feuille de papier, nous le testons "virtuellement" à la main, puis nous le saisissons.  
Dès son écriture, les adresses des instructions sont figées (il n'y pas de labels), il faut donc prévoir des "points de relâchement" entre chaque sous-routine pour pouvoir éventuellement l'étendre. Et si le point de relâchement s'avère trop court, on reprend la routine suivante, on la réécrit et on la met ailleurs.
Quelle rude école, mais ô combien profitable.
Les premiers programmes en Assembleur ont commencé à fuser. Un clone de PacMan, appelé BugMan (nous avions décidés de nous appeler la "Business United Games"), un jeu de course de chevaux, un Asteroid, et plein d'autres encore.
Comme nous continuions à fréquenter les magasins d'informatique, pour tester des machines comme l'Oric, l'Archimède, le Lynx, nous avons rencontré d'autres passionnés de tout âge qui voulaient aussi s'initier, car c'était frustrant, un ordinateur, quand on ne connaissait pas la programmation. Nous avons donc fondé un Club d'Informatique.
by Didier Guillion
 3 comments.

Myriad Life Saturday, May 13th, 2006 at 07:43pm
Et Lua engendra MyrScript 2/3
En 2002, nous avons décidé de tenter de réanimer une idée que nous avions mis "au frigo" depuis pas mal de temps, intégrer un langage de script à Harmony Assistant. Il y a quelques années, nous avions résolu un problème similaire en offrant la possibilité d'enregistrer tous les événements clavier, souris, menu pour pouvoir les "rejouer" par la suite. Le système avait un gros avantage, n'importe qui pouvait l'utiliser sans apprentissage, on lançait "enregistrement" et le programme s'occupait de tout.  Mais aussi un inconvénient de taille, comment choisir un symbole donné sur une partition par exemple ? Non, il nous fallait quelque chose de plus puissant. Nous avons commencé a prospecter l'existant, Java était plaisant car très proche de la structuration du C mais difficile à intégrer à notre propre interfaçage. Python, plus souple, nécessitait l'installation de librairies lourdes pour son exécution.

Puis, par hasard nous avons rencontré Lua. Lua veut dire "Lune" en Portugais.
Développé par une équipe d' Universitaires Brésiliens, Lua est écrit en C, open source et librement utilisable. Nous avions déjà eu l'occasion d'expérimenter d'autres projets venant d'universités, et nous partions sur a priori très défavorable. La suite devait nous montrer que nous nous trompions lourdement dans le cas du Lua...
 
Non seulement Lua est écrit en C, mais en C plus que standard. Créer un projet sur Windows ou Mac OS a été rapide et en quelques heures les librairies Lua étaient compilées sans erreur ni warning.
Les documentations sont extrèmement claires, c'est l'avantage des manuels écrits par des non anglophones, aucun effet litteraire ou de style, rien que de l'information brute et un vocabulaire simple.
La communauté des utilisateurs de Lua est très réduite mais active. Une ou deux de nos questions sur les droits d'utilisation ont reçu une réponse rapide des auteurs mêmes de Lua. Par la suite, Lua s'est révélé tellement solide, rapide et efficace, que nous n'avons plus eu de question à poser.
La seule critique que nous formulons après plusieurs années d'utilisation est que l'évolution du langage en v5 est passée par des changements de syntaxe trop importants, qui auraient nécessité une refonte des scripts existants. Nous n'avons jamais pu utiliser les dernières versions des librairies : impossible de demander à nos utilisateurs de reprendre leurs sources. Pourquoi les auteurs de Lua n'ont-ils pas simplement ajouté de nouveaux concepts au langage sans modifier l'existant ? Dommage, très dommage.
Nous disposions donc d'un "moteur" efficace et rapide, il nous restait plus qu'a retrousser nos manches et interfacer nos objets musicaux à Lua.
by Didier Guillion

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

Myriad Life Thursday, May 11th, 2006 at 06:08pm
Le temps (1/3)
Chez Myriad, nous divisons notre temps de développement de manière à peu près égale en maintenance des produits, évolution des produits existants et recherche de nouveaux concepts ou logiciels. Evolution et recherche alternent dans l'année, la maintenance étant constante et constituée principalement d'aide aux utilisateurs. Un projet dure entre 4 et 6 mois, passée cette limite, nous reconsidérons avec attention sa faisabilité. Les projets de recherche pure sont certainement les plus passionnants. Souvent aussi les plus frustrants car une fois sur deux cela n'aboutit à rien. Dans ce cas nous archivons tout de même l'idée pour plus tard.  La décision de ne pas passer du stade d'étude, qui en général a pris énormément de temps de part les recherches bibliographiques, analyses et constructions de maquettes que cela demande, en réalisation d'un produit véritable est difficile à prendre.
 
Mais si nous n'avons ni les compétences, ni le temps ou que le concept n'intéresserait qu'un petit nombre de personnes, pas de pitié, on archive et on passe à autre chose. Certains projets sont dans nos cartons depuis plusieurs années, notamment un simulateur de machine volante qui nous tenait beaucoup à coeur.  
Un critère d'abandon qui est déjà intervenu est ce que l'on peut appeller la "question obligée". Si l'utilisation du logiciel ne peut se faire que dans un cadre précis et dans des conditions précises, même si le logiciel détecte ces conditions et previent l'utilisateur, même si cela est expliqué dans le manuel, nous allons devoir répondre des milliers de fois à la même question. Et ça, c'est vraiment usant.
 
Un exemple type de projet resté dormant puis réanimé et maintenant très actif est MyrScript.
by Didier Guillion

Mood Wednesday, May 10th, 2006 at 04:17pm
S'il te plait, dessine moi une icône.
Pour nos programmes, nous sommes des demandeurs fréquents d'icônes et autres graphismes d'interface. A ce jour, nous n'avons travaillé qu'avec des graphistes américains. Quand nous avons constaté ce fait, nous avons cherché une explication. Ce serait tout de même plus aisé pour nous d'exprimer nos besoins dans notre langue maternelle. Je me suis un peu balladé sur des forums où des graphistes Francophones s'expriment et j'ai fait plusieurs demandes. Aucune n'a pu aboutir à un contact sérieux. Impossible d'obtenir des exemples de réalisation, un aperçu des tarifs, ou même un mode de réglement compatible avec la comptabilité d'une société. Certains graphistes demandaient même d'être payé au pourcentage ! Je me dis que, peut être, les graphistes Français considèrent la réalisation de l'interface d'un logiciel comme un travail trop trivial ?  Je reste dans l'incompréhension.
 
A titre d'exemple, voici le dernier contact que nous avons eu avec un graphiste d'outre-atlantique.
je recois un email où il me dit que nous devrions changer d'écran de démarrage et d'icone d'application car ceux que nous utilisons semblent dater un peu. D'après ce qu'il m'écrit, il a pris le temps de survoler nos logiciels, il ne parle pas dans le vide, bon point pour lui. Je lui fais donc la demande d'exemple de graphismes et de tarif. Il m'envoie un lien sur un site simple et bien fait, présentant ses réalisations. Je lui dis que tel style de graphisme, vu sur son site me plait bien. Il me fait une proposition commerciale. Je dis ok. Quinze jours plus tard, je recois les premiers rushs, un ou deux ajustements mineurs et une semaine après l'affaire était réglée.
 
Alors, amis graphistes, notre porte vous est toujours ouverte, n'hésitez pas à frapper avec votre carton à dessins sous le bras !
by Didier Guillion
 1 comment.

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.

Memories Monday, May 8th, 2006 at 01:19pm
Vic 20 vs TI99/4A
1981. Les premiers ordinateurs véritablement familiaux arrivent. Dans notre petite ville de Toulouse les magasins commencent à apparaître. Au début, ce sont surtout des librairies qui réservent une pièce de démonstration aux ordinateurs, puis des boutiques dédiées à l'informatique fleurissent, il y en aura ainsi plus d'une vingtaine. Certaines avec une durée de vie inférieure à l'année... Comme d'habitude nous nous "incrustons" pour tester les machines, achetant souvent le livre décrivant la '"bête" pour mieux l'explorer chez nous. L'accueil est très variable. A la librairie C***, place du Capitole, nous nous faisons expulser comme des malpropres : "On ne touche pas !". Chez S***, rue Kennedy, la porte nous est grande ouverte, nous y établissons rapidement nos quartiers. La vendeuse, Valérie, comprenant qu'il vaut mieux présenter des machines vivantes aux clients, plutôt que de bêtes écrans avec un "Ready" suivi d'un curseur clignotant, nous laisse occuper le "ShowRoom" à notre guise. Elle nous prête même des chaises pour que l'on puisse travailler assis, le luxe.
Au hasard de nos périgrinations nous repérons rapidement, une machine très sympa, mais dont les caractéristiques feraient sourire aujourd'hui, même pour un téléphone portable : 3,5 Ko de Ram, 6502 (8bits) à 1Mhz, affichage textuel de 22 colonnes. Le Vic-20 de Commodore Business Machine. CBM avait auparavant sorti le Pet mais cela n'avait pas fait beaucoup de bruit.
Le 6502 c'était le processeur de l'Apple II, l'arlésienne de la micro, il y avait donc une abondante documentation sur ce processeur.

Mais voici que débarque une nouvelle machine, qui semble encore mieux : le TI99/4A, de Texas Instrument. Les caractéristiques  du TI99 sont plus qu'alléchantes: 16 Ko de Ram (fabuleux) et surtout un processeur 16 bits à 3Mhz ! Nous nous précipitons pour le tester, et là, déception, il se traîne lamentablement. Comme la FNAC propose une démonstration du TI99 par un commercial de Texas Instrument, j'enfourche mon vélo et je vais y participer. Je lui pose donc la question "Comment avec un processeur 16 bits à 3Mhz, le TI99 peut il être plus lent qu'un Vic 20, 8 bits à 1Mhz ?". Sourire suffisant du commercial :" Le TI99 est une machine destinée à un usage familial, nous l'avons voulu plus lent afin que les enfants aient tout le temps de lire ce qui s'affiche à l'écran." Et ce genre d'argument était accepté sans problème par le public, c'est dire à quel point l'informatique familiale débutait.
 
Notre premier ordinateur sera donc un Vic-20, acquis pour la somme de 2 200FF,  sans support de stockage les premiers mois. Nous le branchons sur la télé familiale. Et c'est le début de longues soirées en compagnie de cette machine. D'abord le basic, puis le langage qui permet de tutoyer la machine : l'assembleur.
by Didier Guillion
 2 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

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 Thursday, May 4th, 2006 at 02:35pm
On échange ?
Les échanges de document musicaux ont toujours été une de nos préoccupations. Chaque logiciel de musique utilise son propre format de fichier, et il est difficile de partager des documents quand on travaille sur des logiciels différents.  
En général, le format le plus reconnu est le MIDI. Mais, c'est un format maintenant ancien, que l'on peut qualifier de spartiate et plus destiné aux synthétiseurs qu'aux ordinateurs. Par exemple, le format MIDI ne comporte aucune information de mise en page et l'on se retrouve vite limité car un export puis un import ne redonne pas le même aspect de la partition.
 
Grâce à MyrScript, le langage intégré à Harmony Assistant, il est possible d'importer des documents musicaux provenant de toutes sortes de logiciels : Finale, Noteworthy, Encore, GuitarPro, Tabledit, etc. Depuis deux ans, une bonne partie de notre temps a été passée à écrire des scripts d'importation, mais il y a tellement de logiciels différents que je ne pense pas que nous en verrons un jour la fin. Il faut en effet, pour chaque logiciel, concevoir un script spécifique, parfois même avec des variantes car les formats ont évolués dans le temps.
 
Nous réfléchissons depuis quelque temps à une autre approche du problème. L'idéal serait d'avoir un format de fichier qui soit commun à tous les logiciels. Il y a bien l'initiative très intéressante du MusicXML mais cela suppose qu'un exporteur MusicXML existe pour le logiciel. Or, très souvent, les nouveaux utilisateurs de Melody/Harmony utilisaient un programme dont le développement a été arrété, et voudraient bien récupérer les partitions créées avec celui-ci. Ils se retrouvent bloqués.
 
C'est alors que nous est venue une idée. Un format d'échange existe : c'est le PDF. Que ce soit sur Mac OS X, où l'exportateur en PDF est intégré au système, sur Mac OS 9 où des pseudo pilotes d'impression existent, ou sur Windows avec des programmes gratuits comme PDFCreator, il est aisé de créer un document PDF à partir de n'importe quel logiciel. De plus on trouve une grande quantité de partitions en PDF sur l'Internet notamment sur Choral Public Domain Library.
 
Si l'on pouvait lire ces fichiers PDF avec Harmony/Melody nous disposerions alors d'un format d'importation universel. La description du format a été publiée par son créateur, Adobe. Une pré-étude a été lancée cette semaine pour voir si ce format est lisible et si l'on peut faire quelque chose de ces données.
Dès que la nouvelle version d'Harmony et de Melody sera publiée (normalement Mardi prochain 9 Mai) nous approfondirons la question.
by Didier Guillion
 1 comment.

Technical Wednesday, May 3rd, 2006 at 04:23pm
Le requin qui vous veut du bien
Souvent critiqué à juste titre par les développeurs de gros projets, XCode (ensemble d'outils de développement fournis par Apple) renferme pourtant un petit bijou : Shark. Shark vient en remplacement de l'ancien outil "Sampler". Après avoir installé les developer tools, on le trouve dans "Developer>Applications>Performance tools".
 (A noter que pour utiliser Shark, il faut cocher la case des "CHUD tools" lors de l'installation des outils de développement.)
Shark permet d'analyser les performances d'une application en train de tourner. Comme il travaille par ponction régulière, il ne demande aucune compilation spéciale de l'application à analyser, si ce n'est la présence des labels. La précision de Shark est étonnante, il fournit même un diagnostic de l'assembleur obtenu, avec suggestion des modifications à appliquer au fichier source pour l'optimiser.
Son ergonomie est tout à fait satisfaisante, il est fiable et précis. Je dis bravo !
by Didier Guillion

Myriad Life Tuesday, May 2nd, 2006 at 04:36pm
Le téléphone sonne toujours deux fois
Ceux qui me connaissent savent mon aversion profonde pour ce bidule du siècle dernier, ce monstre noirâtre et stridulent qui vous réveille à trois heures du matin parce que certaines personnes sont fâchées avec les décalages horaires, j'ai nommé le téléphone. Pourtant, pourtant, ce jour là, le téléphone sonne. Je lève le nez de mon ordinateur, sachant que tout à l'heure je ne retrouverai pas le fil et la solution au problème que S*** M*** m'a soumi. Lol.  
A l'autre bout une dame.
- Je vous appelle d'Italie.
Bon, un point pour cette personne, elle fait l'effort de parler en Français. Et un Français parfait en plus.
- J'ai un problème de notation grégorienne. (Là, elle m'explique un problème compliqué de suppression de punctum dans un neume)
- Euh... Pourriez vous m'envoyer un email ?
- C'est difficile. Je suis Soeur M*** du couvent de L*** et seule la mère supérieure a accès à l'Internet.
- Euh... Un courrier postal peut être ?
- Ca va être difficile également. Il y a deux mètres de neige ici. Cela fait trois semaines que le facteur n'est pas passé. Il nous reste juste l'électricité et le téléphone. Nous sommes coupées du monde vous savez...
Bon, ok, d'accord, je l'ai aidée à résoudre son problème. Mais, vous aurez du mal à trouver meilleure explication que cette soeur Carmélite, bloquée dans son couvent en altitude...
by Didier Guillion
 1 comment.


Full view
Reduced view
Most recent first
Oldest first
All
Didier Guillion
Olivier Guillion
Sylvie Ricard
All
Technical
Dev News
Mood
Memories
To be seen
Myriad Life
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
Dec 2014
Jan 2015
Feb 2015
Mar 2015
Apr 2015
May 2015
Jun 2015
Jul 2015
Aug 2015
Sep 2015
Oct 2015
Nov 2015
Dec 2015
Jan 2016
Feb 2016
Mar 2016
Apr 2016
May 2016
Jun 2016
Jul 2016
Aug 2016
Sep 2016
Oct 2016
Nov 2016
Dec 2016
Jan 2017
Feb 2017
Mar 2017
Apr 2017
May 2017
Jun 2017
Jul 2017
Aug 2017
Sep 2017
Oct 2017
Nov 2017
Dec 2017
Jan 2018
Feb 2018
Mar 2018
Apr 2018
May 2018
Jun 2018
Jul 2018
Aug 2018
Sep 2018
Oct 2018
Nov 2018
Dec 2018
Jan 2019
Feb 2019
Mar 2019
Apr 2019
May 2019
Jun 2019
Jul 2019
Aug 2019
Sep 2019
Oct 2019
Nov 2019
Dec 2019
Jan 2020
Feb 2020
Mar 2020
Apr 2020
May 2020
Jun 2020
Jul 2020
Aug 2020
Sep 2020
Oct 2020
Nov 2020
Dec 2020
Jan 2021
Feb 2021
Mar 2021
Apr 2021
May 2021
Jun 2021
Jul 2021
Aug 2021
Sep 2021
Oct 2021
Nov 2021
Dec 2021
Jan 2022
Feb 2022
Mar 2022
Apr 2022
May 2022
Jun 2022
Jul 2022
Aug 2022
Sep 2022
Oct 2022
Nov 2022
Dec 2022
Jan 2023
Feb 2023
Mar 2023
Apr 2023
May 2023
Jun 2023
Jul 2023
Aug 2023
Sep 2023
Oct 2023
Nov 2023
Dec 2023
Jan 2024
Feb 2024
Mar 2024
Apr 2024
May 2024
Jun 2024
Jul 2024
Aug 2024
Sep 2024
Oct 2024
Oct 11th, 2024 at 06:31pm 
Comment from Oliveira
¡Por el buen camino!
Oct 11th, 2024 at 05:25pm 
Article from Olivier Guillion
Harmony Assistant 9.9.9  beta étape 27
Oct 11th, 2024 at 05:25pm 
Article from Olivier Guillion
Harmony Assistant 9.9.9  beta étape 27
Oct 10th, 2024 at 11:05pm 
Comment from Sylvain
très utile !
Oct 10th, 2024 at 07:39pm 
Comment from JP
Remplacement des caractères
Oct 10th, 2024 at 05:01pm 
Article from Didier Guillion
Harmony Assistant 9.9.9  beta étape 26
Oct 10th, 2024 at 05:01pm 
Article from Didier Guillion
Harmony Assistant 9.9.9  beta étape 26
Oct 9th, 2024 at 06:19pm 
Comment from Antoine Bautista
Ecriture des paroles....
Oct 9th, 2024 at 05:18pm 
Article from Olivier Guillion
Harmony Assistant 9.9.9  beta étape 25
Oct 8th, 2024 at 05:03pm 
Article from Didier Guillion
Harmony Assistant 9.9.9  beta étape 24

Top of page
Legal information Cookies Last update:  (c) Myriad