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 | |
| |
|
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 | |
| |
|
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 | |
| |
|
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 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 | |
|
| |
|
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 | |
|
| |
|
|
