 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 |  |
|
| |
|
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 | |
| |
|
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 | |
| |
|
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 | |
| |
|
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 | |
| |
|
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 | |
|
| |
|
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 | |
|
| |
|
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 | |
|
| |
|
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 | |
| |
|
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 | |
|
| |
|
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 | |
|
| |
|
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 | |
|
| |
|
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 | |
|
| |
|
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 | |
| |
|
 A me lire, on pourrait croire que je suis devenu un monomaniaque du spam, et que je passe plus de temps à chercher des moyens de l'éviter que cela ne m'aurait pris à le traiter manuellement.
Hélas, ce n'est pas le cas.
On peut percevoir actuellement des évolutions, qui ne laissent rien présager de bon.
Posons-nous la question: quel est le but des spammeurs ? Que leur message soit lu par un maximum de personnes, peu importe le moyen, à condition que ce soit gratuit. Les considérations déontologiques ou morales, ils s'en fichent comme la première pilule d'aspirine colorée à l'encre qu'ils ont vendue en tant que viagra. S'il pouvaient se faire un peu plus de fric en pourissant tous les courriels de l'association des orphelins myopathes victimes de l'amiante lors de la journée de promesses de dons, ça ne leur ferait ni chaud ni froid.
Mais maintenant que de plus en plus de boîtes aux lettres électroniques sont protégées pas des filtres anti-spam performants, l'opération perd de son efficacité. Et lorsqu'arrivera le jour où tout le monde en sera équipé, ce sera la fin du spam tel que nous le connaissons.
Alors, quel moyen pour toucher un maximum de personnes, si ce n'est le mail ?
Leur réponse semble être: les forums et les blogs.
On peut raisonnablement prédire que dans un futur proche, la proportion de spam sur ce genre de média se rapprochera de celle actuellement constatée sur le mail. Un taux proche de 50% n'est pas irréaliste.
Il suffit que des personnes soient payées pour se balader sur le Web, et pour poster le spam sur un maximum de forums de discussion, blogs, livres d'or, ou au travers des systèmes de messages privés.
Pour l'instant, beaucoup de spam de ce type est réalisé "à la main".
Cependant, ces derniers jours, on assiste à une recrudescence importante des automates.
Il s'agit de programmes, qui parcourent le Web à la recherche de forums ou de blogs utilisant des types de logiciels connus. Le programme crée alors automatiquement un compte (le spammeur dispose d'une bonne quantité d'adresses e-mails anonymes pour la réponse), récupère le mot de passe renvoyé par courrier électronique, l'utilise pour entrer dans le forum, et poste le message.
Mais, plus inquiétant, certains s'arrêtent juste après la création du compte, et en créent ainsi plusieurs, sans poster aucun message. Ces pseudonymes "dormants" sont probablement destinés à laisser au spammeur de nombreuses portes ouvertes sur les forums, afin d'être capable de poster en un instant l'annonce pour laquelle ils ont été payés, en plusieurs milliers d'exemplaires.
Dans les 15 derniers jours, environ 50 à 60 inscriptions de ce type ont été recensées sur notre forum de discussion. Certains pseudos avaient été utilisés pour s'inscrire sur plus de 200 000 forums différents au hasard de la toile!
On peut considérer, sur le mois dernier, que 60 à 80% des nouvelles inscriptions à notre forum ont été réalisées par des spammeurs.
J'ai dû rapidement supprimer tout ça, et mettre en place un filtre permettant d'éliminer le plus gros d'entre eux lors de l'inscription. En deux jours, ce filtre grossier a bloqué une bonne dizaine de ces inscriptions, et en a laissé passer deux, que j'ai bannies ou supprimées manuellement.
Nous allons donc probablement nous résoudre à appliquer des méthodes plus drastiques contre la création automatique de compte d'utilisateur, aussi bien sur nos forums que sur ce blog.
Lors de l'inscription, au lieu de renvoyer simplement un message donnant le mot de passe, il s'agira d'un message contenant une phrase du type: "Merci de décrire succintement le thème du forum, et ce que vous espérez y trouver dessus".
Ce n'est que lors de la réception de la réponse, et après un contrôle manuel, que l'inscription sera validée et le mot de passe envoyé.
Ainsi, seul un opérateur humain, sachant de quoi traite notre forum, et disposé à passer plus de 10 secondes à répondre, pourra s'inscrire.
Cela devrait déjà éliminer pas mal de nuisibles.
|
|
|
| by Olivier Guillion |  |
|
| |
|
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 | |
|
| |
|
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 | |
|
| |
|
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 | |
| |
|
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 | |
|
| |
|
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 | |
| |
|
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 | |
|
| |
|
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 | |
| |
|
|
