Nous avons donc attaqué la partie impression d'Acam. Afin de bien comprendre la charge de travail un petit rappel du mode de fonctionnement est nécessaire. Dans Acam affichage à l'écran et impression ont très vite été séparés. Pour l'écran, à chaque fenêtre est associé un "offscreen" (une image pixélisé en couleur) sur lequel Acam dessine lui-même quasiment tout. Seul les textes sont affichés par l'OS dans l'offscreen. La gestion des différents types de polices, de modes de transfert, de rotation, serait un vrai casse tête. De fait une normalisation commence à apparaître : l'ATSUI. C'est ce que nous utilisons sur Mac OS X. Utiliser ce type de fonctionnement pour l'impression est possible, c'est le mode "Imprimer selon une image haute résolution" d'Harmony Assistant. Cependant cela entraîne quelques problèmes. D'une part, pour avoir une précision suffisante, il faut utiliser un offscreen immense. N'oublions pas que la résolution standard d'un écran est de 72 pixels par pouce (ppp) une imprimante va facilement jusqu'à 2400 ppp. Le temps de transfert de l'image vers le périphérique va donc être non négligeable. Ensuite certains types d'imprimantes gèrent eux même les tracés de manière intelligente (par exemple les imprimantes PostScript) et vont se charger de lisser les différents graphismes au mieux de leur capacité. Donc lorsque nous voulons imprimer une page sous Acam : Les différents ordres graphiques sont collectés dans une structure très proche du PicHandle de Mac OS 9. Ces différents ordres sont reinterprétés et traduits dans des commandes dépendantes du système et envoyé au pilote d'impression. Il est donc nécessaire de traduire toutes les commandes graphiques générique d'Acam: MoveTo, LineTo, Clip, Fill, etc, en commandes spécifiques au système. Bon week end ! |
|
|
by Didier Guillion | | |
| |
|
Nous avançons lentement mais surement. Nous commençons à comprendre de mieux en mieux comment fonctionne Mac OS X. En effet, nous devons déconnecter tous les automatismes de Cocoa pour gérer les choses à notre façon : la gestion des allocations mémoires, les objets graphiques, les évènements clavier et souris, etc. D'abord, l'accès aux fenêtres systèmes de sélection de fichier à charger et à sauver, de paramétrage des imprimantes a été implémenté : Depuis Myredit, il est donc maintenant possible de charger un fichier de le modifier puis de le sauvegarder sous un autre nom. A noter que le multi-fenêtrage est opérationnel ainsi que le déplacement et le changement de taille. Un grand point positif : nous craignions vraiment rencontrer des problèmes en mixant de l'Objective-C et du C, et bien non, avec un peu de discipline les appels de l'un à l'autre se font sans mécanismes compliqués. Nous avons perdu pas mal de temps avec une réaction étrange de GCC (le compilateur C de XCode). En C, les paramètres des fonctions peuvent être flous. GCC le gère d'une manière un peu particulière puisqu'il refuse les données de moins de 4 octets, affiche juste un avertissement et génère de l'assembleur avec une instruction destinée à faire planter le programme : ud2a. Nous n'avions jamais vu cela. La saisie de la position globale du curseur de la souris a également été assez coton. Après plusieurs essais infructueux et plantogènes nous sommes passés par la possibilité qu'offre Mac OS X de détourner les évènements de périphériques à un très bas niveau via CGEventTapCreate. Et cela fonctionne. Prochaine étape, l'impression, il va y avoir du boulot ! |
|
|
by Didier Guillion | | | |
|
Tout a bien avancé aujourd'hui, nous avons mis en place la possibilité d'utiliser des aspects d'interface différents sur Mac. En une journée, nous avons donc avancé de trois ans (passage direct de Windows 98 à Windows XP) Nous avons également passé les fichiers source sur Linux, et essayé une première compilation. Malheureusement, nous avions oublié que le système de fichier sur lequel notre Linux est installé est sensible à la casse, ce qui lui fait considérer par exemple le fichier "Acam.h" comme différent du fichier "acam.h". Il va donc falloir faire pas mal de petites modifications dans nos fichiers sources avant de pouvoir espérer compiler tout ça proprement... |
|
|
by Olivier Guillion | | |
| |
|
Alors que tout commençait à fonctionner plutôt bien au niveau des textes, nous nous sommes rendus compte que les appels système que nous utilisions sur Mac OS X ne nous permettraient pas d'aller assez loin, leurs options étant trop limitées. Par exemple, les styles de fontes (gras, italique) n'étaient disponibles que si une fonte dédiée était installée. Nous avons donc dû tout reprendre en utilisant l'ATSUI, une couche logicielle très puissante mais assez délicate à mettre en oeuvre, que vous avions déjà utilisée pour l'affichage des textes Unicode au sein de nos logiciels. Les opérations de nettoyage et de clarification des fichiers sources continuent en parallèle. Nous allons bientôt pouvoir créer un projet de test sous Linux (GTK+), et essayer de compiler nos modules sur cette plate-forme. Travailler sur 3 systèmes à la fois nous permettra alors de déterminer comment mieux séparer ce qui est dépendant du système de ce qui ne l'est pas. |
|
|
by Olivier Guillion | | | |
|
Pas mal d'avancées satisfaisantes pour finir la semaine. D'un coté, un gros travail de séparation des fonctions génériques de celles spécifiques à la machine a été fait. Il nous restera donc a remplir les sources mannequins pour obtenir une version d'Acam sur n'importe quel OS. Pour entrer dans le détail, depuis quelques dizaines d'années, les systèmes d'interface graphique n'ont guère divergés. Il y un menu, des fenêtres. Chaque fenêtre propose une aire système (titre, marges...) et une aire utilisateur sur laquelle on peut dessiner ce que l'on veut. Alors, pour créer une fenêtre cela peut être NewWindow, CreateWindow, OpenWindow sur les différents OS, le résultat reste le même. Donc, notre entrée AcamCreateWindow devient l'entrée générique pour toutes nos applications. Ensuite, sur Mac OS X, nous avons réussi à gérer les menus de manière conforme à l'aspect du système : Au passage, l'appli est un petit éditeur de texte que nous avons écrit il y a une vingtaine d'année pour tester les premières versions d'Acam. La prochaine étape est l'uniformisation de la gestion des polices de caractères. Bon week-end ! |
|
|
by Didier Guillion | | |
| |
|
Maintenant que tout est plus ou moins en place, nous nous sommes replongés dans la totalité des fichier sources d'Acam pour séparer tout ce qui est spécifique au système d'exploitation hôte de ce qui est commun. Les appels au système Windows étant très nombreux, et intriqués dans les modules supposés être communs, c'est un travail de minutie et de patience. Cela permettra, à terme, d'avoir d'un coté le noyau logique d'Acam, avec la gestion de tous les objets, événements, etc, qui sont identiques partout, et d'un autre coté une collection la plus limitée possible de fonctions dépendantes de l'OS. C'est seulement cette dernière partie qu'il faudra réécrire chaque fois que nous porterons Acam sur un nouveau type de machine, d'où l'intérêt de la réduire au strict minimum, afin de réduire d'autant la complexité et le temps de portage. |
|
|
by Olivier Guillion | | | |
|
Nous avançons pas à pas sur le développement d'Acam sur Mac. Un point important a été franchi quand nous avons enfin réussi à détourner les évènements système bas niveau vers notre propre système de traitement. Pour résumer, Cocoa définit des objets qui reçoivent des évènements. Chaque objet traite l'évènement selon ses propres méthodes, qui peuvent être surclassées. Nous, nous fonctionnons "à l'ancienne", c'est l'objet qui envoie une requête à l'interface pour savoir si un évènement est disponible. La conversion de la couche graphique avance également, nous commençons à afficher des éléments simple en utilisant CoreGraphic. Comme nous sommes passés d'offscreens QuickTime à des offscreens CoreGraphic (les entrées bas niveau de Mac OS X) il est maintenant possible d'utiliser toutes les fonctions CoreGraphic et en particulier l'affichage des textes. Nous n'arrivons toujours pas à demander à CoreGraphic de nous dire la taille en pixels X et Y d'un texte, mais apparemment nous ne sommes pas les seuls à rencontrer ce problème... D'où l'aspect décalé de l'état actuel de notre test : Mais cela nous satisfait, une vilaine fenêtre Window 95 qui tourne sous Mac OS X... Il faut également savoir que les origines de tracé ont changé. Carbon et QuickTime considéraient que le point (0,0) était en haut à gauche de l'espace. CoreGraphic le place en bas à gauche. Pas mal de gymnastique arithmétique donc. Mais nous évoluons dans le bon sens : une uniformisation des fonctions vers une couche système dépendant. Dès que cela sera à peut prêt au point, nous tenterons une compilation sous Linux. |
|
|
by Didier Guillion | | | |
|
Apparemment, on était mal partis dans la gestion des offscreens (aires non visibles sur lesquels ont lieu tous les tracés graphiques avant d'être transférés à l'écran) sur Mac OS. Nous avions utilisé un jeu de fonction bien documentées mais au final peu pratiques. Nous avons trouvé presque par hasard une autre documentation, qui présente une autre manière de créer ces offscreens, avec plus de souplesse et plus de possibilités (gestion des affichages de polices de caractères plus aisée, etc) Nous en sommes donc revenus là où nous en étions hier, mais avec le nouveau système graphique. On devrait maintenant pouvoir progresser plus aisément. En parallèle, nous avons jeté un oeil au développement sur Linux. Nous avons dû d'abord répondre à l'inévitable interrogation "Gnome/GTK+ ou KDE/QT". Nous avons décidé d'essayer d'abord GTK+. Nous avons créé un petit programme C qui ouvre une fenêtre, et est capable de dire si le bouton de la souris est cliqué ou relâché sur celle-ci. Ca n'a l'air de rien, mais cela nous permet de commencer à évaluer la difficulté d'un portage d'Acam sur cette plateforme. A priori, la structure de la boucle de gestion des événements est très proche de celle de Mac OS X. |
|
|
by Olivier Guillion | | | |
|
Toutes les fonctions graphiques qui étaient écrites en assembleur ont entièrement été réécrites en C. Cette version est probablement un peu moins rapide que la version originelle, mais la différence ne saute pas aux yeux. Bien entendu, nous conservons les versions rapides en assembleur pour Acam sur Windows. Ceci a cependant permis de commencer à tracer le contenu des fenêtres (titre, cadres, boutons, etc) sur Mac OS, et facilitera le portage ultérieur vers de nouveaux systèmes. Nous avons ainsi obtenu quelque chose qui ressemble à une fenêtre Windows 95, le look par défaut, sur Mac OS X. Il y a encore quelques ratés, et l'affichage des textes n'est pas opérationnel pour l'instant, mais c'est un bon début: En parallèle, nous essayons de trouver un système de développement en C efficace pour Linux. Même si la version Linux d'Acam n'est pas pour tout de suite, savoir comment une application devrait être structurée sur ce système nous permettrait de mieux cerner le dénominateur commun entre les interfaces graphiques de Windows, Mac OS 9, Mac OS X, iOS et Linux, et ainsi de concevoir Acam en conséquence. |
|
|
by Olivier Guillion | | | |
|
Nous achevons notre deuxième semaine de développement sur Acam. En surclassant l'objet Cocoa NSWindow nous avons réussi à intercepter plusieurs évènements sur les fenêtres. Mais pour l'instant, si le clavier, le bouton gauche et la mise à jour graphique de l'aire de la fenêtre ne semblent pas poser de problème, nous ne recevons pas d'évènement bouton droit appuyé mais uniquement, bouton droit relâché, étrange... La couche bas niveau de manipulation de mémoire (écrite en assembleur) s'est avérée assez difficile à rendre compatible entre Visual C et XCode : le compilateur GCC de XCode fait vraiment des choses pas très nettes, comme par exemple, utiliser des registres processeur sans les préserver. Nous allons donc réécrire ce module en C pour aller plus loin dans nos tests. De toute manière cela pourra servir d'avoir une version d'Acam 100% en C. Bon week end ! |
|
|
by Didier Guillion | | | |
|
Aujourd'hui Myriad fête son 23 ème anniversaire. Nous nous approchons du quart de siècle... Pour fêter cela nous sommes revenus à nos sources et avons passé la journée dans l'assembleur i386 pour essayer de rendre les codes compatibles entre Visual C et GCC, et ce n'est pas gagné ! Alors un grand poutou à ceux qui nous soutiennent quotidiennement et en avant pour la nouvelle année. |
|
|
by Didier Guillion | | |
| |
|
Nous avons réussi à lier notre librairie Acam mannequin à un très court projet fonctionnant sous Acam Windows. Les premières entrées vides ont été implémentées. En premier, les opérations d'entrée/sortie disque. Ainsi, les fichiers ressources sont apparemment correctement lus et les objets extraits. Les premières fonctions de base ont été écrites : ouverture d'une fenêtre, changement de son titre, redimensionnement. Il reste maintenant à tracer sur cette fenêtre. D'après la documentation Apple, QuickDraw est indépendant de Carbon et intégré à QuickTime, on devrait pouvoir utiliser soit QuickDraw soit, la nouvelle technologie Quartz 2D. Nous pencherions plutôt pour la seconde solution (même si le travail est plus important) car elle est annoncée comme plus rapide et offre des possibilités intéressantes comme les courbes de Bézier. Donc deux objectifs : d'abord définir le remplaçant du GrafPort (le Device Context sous Windows), ensuite arriver à intercepter les évènements qui arrivent sur la fenêtre : mise à jour, click souris, etc et les convertir. |
|
|
by Didier Guillion | | |
| |
|
Mieux vaut tard que jamais... Un clic a du passer à coté du bouton "Envoyer". Aujourd'hui, nous avons optimisé la synthèse, afin d'être sûrs que le calcul puisse s'effectuer en temps réel. Sur notre processeur, maintenant plutôt ancien, un instrument prend environ 4 à 5% du temps machine, ce qui reste raisonnable. Nous avons également amélioré le son du doigt qui glisse sur le trait de la corde, en trouvant un algorithme de mouvement plus réaliste. Nous faisons des essais de léger bruit de glissement sur les cordes lisses (les 3 cordes nylon d'une guitare espagnole, par exemple). Ce n'est pour l'instant pas franchement convaincant, il n'est pas certain que ce soit conservé au final. |
|
|
by Olivier Guillion | | | |
|
Dans tous les tests de sonorité que nous avions menés jusqu'à présent, les morceaux employés étaient déjà travaillés pour un réalisme maximal. Les accords étaient arpégés, les vélocités bien ajustées, etc. Le réalisme du résultat est grandement dépendant de ces ajustements. Même avec un son de guitare quasi-parfait, si le morceau a été entré "au kilomètre", avec des notes calées mécaniquement, toutes à la même vélocité, il y a peu de chance d'obtenir quelque chose de réaliste. Aussi, le module sonore de guitare doit également prévoir une phase de précalcul des paramètres des notes. Ce traitement serait optionnel et configurable par l'utilisateur, et consisterait en quatre rubriques: 1- l'ajustement automatique des durées de notes En effet, si le guitariste n'étouffe pas les cordes, chaque note continue de sonner jusqu'à ce qu'une autre note soit jouée sur la même corde. 2- Le bruit de trait de corde, lorsqu'à la fin d'une note, le doigt se déplace jusqu'à la nouvelle case en frottant la corde 3- L'arpégeage (?) des accords, dépendant du sens du mouvement du plectre et de la vitesse d'exécution 4- Les vélocités, pour lesquelles il nous reste encore à trouver un algorithme de calcul pas trop fantaisiste. |
|
|
by Olivier Guillion | | |
| |
|
Nous avons travaillé sur la configuration des sons de guitare. Maintenant que nous pouvons jouer d'un tel instrument en temps réel, nous avons pu reprendre les paramètres un à un (ils sont pour l'instant stockés sous forme d'un fichier texte), et écouter quel était leur effet sur le son résultat. Ceci nous a permis de savoir quels réglages étaient nécessaires, lesquels n'avaient pas d'utilité sensible, et quelle conséquence avait la modification d'un paramètre sur le son entendu. Nous pourrons ainsi réorganiser ces paramètres pour proposer à l'utilisateur quelque chose de compréhensible et de pas trop compliqué. Dans un autre domaine, nous avions mis en place, dans nos projets d'essai, des sons réalistes de glissement de doigt sur le trait. Malheureusement, la structure de fonctionnement de l'instrument virtuel dans Harmony Assistant ne permet pas au module de savoir quelles notes vont être jouées après celle qu'il traite actuellement. Il ne peut donc pas anticiper le mouvement des doigts, comme le ferait un vrai guitariste. Et si on démarre le mouvement du doigt au moment où la note est censée être jouée, c'est trop tard, le son de la note se décale, ça s'entend et c'est pas beau. Il va donc falloir que nous trouvions une méthode pour parvenir à savoir, lors du jeu de la musique, quel va être le prochain mouvement de la main sur le manche. Ca promet d'être compliqué... |
|
|
by Olivier Guillion | | |
| |
|
Nous sommes en train d'écrire une couche mannequin qui devrait nous permettre à terme de compiler la librairie Acam sous Mac OS et de la lier avec une de nos applications. Bien sur ce n'est qu'une étape car les différentes entrées de la couche mannequin sont vides, il va falloir les remplir. Les sources C se compilent sans aucun problème sous XCode, seule une instruction assembleur est mal digérée par XCode. Il va falloir trouver une solution. Donc pour résumer, quand une de nos applications voudra ouvrir une fenêtre Mac OS X, elle invoquera la fonction Mac OS 9, qui sera émulé par la couche Mac OS 9 d'Acam qui appellera la fonction Windows correspondante qui elle même sera émulée par notre couche mannequin et transformée en appel Mac OS X. Les conversions étant très rapides, nous sommes persuadés que cela sera imperceptible en terme de réactivité pour la plupart des fonctions, les autres seront optimisées pour offrir un accès direct. La seule question en suspend est de savoir si nous allons pouvoir gérer l'interface graphique Cocoa en C sur Mac OS X puisque le langage officiel reste OBJ-C.... |
|
|
by Didier Guillion | | | |
|
Nous avons commencé l'intégration du générateur de son de cordes dans Harmony Assistant. La première étape a été de mettre en fonction un module mannequin, qui joue les notes avec un son simple (sinusoïde). Une fois ce mannequin fonctionnel, il s'est agi de le remplacer par le module de synthèse réel. Cela fonctionne maintenant, nous avons joué et exporté des partitions avec un son de guitare modélisé, directement depuis Harmony Assistant. Il reste maintenant à rendre tout cela bien propre, et à prévoir l'interface graphique qui permettra à l'utilisateur, dans un premier temps, de définir quelles portées doivent utiliser les nouveaux sons, et dans un deuxième temps, de configurer finement les instruments en question. |
|
|
by Olivier Guillion | | |
| |
|
"Pluralitas non est ponenda sine necessitante" Les multiples ne doivent pas être utilisés sans nécessité. (Guillaume d'Ockham) Il y a tous juste 20 ans, en 1991, nous avons commencé le développement de notre librairie Acam (As Clever As Mac). Lassé de devoir recoder une bonne partie de nos programmes sur les différentes machines existantes comme le Mac, le PC, l'Atari ST, nous avons décidé de mettre au point une couche logicielle commune à tous les systèmes. Comme le meilleur système d'interface graphique à l'époque était Mac OS, nous avons donc réécrit celui ci en C. Depuis, tous nos logiciels utilisent cette librairie, bien que depuis près de 15 ans elle ne tourne plus que sous Windows. Entretemps, Mac OS est devenu Mac OS X mais la compatibilité a été assuré par la couche logicielle Carbon qui permet de faire tourner les applications utilisant les anciennes API. Nous craignons qu'un jour, à la faveur d'une mise à jour majeure du système, Apple n'abandonne Carbon. Il est absolument impensable de réécrire tous nos logiciels en Objective-C sous Cocoa en perdant dans le même mouvement ce grand bonus d'avoir des sources compatibles entre Mac OS et Windows ce qui réduit drastiquement nos temps de développement. Nous avons décidé de passer quelques jours à étudier la possibilité de repasser Acam sous Mac OS. C'est un gros travail car au fil des années, Acam est devenu très lié à Windows. Mais ce faisant nous allons essayer de le rendre totalement indépendant du système, ce qui, à terme, permettrait d'envisager un portage vers d'autres systèmes comme l'iOS qui équipe les iPod, iPad et autres iPhone, ou même une version Linux qui permettrait d'avoir enfin nos logiciels sur cette plateforme, en mode natif, sans passer par l'émulateur WINE. A suivre ! |
|
|
by Didier Guillion | | |
| |
|
Le week-end a été passé à restaurer notre PC de développement, dont le système (Windows XP) avait fumé jeudi soir. Nous avions des copies de sauvegarde de tous les fichiers "source", mais par sécurité, nous avons sauvegardé vendredi la totalité de nos données sur un disque externe, grâce à un démarrage sous Linux. Nous avons acheté un nouveau disque interne (SATA 500Mo), sur lequel nous avons à nouveau tout copié - oui, on est un peu paranos sur les risques de perte de données-. Les tentatives de réparation du système on toutes échouées, nous avons donc dû nous résoudre à un reformatage et une réinstallation complète. Nous avons envisagé un moment de passer à Windows 7, mais nous avons préféré différer ça, pour ne pas cumuler les problèmes de restauration des données et d'incompatibilités possibles du nouveau système. Samedi a donc été passé à effectuer les centaines de mises à jour d'XP, à télécharger et installer la trentaine d'applications indispensables et à reconfigurer tous nos outils de développement (compilateurs C et Flash, signatures numériques, editeurs divers, "batchs" de gestion des images réseau, etc. Au final, nous nous retrouvons avec des outils un peu plus à jour, un système plus rapide car moins chargé d'applications mal désinstallées qui s'étaient accumulées depuis 5 ans, et une capacité de disque dur doublée. Aujourd'hui, nous avons recompilé quelques applications pour vérifier que tout va bien. Ainsi, Le Myriad Music Plug-in a été re-posté avec une installation corrigée sur Firefox 4. En effet, il ne trouvait ce navigateur que lorsqu'il n'avait pas été installé à partir d'une mise à jour de Firefox 3. Sur notre site, la version n'a pas bougé car seul l'installateur a été modifié, le plug-in lui-même restant identique. Donc, si vous n'avez pas pu l'installer sur Firefox 4, téléchargez-le à nouveau et réessayez... |
|
|
by Olivier Guillion | | |
| |
|
Nous sommes toujours sur notre problème de plantage de Windows. Apparemment le système n'est pas récupérable mais tous nos fichiers de données sont là. Nous avons réussi a démarrer une version d'Ubuntu sur CD et sommes en train de copier toutes les données sur un disque amovible. Quand ce sera fini, nous essaierons de réinstaller Windows.... Sinon, il y a très peu de retours sur les dernières versions publiées et c'est plutôt positif. Notre intention est de démarrer très vite le chantier de notre nouveau produit : l'intégration de la guitare virtuelle dans Harmony/Melody. Bon week end ! |
|
|
by Didier Guillion | | |
| |
|
|