HomeProductsDownloadOrderSupportSearch
  
 
 Myriad Blog 1.3.0 Tuesday, Mar 19th, 2024 at 07:55am 

Dev News Friday, Jun 30th, 2006 at 05:13pm
Projet PDFToMusic, étape 18
Aujourd'hui, nous avons rencontré un nouveau type de document. Les différentes lignes (ligne de portée, barre de mesure) sont dessinées à l'aide d'images. Le problème a été partiellement résolu mais la conversion va nécessiter de nouveaux algorithmes de discrimination.
Les paroles sont maintenant correctement extraites et associées aux notes, même s'il y a plusieurs lignes de paroles. De plus en plus de fichiers se chargent presque sans erreur.
 
Olivier travaille sur l'importation MusicXML des coulés, liés et accroches.
 
Nous commençons à réfléchir à ce que pourrait donner l'interface. Nous la voudrions simplissime. Du genre, une fenêtre pour représenter le document avec en haut un nombre limité d'icônes. Nous pensons revenir au principe que nous avions utilisé pour la version 1.0 d'Harmony. Plutôt qu'une palette flottante, les icônes seraient directement affichées dans la fenêtre du document, c'est plus gourmand en place écran, mais c'est la mode... Ce que j'aime bien personnellement, en tant qu'utilisateur, c'est de pouvoir définir les icônes présente parmi une liste de fonctionnalités iconisées.  
A priori, il faudrait, pour la navigation, "Plus une page", "Moins une page",  "Augmenter/diminuer l''échelle". Peut-être "Aller à la page" avec une valeur numérique.
Pour le jeu : "Lancer", "Pause", "Changer le tempo" . Peut- être, la possibilité de jouer un métronome, mais ce n'est pas sûr.
Additionnellement, peut-être une icône pour exporter le document à moins que cela ne soit simplement une option de menu. Les formats d'exportation seraient MusicXML, peut-être MIDI et les pages sous forme de fichiers BMP.
by Didier Guillion
 3 comments.

Dev News Thursday, Jun 29th, 2006 at 05:10pm
Projet PDFToMusic, étape 17

Nous bataillons avec l'équipe du MusicXML pour savoir comment exporter la position graphique précise des objets afin d'avoir un rendu à l'écran identique dans les diverses applications. Ce n'est pas une mince affaire car c'est loin d'être normalisé. C'est assez frustrant de connaître au quart de pixel près la position d'un objet dans la mesure et ne pouvoir être sûr du résultat obtenu, ceci variant selon le logiciel. Nos préoccupations ont cependant été entendues, et la version en cours de développement du MusicXML 1.2 devrait, en théorie, clarifier la situation.
Le principal travail de la journée a été de discriminer parmi les textes affichés sur la page, ce qui est un accord, une parole, un texte libre, un nom de portée, etc. Pour cela nous avons travaillé à partir de l'exemple de Sylvain M***,"Dimna Juda" de l'étape 11. Un casse-tête très intéressant... Après moultes déboires cela commence a fonctionner. L'export MusicXML a été complété afin de gérer les accords extraits.
by Didier Guillion

Dev News Wednesday, Jun 28th, 2006 at 04:58pm
Projet PDFToMusic, étape 16

La première version de l'importeur MusicXML, écrite en C par Olivier, a été intégrée au projet. Elle est considérablement plus rapide que la version MyrScript ! Le projet PDFToMusic a été lié avec la librairie Harmony de jeu de musique et des premiers fichiers simples ont été convertis depuis le PDF et joués.
La question qui se pose est maintenant de faire un lien entre le PDF affiché et la position temporelle de jeu afin d'afficher la position courante par une barre verticale.
Ce sera l'objet d'une étude ultérieure.
Pour l'instant nous testons nos algorithmes de reconnaissance de caractère et d'export MusicXML sur des fichiers PDF d'origine différentes. Cela montre qu'il reste énormément de travail à faire...
by Didier Guillion

Dev News Tuesday, Jun 27th, 2006 at 04:52pm
Projet PDFToMusic, étape 15

L'extraction de données depuis un PDF donne une quantité d'informations terriblement précises sur les symboles et leur positionnement. Notre but est d'exporter un maximum de ces informations dans le fichier MusicXML résultat. Ceci a mis en exergue des lacunes importantes de l'import MusicXML d'Harmony Assistant. En fait, cet importeur est le premier d'une longue série d'importeurs qui se sont succédés : Encore, Finale, Tabledit, GuitarPro, etc. et en tant que pionnier il souffre de lourdeurs et de problèmes de conception assez pénalisants. Olivier va donc repartir de zéro et réécrire un importeur MusicXML, en C, qui sera la pierre d'achopement des échanges entre nos applications mais également entre nos applications et les applications extérieures.  
A terme, cet importeur sera vraisemblablement également disponible dans Melody Assistant et sera une composante du MMPlug-in qui pourra alors gérer les fichier MusicXML
by Didier Guillion

Dev News Monday, Jun 26th, 2006 at 05:18pm
Projet PDFToMusic, étape 14

Dans l'étape actuelle, nous travaillons sur la compréhension des symboles afin de recréer une partition valide. Les questions qui se posent sont très proches de celles que nous avons déjà rencontrées lors de la conception d'OMeR en 1999. L'approche est par contre totalement différente. Par exemple plutôt que d'adapter les durées de symboles à la métrique, nous allons faire le contraire. En reconnaissance de partition musicale, une simple erreur entre une barre d'accroche simple ou double par exemple (et c'est graphiquement très semblable) a de forte répercution sur la durée des notes et donc sur toute la structuration de la partition à partir de cette position. Les algorithmes utilisés devraient être beaucoup plus souples et limiter les éventuelles erreurs à la mesure.
by Didier Guillion

Mood Friday, Jun 23rd, 2006 at 05:14pm
Cracked by Pablo !

Je recois un e-mail d'un utilisateur Norvégien qui se plaint que son numéro de licence ne fonctionne pas. Je démarre donc la procédure habituelle : pas d'errreur de frappe ? dans le bon logiciel ? etc.
Non, il confirme et me communique les références de sa commande, carte VISA, numéro de transaction, tout est ok.
Je lui dis que je ne comprends pas. Il commence à s'énerver un peu et m'envoie le numéro de licence que nous lui avons communiqué :
"XMNAP-KRACK-BYYYY-PABLO-NOPPP-01"
 
Euh.... Je lui fais remarquer que ce numéro contient "KRACK BY PABLO" et que je me permets de douter que ce soit nous qui le lui ayons envoyé...
Confusion et excuses de sa part. Il a échangé des numéros de série par email et s'est trompé d'email...
Donc, si vous perdez votre numéro de licence, simplement, demandez-le nous, ne vous précipitez pas sur les sites de pirates pour en recupérer un autre.
by Didier Guillion
 1 comment.

Dev News Thursday, Jun 22nd, 2006 at 05:10pm
Projet PDFToMusic, étape 13

Une fois le document PDF analysé et affiché, nous voudrions que l'utilisateur puisse le jouer... Or, et c'est là le problème, il n'y a strictement aucune information sur l'instrument dans un document PDF. Souvent, le nom de la portée est présente, et quand on voit "Guitare" on doit être capable de savoir quoi faire... Mais ce n'est pas toujours le cas.
Olivier à donc démarré l'écriture d'un module qui, à partir des informations présentes dans un document, essaie de déterminer quel instrument associer à chaque portée.
Les critères sont, entre autre, la clef, la tonalité, la présence ou non d'accords, la tessiture, les groupes de portées définis...  
Nous prévoyons d'intégrer Virtual Singer dans PDFtoMusic, ce qui permettrait de chanter également les paroles.
 
by Didier Guillion
 1 comment.

Dev News Wednesday, Jun 21st, 2006 at 04:25pm
Projet PDFToMusic, étape 12

Il apparait maintenant de manière de plus en plus évidente que le MusicXML va être le format d'échange entre PDFToMusic et les autres programmes.
Il va donc nous falloir écrire un importeur Music XML en C afin de pouvoir charger les fichiers obtenus avec Melody Assistant.
Ceci implique qu'il serait donc possible d'intégrer cet importeur au Myriad Music Plug-In et donc d'utiliser le MMPlug-in pour afficher et jouer des fichiers Music XML sur le web.
Bien sur, les fichiers devront être compactés car le Music XML est très verbeux. La question a été posée à M. Good, qui gère le projet Music XML, de savoir si un standard de compactage a été défini. Ceci a apparemment mis en chantier la version 1.2 du Music XML qui devrait proposer cette fonctionnalité.
Pour exemple, un fichier Music XML de 100Ko est réduit à 4Ko une fois Zippé.
 
Note: C'est avec plaisir que nous recevons vos suggestions sur ce projet, mais envoyez-nous plutôt un email, cela facilitera les échanges...
by Didier Guillion
 3 comments.

Memories Tuesday, Jun 20th, 2006 at 05:15pm
Sapiens (3/3)
Sapiens fut proposé au Printemps 1986 à plusieurs éditeurs, les négociations furent âpres et passionnées, et c'est une fois de plus Loriciels qui fut choisi comme éditeur. Un éditeur Lyonnais bien connu, qui nous avait filouté entretemps sur un autre travail, n'était plus dans la course.
 
Dans la foulée de la version MO5 de Sapiens, une version pour CPC fut développée ainsi que différentes variantes pour TO7, MO6, TO8 (sur un prototype non carossé en provenance directe de chez Thomson), et pour TO9. Quand Loriciels nous demanda, fin 1986, une version pour Compatible PC de Sapiens (mode CGA) nous décidâmes de revoir notre mode de travail. N'existait-il pas un moyen de ne pas avoir à tout réécrire à chaque fois ? A l'époque c'était la grande guerre entre le Pascal et le C. Nous connaissions un peu le Pascal pour l'avoir pratiqué à la Fac, mais pas du tout le C. En tout cas, les "Pascaliens" honissaient le C, en particulier une revue "Pascallissime", particulièrement virulente. Cela nous a mis la puce à l'oreille (on ne médit que ce sur ce que l'on jalouse) et avons regardé ce langage un peu plus en détail. Le C portait le sobriquet d' "assembleur portable", alléchant...
Rien d'assembleur dans le C, mais un langage simple (simpliste même) mais surtout portable. Nous avons acheté un livre et nous nous y sommes mis. Notre premier programme en C a été l'adaptation de Sapiens pour PC.

Les mêmes sources furent utilisés mi-1987 pour sortir une version Atari ST de Sapiens, et 20 ans plus tard pour créer une version Macintosh à l'occasion de l'anniversaire de Sapiens.
 
C'est sur Atari ST que nous découvrons notre premier circuit sonore qui permette de jouer des sons numérisés. Nous créons ainsi, à notre connaissance, le premier jeu pour Atari à utiliser une musique de fond jouée avec des instruments numériques. Le son de flûte de pan avait été enregistré à partir d'une canne à pêche en roseau que nous avions sciée.
 
Nous gardons un très bon souvenir de l'Atari ST.
 
En 1987, Sapiens reçut le Tilt d'Or Canal Plus du meilleur jeu d'aventure.  
Le 5ème Axe et Sapiens nous avaient un peu rodé au métier et permis de constituer un petit capital. Le statut d'auteur de logiciel indépendant était encore nouveau et très ambigu. Nous avons alors décidé de monter une société pour travailler dans un cadre plus "officiel".
by Didier Guillion

Dev News Monday, Jun 19th, 2006 at 05:02pm
Projet PDFToMusic, étape 11
Les différents objets présents dans une partition sont isolés et classés selon leur catégorie : clefs, notes, silences, barres de mesures,etc. La position sur la page de ces différents objets va nous permettre de créer un "squelette" de la page : ensemble d'aire de portées divisées en aires de mesures.  Le type de clef, et la tonalité associée à chaque mesure semble correctement interprété.
Les objets plus élémentaires (notes, silences) sont associés aux mesures selon leur position. Il est nécessaire de mettre en place une analyse des "ledgers lines" (lignes de repérage) pour pouvoir trouver la portée lorsque le symbole est situé en dehors de l'aire des lignes de la portée. Ensuite, il va falloir associer à chaque symbole ses attributs : altération, paroles associées, ornements, etc. Les paroles posent un problème car il est difficile de savoir si un texte en pied de page fait partie du pied de page ou de parole associés à la dernière portée de la page.  
Dès qu'une nouvelle étape de la reconnaissance est validée, l'export MusicXML correspondant est écrit afin de pouvoir comparer visuellement le résultat.
La partie analyse de document qui fonctionnait sur Macintosh depuis le début à été transférée sur Windows et compilée. Une fois de plus Acam nous à fait gagner un temps considérable de portage.
by Didier Guillion
 1 comment.

Memories Friday, Jun 16th, 2006 at 05:00pm
Sapiens (2/3)

Dans Sapiens, et contrairement aux jeux qui existaient alors, il fallait avant tout priviligier la diplomatie, les cadeaux, échanges d'objets et éviter les combats. Un joueur qui voulait aller loin, devait en premier lieu repérer les sources qui lui permettrait de se désaltérer et remplir ses gourdes.
Ensuite, pour manger, il était impératif de ramasser des pierres, les tailler pour se fabriquer lances, haches et chasser le lapin. Le deuxième objet essentiel etait l'outre que l'on pouvait remplir d'eau afin de traverser des régions où il n'y avait pas de sources.
Plusieurs tribus se partageaient le monde, les "Pieds Agiles", tribu de notre héros, dont les ressources étaient la cueillette et la chasse. Au Nord Est, les "Yeux malins", pacifiques, plutôt spécialisés en objets manufacturés et experts en négoce. Au Nord Ouest les "Hyènes Folles", des fanatiques violents avec qui il était très difficile de négocier autrement qu'en fracassant des haches sur les cranes ou vice-versa.
Alors, bien évidemment le joueur qui persistait, dès le début du jeu à insulter son chef puis se battre avec lui, se retrouvait pourchassé par l'ensemble de sa tribu et ne passait pas la journée...
 
Un grand plaisir, c'est que 20 ans après, j'entends encore dire "Sapiens ? J'ai rien compris, j'arrêtais pas de mourir de soif et tout le monde me tapait dessus..."
 
Plutôt tenaces, nous voulions coûte que coûte mettre de la musique, et ce, même si l'ordinateur n'avait pas de circuit sonore. C'est le principe de la modulation delta qui sera appliqué. Une fréquence "porteuse", très aiguë est émise sur le bit unique est modulée pour simuler plusieurs voix simultanées (autrement dit, comment jouer un quatuor de Mozart sur un buzzer de montre-bracelet). La musique sera écrite sur "K-Muse" par Gilles Soulet et son dynamisme contribuera largement au succès du jeu.  
 
by Didier Guillion
 1 comment.

Dev News Thursday, Jun 15th, 2006 at 04:59pm
Projet PDFToMusic, étape 10

Plusieurs fichiers PDF, encodant les caractères sous forme d'images bitmap sans indication de début et de fin de symbole ont été localisés. Une catégorie a donc été créée pour les regrouper, ce sera la catégorie 3.
Nous avons donc actuellement 4 catégories, divisées en sous-catégories :
La catégorie 0 (zéro) : Ce sont les PDF n'incluant qu'une seule image non vectorielle de la partition par page du document. Non utilisable.
La catégorie 1 : Les symboles musicaux sont délimités et dessinés à partir d'une police de caractère.  
La catégorie 2 : Les symboles musicaux sont délimités et dessinés à l'aide de tracés vectoriels (catégorie 2.1) ou d'images bitmap (catégorie 2.2).  
La catégorie 3 : Les symboles musicaux ne sont pas délimités et dessinés avec des images non vectorielles (catégorie 3.2). On peut supposer que la catégorie 3.1 existe (symboles musicaux vectoriels non délimités) mais elle n'a pas été rencontrée pour l'instant. Son traitement serait des plus délicat...
 
Les catégories 1, 2 et 3 convergent vers le module de reconnaissance de caractère mis au point par Olivier qui a été connecté à l'ensemble et donne des résultats probants.
La base de donnée des tracés est alimentée avec l'ensemble des données extraites des catégorie 1 et 2. J'hésite encore à généraliser ceci à la catégorie 3 car ceci risque de faire "enfler" la base de manière drastique.
Le module de reconnaissance arrive à séparer les coulés et liés des autre symboles, eux aussi n'alimentent pas la base de donnée.
 
Lors de l'analyse des PDF en notre possession, un cas particulier de la catégorie 1 a été rencontré. Certains fichiers ne codent pas les lignes des portées avec des commandes PDF (ligne, ou rectangle) mais utilisent un caractère particulier d'une fonte embarquée représentant 5 lignes horizontales sur quelques pixels. Ce cas devra être traité.
by Didier Guillion
 1 comment.

Memories Wednesday, Jun 14th, 2006 at 04:39pm
Sapiens (1/3)

En cette année 1986, le jeu vidéo se divise grossièrement en trois catégories. Les jeux de simulation (mais la puissance des ordinateurs n'est pas encore là pour donner une vraie dimension à ce type de jeu), les jeux de "Shoot them up", où l'on tire sur tout ce qui bouge (Doom en sera l'aboutissement en 3D quelques années plus tard), et les jeux d'aventure où il faut résoudre des énigmes pour aboutir au but. Des trois catégories, c'est le jeu d'aventure qui sollicite le plus de réflexion de la part du joueur. Mais, en général, cela se présente comme un jeu de l'oie, où une énigme dans chaque case permet de passer à la case suivante.  Nous avions dans nos cartons l'idée d'un jeu où le degré de liberté serait immense, un compromis entre le jeu de simulation, arcade et aventure.
Notre création précédente le 5ème Axe, se vendait très bien, nous pouvions donc prendre le risque de nous faire plaisir en tentant l'originalité. Le joueur serait plongé dans un monde immense et il ferait ce qu'il voudrait. L'"aventure" se créerait selon ses actes ce qui garantirait une partie réellement différente à chaque fois.
Une fois le principe posé, il nous fallait trouver un cadre qui puisse "entrer" dans les ordinateurs à notre disposition. L'aspect dépouillé du néolithique nous est très vite apparu : conversations simples, nombre d'objets limité, paysages homogènes. Le personnage sera donc un homme préhistorique. L' Homo Sapiens Néandertalensis fut choisi car à l'époque on commençait déjà à réabiliter ce Sapiens et certains scientifiques le dégageait de l'aspect simiesque où l'on voulait le cantonner.
 
Le découpage de jeu dégagea deux modules principaux, et deux subalternes. Tout d'abord il nous fallait montrer en vue subjective le paysage avec montagnes, arbres, nuages, soleil, etc. Ensuite, en vue latérale, le personnage lui-même pour les scènes de discussion, troc, chasse et combat.
Les modules mineurs furent la taille des silex pour fabriquer des armes et la création du personnage.
 
Des proposition de module comme fabrication de vêtements ou allumage de feu furent abandonnées. Egalement, l'idée initiale intégrait les sens de l'odorat et de l'ouie dans la perception de l'environnement. Ceci aussi passa à la trappe.
 
A partir de la position dans le plan de jeu, des racines d'un générateur de nombre pseudo-aléatoire étaient calculées, et produisaient un décor différent mais reproductible : si le personnage revenait au même point, il retrouvait l'endroit tel qu'il l'avait vu. La "grille" faisait ainsi trois millions de points différents.
 
Dans notre esprit, le milieu naturel était proche de la savane africaine actuelle, nous avons donc construit un algorithme de "pousse d'arbre" qui simulait des arbustes tel que l'on peut en voir aujourd'hui en Afrique, à partir du générateur de nombres pseudo-aléatoires . Ceci fut utilisé dans la vue latérale.
 
Lorsque Loriciels nous a envoyé les rushes de la jaquette nous avons bondit. Il n'y avait pas de Stegausores à cette époque ! Mais ils  n'ont rien voulu savoir...
by Didier Guillion
 2 comments.

Dev News Tuesday, Jun 13th, 2006 at 05:13pm
Projet PDFToMusic, étape 9

Les caractères musicaux sont maintenant isolés depuis le document PDF original. Une collection des différents tracé des glyphes est mémorisée sous la forme d'un fichier de donnée.  
Lorsque l'on rencontre un caractère, on le recherche dans la base de donnée, et s'il n'y est pas on le rajoute. Pour l'instant la relation entre le glyphe et sa signification (par exemple tête de noire, ronde,etc) se fait "à la main". Très bientôt cette tache sera confiée au module de reconnaissance de caractères développé par Olivier.
L'analyse de la page détermine les ensembles de portées (systèmes), puis les aires des lignes de portées dans le système, puis les aires des mesures dans ces lignes, enfin, chaque caractère musical reconnu est collecté dans la mesure le contenant. Pour contrôler si ceci est correct, il faudrait redessiner ce que nous comprenons sur l'image de la page. Mais cela demanderait de réécrire quasiment un affichage complet de tous les symboles et nous ne sommes pas sur que cela servira dans la version finale. Nous préférons donc écrire (en fait réécrire puisque cela existe déjà en MyrScript) un exporteur au format MusicXML. Le format MusicXML a d'ailleurs de forte chance d'être un des formats d'exportation prioritaire de PDFToMusic. La procédure de validation est donc plus simple : créer un document avec Harmony, l'imprimer en PDF, le traiter avec PDFToMusic, recharger le MusicXML obtenu et contrôler les différences.
Des premiers essais sont menés sur des partitions simples.
 
Voici le document original créé avec Harmony puis exporté en PDF.

 
Le PDF est chargé par PDFToMusic et exporté en MusicXML.
 
Le fichier MusicXML généré par PDFToMusic est chargé avec un autre logiciel :

Toute la chaîne de traitement est maintenant en place, mais il reste une part énorme de travail : comprendre et convertir le maximum des informations que l'on peut trouver dans dans une partition.
by Didier Guillion

Memories Friday, Jun 9th, 2006 at 04:49pm
Le CPC 464-664

En octobre 1985, nous faisons l'acquisition d'un CPC 664 (version avec lecteur de disquette du 464)  pour porter le 5ème Axe qui commence à se vendre très fort sur Thomson. La machine est nettement plus évoluée qu'un MO5 (Il faut l'avouer, ce n'est pas vraiment difficile). Ce n'est toujours pas l'équivalent du Commodore 64, mais cela tient la route. Le problème est que nous devons assurer le portage très rapidement : un mois et nous n'avons jamais vraiment travaillé en Z80. (Les processeurs sont différents et bien sûr tout notre programme est écrit en langage machine). De plus, nous étions respectivement, Olivier lycéen et moi étudiant en Biochimie, c'était les cours la journée et la programmation la nuit, week-end et vacances.

Nous choisissons de faire un cross-développement (développement croisé, on édite/compile sur une machine autre que celle qui exécute le programme). Nous écrivons un assembleur/désassembleur Z80 sur Thomson, un programme de conversion de code 6809 en Z80 et connectons Thomson et Amstrad via un cable branché sur le port parallèle.  
Nous profitons du fait que, contrairement au Thomson, l'Amstrad possède un circuit sonore, pour ajouter une musique polyphonique pendant le jeu, musique écrite à l'origine sur Commodore 64 par Gilles Soulet à l'aide de notre logiciel K-Muse.  
 
La version CPC sera livrée juste à temps pour les fêtes de Noël, mais l'écran intégré de très mauvaise qualité du CPC m'aura abimé les yeux à un point tel que je suis resté pendant plusieurs semaines sans pouvoir supporter la lueur d'un écran vidéo...
Le 5ème Axe campera une position résolue, pendant plusieurs mois, au top ten des meilleures ventes de jeu en France, (même Hebdogiciel en a dit du bien...)  mais nous étions déjà sur un autre projet, un jeu résolument différent de tout ce qui pouvait exister...
 
by Didier Guillion
 1 comment.

Dev News Thursday, Jun 8th, 2006 at 04:51pm
Projet PDFToMusic, étape 8

Un tracé des caractères en courbe de Bézier a été implémenté, cela nous permet de faire avancer de manière drastique le visualiseur de document PDF.
D'autant plus que l'encodage des différents types de polices a été uniformisé et que tous les tracés convergent maintenant vers ce module unique.
Voici par exemple un fragment de partition, visualisé à l'aide du logiciel "Aperçu" qui utilise les fonctions de Mac OS X:

Et le mème fragment, affiché à l'aide de notre visualiseur.

Le résultat nous semble encourageant...
by Didier Guillion
 2 comments.

Dev News Wednesday, Jun 7th, 2006 at 04:54pm
Projet PDFToMusic, étape 7

Il nous faut mettre en place une règle de décision qui détermine si une police est musicale ou non, avant d'invoquer la reconnaissance de caractère. Pour ce faire, on utilise la statistique de répartition des caractères sur la page.
A partir d'une collection des lignes présentes sur la page, les aires des portées sont extraites, ainsi que les aires des systèmes, puis les aires des mesures sont calculées.
L'algorithme de raboutage de caractères en mot a été écrit, on obtient donc une liste de mots associée à chaque page. Apparemment, le PDF fonctionne en Unicode pour l'encodage des caractères, cela tombe bien, Harmony Assistant est Unicode depuis peu...
 
Nous allons fournir ici très bientôt les premiers résultats préliminaires.
by Didier Guillion

Memories Tuesday, Jun 6th, 2006 at 05:15pm
Le 5ème axe

1985. Que cela nous plaise ou non, même si l'on considère cela comme injuste au vu de ces capacités, le MO5 est là et se vend comme des petits pains tricolores. Mais toute médaille à son revers. En dépit des franches rigolades que nous a procuré la simple lecture de ses caractéristiques techniques, nous savons que l'on achète un ordinateur pour plein de bonnes raisons pédagogiques mais qu'ensuite on cherche surtout à y mettre des jeux dessus. Or, des jeux il n'y en a pas. Typiquement Franco-Français, le MO5 n'intéresse pas les éditeurs anglo-saxons. Ses capacités sont trop primaires pour envisager le portage simple de jeux tournant sur de vrais ordinateurs (Mis à part l'excellent "Aigle d'Or" qui sera adapté de l'Oric au MO5 avec un succès plus que mérité)
Loriciels nous contacte avec insistance pour nous demander une version MO5 de Véga. Nous leur expliquons que, même si Véga n'utilise que 5% des capacités fabuleuse du Commodore 64, c'est totalement impossible à faire sur un Thomson. Ils insistent lourdement et nous nous mettons à réfléchir à un jeu spécifique au MO5. Une particularité de la machine nous intrigue.

 
L'unique mode vidéo du MO5 gère de manière séparée le plan noir et le plan couleur. Ceci permettrait de travailler assez rapidement sur deux plans. Nous imaginons donc des personnages en noir et blanc, évoluant sur un décor défilant en couleurs (4 couleurs il ne faut pas trop espérer).
 
Rapidement le principe du 5ème Axe voit le jour. Il ne nous reste plus qu'a appliquer la routine habituelle : écrire un assembleur/ désassembleur 6809 en Basic, s'en servir pour écrire un assembleur/désassembleur en assembleur, écrire avec celui-ci un éditeur pour les graphismes...
 
Vous pouvez lire sur cette page l'histoire du jeu.
En six mois, le 5ème axe voit le jour et les cassettes envoyées aux principaux éditeurs. Aussitôt les coups de téléphone pleuvent, ce qui nous permet de négocier un pourcentage sur les ventes plus intéressant. Finalement, nous signons avec Loriciels, qui nous demande dans la foulée une version pour CPC 464...
by Didier Guillion
 1 comment.

Dev News Monday, Jun 5th, 2006 at 08:32am
Projet PDFToMusic, étape 6

Le travail sur ce projet a débuté depuis trois semaines. Nous attaquons maintenant le problème posé par ce que nous avions appelé précédemment la catégorie 2. Dans cette catégorie, les textes sont dessinées en utilisant des commandes PDF sans aucune référence à une police ou indication de début et de fin de caractère, contrairement à la catégorie 1.  L'extraction des caractères en est difficile mais nous construisons un algorithme de décomposition de chemin PDF qui donne de bons résultats. Là aussi, tous les tracés sont convertis dans notre ensemble de commande de tracés communs.
En l'état, nous traitons 99% des documents musicaux PDF en notre possession, mais de nouveaux cas particuliers peuvent encore survenir...
La prochaine étape sera de rendre tout ceci plus propre (pas mal de sources ont été écrits/réécrits plusieurs fois et sont un peu de guingois) et de le valider sur un maximum de fichiers PDF.
Comme nous avons choisi d'extraire les caractères un par un, il va falloir réfléchir à un module qui raboute (concatène) les caractères isolés en mots, (voire phrases) associés à une position précise sur la page.
 
Plusieurs personnes nous ont écrit pour nous soutenir dans ce projet PDFToMusic et nous les remercions de leurs avis et conseils. Dans notre esprit, nous essayons de converger vers une généralisation de la reconnaissance de caractères musicaux et de création de structure de partition. Cette "couche", qui recevrait des symboles bruts non reconnus et en produirait du MusicXML, MIDI, document Melody/Harmony ou autre, pourrait être alimentée soit à partir de l'extraction depuis des documents PDF, soit à partir d'images scannées.  
Si cela pouvait fonctionner, cela aboutirait à un programme d'OCR entièrement nouveau. Un genre de Super-OMeR...
by Didier Guillion

Memories Friday, Jun 2nd, 2006 at 05:17pm
Une cloche Thomson, sonne...

1985. A cette époque, il sortait une nouvelle marque d'ordinateur chaque mois. Le géant de l'électronique Française, Thomson, décida de s'y mettre. Le marché était juteux. "Miam !" On du se dire les costard-cravates, devant les courbes ascendantes en couleur. "Il faut saisir l'opportunité de la conjoncture".
Bien sur, l'effort de Thomson sera essentiellement porté sur la manière de vendre le plus de machines et non pas sur les capacités de ces machines elles mêmes. Ayant obtenu le monopole (avec Bull Micral) du marché de l'éducation, Thomson s'apprétait à produire des "sous-ordinateur" et empocher des bénéfices collosaux.
Le premier à apparaître sera le TO7. Doté d'un stylo optique et d'un clavier à membrane, il se voulait "sérieux et familial". Je me rappelle, chez S*** rue Kennedy, avoir observé du coin de l'oeil, une personne essayant un TO7 en démonstration. Elle commence à taper sur le clavier, mais c'est si désagréable et douloureux aux doigts, qu'elle réfléchit deux secondes, saisit le stylo optique et s'en sert pour presser les touches !  
Pour dire à quel point ces ordinateurs étaient "pensés" : le MO5 avait un bouton de "reset" bien en vue sur le dessus. Une simple pression malencontreuse, un livre inconsidérement posé sur la machine et tout était effacé...Génial sur un nano-réseau.
Alors, que ce soit le TO7 ou un peu plus tard le MO5, le constat sera le même. Alors que les ordinateurs individuels n'avait pas 5 ans, Thomson avait réussit à manquer deux ou trois générations... Pas de mode vidéo, pas de circuit sonore (le processeur devait tout gérer sur un bit),  comme on disait à l'époque, des ordinateurs "tout pourri de l'intérieur". La seule chose que l'on pouvait porter à leur crédit était le microprocesseur, un 6809, excellent composant. Certainement un moment d'égarement de Thomson qui, pour poursuivre dans la continuité, aurait du choisir le Z80...
Mais par contre, une campagne basée sur l'effet "Cocorico" : "C'est Francais, mon bon Monsieur", et un monopole dans l'éducation "Vous comprenez Monsieur, votre enfant pourra travailler sur le même ordinateur qu'en classe", fait que le MO5 va se répandre. Et nous proposer un nouvel axe de travail...
by Didier Guillion
 1 comment.

Dev News Thursday, Jun 1st, 2006 at 04:32pm
Projet PDFToMusic, étape 5

Les polices de type TrueType, Adobe Type 1, Adobe Type 1C,Type 3 et une police dérivée du TrueType, le Type CiD type 2, ont été uniformisées en un ensemble de commandes de tracé. Ceci nous permet d'avoir un module de tracé commun pour toutes les polices rencontrées et ainsi pouvoir comparer plus facilement les glyphes.
Certains fichiers PDF encodent les glyphes des polices, non pas sous forme de tracés vectoriels (courbes de Bézier) mais d'images bitmap monochromes. On peut repérer ces fichiers au fait que, lorsque  l'on augmente l'échelle de visualisation du PDF, certains caractères deviennent crénelés.
Ceci a été traité et uniformisé.
Afin de valider nos extractions, un visualiseur de document PDF est mis en place. Ceci nous permet de contrôler "de visu" ce que nous "comprenons" dans un fichier PDF et servira vraisemblablement ultérieurement à montrer le document chargé à l'utilisateur.
Lors de l'analyse du document, les glyphes sont isolés et tracés dans une image en niveau de gris. Cette image est donc prête à s'interfacer avec le module de reconnaissance de caractère en cours de mise au point par Olivier.  
La plupart des fichiers PDF avec police se chargent plutôt bien, nous allons maintenant nous plonger sur la catégorie 2 : fichiers PDF sans police de caractère incluse.
by Didier Guillion


Full view
Reduced view
Most recent first
Oldest first
All
Didier Guillion
Olivier Guillion
Sylvie Ricard
All
Mood
To be seen
Dev News
Memories
Myriad Life
Technical
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
Mar 18th, 2024 at 08:14pm 
Comment from Sylvain
Mar 18th, 2024 at 08:13pm 
Comment from Sylvain
@André
Mar 18th, 2024 at 07:28pm 
Comment from Antoine Bautista
Build 82....
Mar 18th, 2024 at 05:02pm 
Article from Didier Guillion
Harmony Assistant 9.9.8  étape 198
Mar 18th, 2024 at 05:02pm 
Article from Didier Guillion
Harmony Assistant 9.9.8  étape 198
Mar 17th, 2024 at 11:40am 
Comment from Antoine Bautista
Frite....
Mar 17th, 2024 at 11:40am 
Comment from Antoine Bautista
Frite....
Mar 16th, 2024 at 09:16am 
Comment from André Baeck
Mar 16th, 2024 at 09:16am 
Comment from André Baeck
Mar 16th, 2024 at 09:13am 
Comment from André Baeck

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