Les derniers points manquants dans la version d'Acam Winter pour Linux ont tous été pris en compte et terminés, après moultes recherches.
La programmation Linux tient plus de l'alchimie que du processus industriel. Par exemple, la gestion de la molette de la souris sur X passe par un pseudo-appui sur les boutons 4 et 5 de la souris.
Ce n'est expliqué nulle part, commenté nulle part, il faut juste le savoir. C'est pourquoi Linux est une telle "usine à gourous" : le savoir y est empirique, transmis de bouche à oreille, et noyé dans la montagne de sites recopiant le résultat de la commande "man".
Nous avons donc maintenant une version quasi fonctionnelle d'Harmony Assistant sur Acam-Winter Linux.
Les dépendances ont été réduites, il faut voir maintenant si on peut aller plus loin.
Pour mémoire, il y a trois manières d'utiliser un module externe ou système dans une application :
- La plus courante est appelée liaison dynamique ou dépendance. Lors du lancement de l'application, les modules nécessaires sont recherchés dans le système. Ils seront utilisés par l'application. S'ils ne sont pas tous présents, l'application ne se lancera pas.
- La plus sûre est appelée liaison statique. Le module est directement intégré dans l'application, augmentant de ce fait sa taille. C'est la solution à privilégier pour limiter les ennuis, mais ce n'est pas toujours possible.
- Entre les deux, lorsqu'un module n'est pas absolument nécessaire, et lorsque l'application peut se débrouiller sans, il y a le "weak link". La liaison dynamique est effectuée par le programme lui-même après son démarrage. Si le module n'est pas trouvé, l'application continue quand même.
Voici la liste des dépendances d'Harmony Assistant à ce jour.
linux-gate.so.1
libasound.so.2 => /usr/lib/i386-linux-gnu/libasound.so.2
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2
librt.so.1 => /lib/i386-linux-gnu/librt.so.1
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6
libfontconfig.so.1 => /usr/lib/i386-linux-gnu/libfontconfig.so.1
libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6
libm.so.6 => /lib/i386-linux-gnu/libm.so.6
libc.so.6 => /lib/i386-linux-gnu/libc.so.6
/lib/ld-linux.so.2
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1
libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1
libz.so.1 => /lib/i386-linux-gnu/libz.so.1
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6
Et en voici le détail, avec les questions et problèmes que nous nous posons :
linux-gate (Accès à Linux) Trop lié au système pour envisager un passage en statique
libasound (Alsa, gestionnaire sonore) Trop volumineux, complexe et lié au système pour passer en statique
libdl (laison dynamique) D'après certains forums, trop lié au système pour passer en statique
librt (Extensions Temps Réel) Gestions des entrées-sorties, flux, fichiers, etc. D'après certains forums, trop lié au système pour passer en statique
libpthread (Gestion des processus) D'après certains forums, trop lié au système pour passer en statique
libX11 (Système d'interface homme-machine X11) Trop volumineux, complexe et lié au système pour passer en statique
Necessite libfontconfig, libxdcmp
libfontconfig (Fontconfig, gestion des polices) Trop complexe et volumineux pour passer en statique
libfreetype (Freetype, affichage de polices) Trop complexe et volumineux pour passer en statique
libm (bibliothèque mathématique du C) Tentative de passage en statique inopérante, raison indéterminée à ce jour
libc (bibliothèque C standard) Le passage en librairie statique semble déconseillé. À vérifier. Tentative de passage en static inopérante, raison indéterminée à ce jour
ld-linux (chargement dynamique de librairies). Permet les weak links. Vérifier le rapport avec libdl.
libxcb (interface sur le protocole X-Window). Semble être une alternative à Xlib. Pas certain de comprendre qui en a besoin.
necessite libXau
libexpat (XML) lecture de fichier XML. Tentative de passage en statique inopérante, probablement utilisée par une autre lib (fontes, etc)
libz (Zlib) compression ZIP. Tentative de passage en statique inopérante, probablement utilisée par une autre lib (fontes, etc)
libXau (X11 Authorization Protocol) Quelle utilité ?
libXdcmp (X Display Manager Control Protocol) : interactions avec le gestionnaire d'affichage de X Window
La bibliothèque optionnelle libXrender, permettant les pointeurs souris en couleur, est chargée en weak-link, et ne fait fonc pas partie des dépendances.
Voila, il nous reste à trouver des réponses à toutes nos questions sur ces modules.
Mais je crois que ça pourra attendre 2015 
Joyeux réveillon à tous ! |
|
|
| by Olivier Guillion |  |
|
| |
|
Nous avons donc tenté de passer Harmony sous Acam Mac, ceci rappelons-le afin de le rendre indépendant de Carbon et de pouvoir accéder aux nouvelles API Mac OS X.
En première étape, il a fallu recréer un projet en s'inspirant du protocole mis en place pour adapter Myredit puis Melody Player.
Puis, les différents sources C ont été compilés jusqu'à ce qu'il n'y ait plus d'erreur, ensuite il a fallu lier avec la librairie Acam ce qui a produit de nombreux liens irrésolus qui ont été redéfinis dans un source mannequin. Ceci nous a pris plusieurs jours, sans aucun résultat tangible à l'écran.
Mais ce matin, les phases d' initialisation sont passées sans problème et nous avons obtenu ceci :
Maintenant nous attaquons tous les points laissés en suspens.
Les menus ont ensuite été complétés afin de gérer les menus hiérarchiques, les éléments checkés et les images. |
|
|
| by Didier Guillion |  |
| |
|
Avant de pouvoir envisager une version alpha, 4 points doivent encore être réglés dans Acam-Winter :
Les pointeurs de souris non-standards, en couleur
La gestion de la molette de la souris
Des problèmes de clavier : certaines touches de fonctions sont considérées comme restant appuyées lorsqu'elles sont relâchées quand l'application n'est plus à l'avant-plan
Les palettes qui disparaissent lorsque l'application n'est plus à l'avant-plan, ceci n'étant plus nécessaire lorsqu'on a une grande fenêtre "bureau" qui contient les fenêtres de l'application
Nous nous sommes donc attaqués aux pointeurs souris en couleur, et nous sommes rendus compte que ce n'était tout simplement pas possible avec X11.
Pour pouvoir les gérer, il faut utiliser Xrender, ce qui implique une dépendance supplémentaire. Et si nous l'utilisons, ce module semble permettre également l'utilisation de polices de caractères vectorielles et anticrénelées, ce qui fait double emploi avec freetype.
Nous nous posons donc les questions suivantes : est-ce freetype qui utilise Xrender ou le contraire (ou les deux librairies sont-elles totalement indépendantes?). Et si Xrender est à un plus bas niveau et nous permet de nous affranchir de freetype, a-t-on à notre disposition toutes les fonctions dont on a besoin ?
Une fois de plus, tenter de résoudre un problème sous Linux nous amène à nous en poser trois autres, d'où l'impression confuse de pédaler sans avancer. |
|
|
| by Olivier Guillion | |
| |
|
La longue nuit de Noël est là.
Nous vous souhaitons une douce nuit, en famille, au pied du sapin ! |
|
|
| by Didier Guillion | |
| |
|
Bien que présentant tout un bataillon de fonctions encore à écrire, Acam est fonctionnel sur Mac. Dans le futur il faudra essayer de déterminer si les éléments de l'interface peuvent être dessinés via le système : on sait que les utilisateurs Mac n'aiment pas trop les applications qui changent l'aspect de l'interface.
Nous attaquons maintenant le passage d'un gros projet sous Acam : essayons de voir ce que cela donne avec Harmony Assistant par exemple... |
|
|
| by Didier Guillion | |
| |
|
Il y a à peine un peu plus de 20 ans, la toute première version d'Harmony Assistant était diffusée. Déjà disponible à la fois sur Macintosh et PC, elle ressemblait à une version très simplifiée de celle d'aujourd'hui, comme le montre ce diaporama.
Bien sûr, à l'époque, pas de couleurs, pas de sortie numérique, de chanteur Virtuel, de scripts ou même de changement de métrique en cours de morceau. Le programme était livré sur disquette, accompagné d'une "disquette clef" protégée contre la copie que nous fabriquions sur Mac, en nous appuyant sur le fabuleux circuit de gestion du lecteur appelé IWM, pour Integrated Woz(niak) Machine, inégalé à ce jour.
Nous avons tenté, au début, de diffuser l'application par le circuit classique, dans les magasins de musique. Il s'est rapidement avéré que ce circuit était peu adapté aux produits bon marché et aux marges décentes, les revendeurs d'alors préférant vendre des produits très chers avec des marges de 75%. C'était en 1994, avant la démocratisation d'Internet qui devait précipiter la fin de l'âge d'or des points de vente physiques de produits technologiques ...
Si nous remontons au tout début du développement d'Harmony, le point de départ a été une combinaison de deux logiciels que nous avions écrit sur Mac SE pour notre usage propre :
Le premier, BarMan, était une boîte à rythme (BAR) simplifiée. A partir de petits tableaux écrits dans un fichier texte, le programme envoyait les notes en MIDI, faisant jouer les différents instruments de batterie sur un petit expandeur Yamaha. La version 2.0 y ajoutait des notes de basse.
Le deuxième, Solfège, montrait une portée, et une note y apparaissait. Il fallait très rapidement appuyer sur la touche du clavier correspondant à la note. Ceci permettait de s'entrainer à déchiffrer plus rapidement une partition.
Nous avions donc un programme rudimentaire qui jouait sur la MIDI, et un autre qui montrait une portée. Nous nous sommes alors demandé "Et si nous écrivions un éditeur de partition ?". C'était parti...
Dans Harmony Assistant, tout a été réécrit, certaines parties ayant même été entièrement changées plusieurs fois. Aussi, absolument rien n'a été conservé des programmes d'origine sauf une chose : le nom "Solfège" qui, 20 ans plus tard, reste chez nous la dénomination d'Harmony, utilisée pour le développement.
Donc, souhaitons à Harmony Assistant un heureux anniversaire, et profitons-en pour remercier tous les utilisateurs qui, depuis 20 ans, ont contribué sans relâche à son amélioration. |
|
|
| by Olivier Guillion | |
|
| |
|
Le module d'impression commence à fonctionner.
Petit rappel du fonctionnement interne :
Lorsque le programme trace une page du document, les ordres QuickDraw sont collecté dans une zone mémoire. Si l'on sauvegarde cette zone on obtient un fichier image de type PICT.
Cette zone mémoire peut être affiché sur l'écran via un offscreen (une surface en couleur) ou imprimé via le pilote d'impression. Les différents ordres collectés sont dans ce cas interprétés par Acam et transformés en commandes CoreGraphicsqui sont envoyés à l'imprimante.
Il reste maintenant à traiter une à une chacune des commandes QuickDraw et les transformer en commande CoreGraphic.
|
|
|
| by Didier Guillion | |
| |
|
La boîte d'édition des paramètres d'impression est maintenant graphiquement en place et entièrement fonctionnelle sur Winter-Linux :
La boîte d'impression a été également mise en place graphiquement, mais sa gestion n'est pas encore tout à fait finalisée.
Les documents sont correctement imprimés, au travers d'un export EPS puis un envoi par CUPS. On peut donc considérer que l'impression fonctionne.
Nous en avons profité également pour corriger quelques défauts graphiques d'interface dans Winter, ainsi que quelques sources de crash.
Nous savons que beaucoup d'utilisateurs Linux attendent une version plus solide avec impatience. L'objectif est donc maintenant d'obtenir quelque chose de suffisamment complet et stable pour proposer rapidement une version pré-alpha d'un de nos programmes sur Linux.
Pré-alpha, et non alpha, beta ou RC car il ne s'agirait pas là de tester les fonctionnalités de l'application elle-même mais plutôt l'interface graphique et les relations avec le système Linux en général.
Bon week-end à tous ! |
|
|
| by Olivier Guillion | |
|
| |
|
Les courbes de Bezier fonctionnent enfin !
Les fenêtres Cocoa ne peuvent être a la fois dans la liste des fenêtres et invisible. Une ruse a permis de pallier à ceci.
La cartographie brute du clavier a été implémenté (elle permet de déterminer rapidement si une ou plusieurs touches sont enfoncées)
Au passage plein de petites irrégularités ont été corrigées.
Maintenant, nous allons attaquer un gros morceau, l'impression. |
|
|
| by Didier Guillion | |
| |
|
La logique d'impression d'Acam Winter commence à fonctionner. Nous avons pu obtenir la première boîte d'options d'impression sur Linux:
Au bas de la boîte, on trouve les options supplémentaires, dépendantes du type d'imprimante.
Celles-ci, ainsi que la liste des imprimantes disponibles, ont été obtenues par un simple appel caché à la ligne de commande de CUPS (lpstat et lpoptions), ce qui nous évite d'avoir à lier notre projet à une librairie.
|
|
|
| by Olivier Guillion | |
| |
|
Les styles de base des textes (souligné, gras) ont été implémenté en CoreText
Les polices embarquées sont reconnues par le CoreText et correctement affichées.
Nous essayons de faire fonctionner les courbes de Bezier via les entrées graphiques standard, pour l'instant sans succès. |
|
|
| by Didier Guillion | |
| |
|
Nous planchons toujours sur Acam Winter. La structure de l'impression est de plus en plus simplifiée, afin de limiter les fonctions dépendantes du système.
Nous les avons maintenant réduites à 4 ou 5 fonctions seulement, ce qui devrait grandement simplifier l'implémentation sous une nouvelle plateforme, à condition que ce dernier permette d'imprimer facilement des données PostScript.
Bientôt nous aurons quelque chose à montrer, et, si tout va bien, nous devrions pouvoir assez rapidement proposer une beta-version de quelque chose (Harmony, Melody ou notre éditeur de texte de démo) sous Acam Winter / Linux. |
|
|
| by Olivier Guillion | |
| |
|
Pour finir la semaine, les fenêtres de sélection du nom du fichier en lecture et écriture ont été implémentées via un appel Cocoa, elles seront donc au "look" du système.
L'affichage des images a été réécrit pour utiliser des surfaces Quartz ce qui nous rend normalement indépendants de Quicktime :
Enfin, l'affichage des textes qui utilisait la technologie ATSUI se fait maintenant via le CoreText. L'ATSUI comportait des petits bugs jamais corrigés, par exemple certaines polices perdaient leur capacité à s'afficher en gras sans raison valable.
Le CoreText est assez bien fait quoique complexe et semble puissant. D'après Apple il serait deux fois plus rapide que l'ATSUI.
Ce n'est pas encore totalement fonctionnel. Il nous manque par exemple la capacité d'utiliser des polices fournies avec l'application et non installées dans le système.
Bon week-end ! |
|
|
| by Didier Guillion | |
|
| |
|
Nous avons avancé sur l'impression sous ACAM-Winter. Les boîtes de dialogue ne sont pas ergonomiquement en place, mais la logique a été mise en place : l'application peut demander une mise en page, puis imprimer.
Les pages imprimées sont collectées dans un fichier EPS qui est pour l'instant sauvegardé sur disque. Dans la version définitive, ce sera au petit module d'impression système-dépendant (notre cible étant dans un premier temps les plateformes Linux) d'imprimer réellement ce fichier EPS sur papier.
Ce travail sur les fichiers EPS nous a permis de repérer quelques dysfonctionnements, dont la correction améliorera encore la qualité de l'export graphique EPS d'Harmony/Melopy, sur toutes les plateformes.
|
|
|
| by Olivier Guillion | |
| |
|
Les problèmes graphiques ont été corrigés et la fenêtre principale s'affiche maintenant correctement :
L'interface réagit aux clics souris et aux touches clavier.
Les boites de dialogue additionnelles s'ouvrent également :
Elles sont fonctionnelles. L'aspect est bien entendu celui d'Acam et non de Mac OS X puisque nous traçons tout "à la main".
Enfin, cerise sur le gâteau, la musique se joue en utilisant le CoreAudio.
Maintenant, il faut attaquer la gestion des fenêtres standards de sélection de fichier en lecture et écriture.
|
|
|
| by Didier Guillion | |
|
| |
|
Après les sélecteurs de fichiers, les seules boites de dialogue restantes gérées par le système sont les boîtes de sélection d'imprimante et d'impression.
Afin de s'affranchir au maximum des appels au système, nous allons donc gérer ces boîtes nous-même. Et pour éviter les problèmes de traduction, elles fonctionneront avec des icônes plutôt que des textes.
Voici une "vue d'artiste" de ce que pourrait être la boîte de sélection d'imprimante, obtenue par "Fichier > Mise en page" :
On y trouve :
Le choix de l'imprimante
Le choix de la taille du papier
L'orientation (portrait/paysage)
La définition de taille des marges
Le choix de l'échelle d'impression (ou de l'adaptation automatique au papier)
Les boutons d'annulation et de validation
Ensuite, lors de l'impression par "Fichier > Imprimer", une boîte permet de régler d'autres paramètres :
Nous avons :
A nouveau le choix de l'imprimante, pour les changements d'avis de dernière minute
Un bouton permettant de redéfinir les paramètres (accès à la boîte précédente)
Le nombre de copies
Le choix des pages à imprimer
Le choix de l'impression recto/verso
Le choix du sens d'impression (pages croissantes ou décroissantes) ainsi que des pages paires/impaires
Le choix de la division de la page, qui permet d'imprimer plusieurs petites pages sur une même feuille
Les boutons d'annulation et de validation
Il nous faudra ensuite voir si nous n'avons rien oublié, puis réfléchir à l'implémentation sous Linux, qui se fera probablement par un appel caché à la ligne de commande de CUPS.
|
|
|
| by Olivier Guillion | |
| |
|
Les fichiers de configuration et de ressource sont maintenant correctement localisé. La lecture/écriture des fichiers passe maintenant par les entrées standard Unix fopen et fclose. Or sur Mac les fichiers sont divisés en deux parties, le ressource fork et le data fork. La fonction fopen ouvre le data fork. Apple a du ruser méchamment pour permettre d'accéder au ressource fork. Voici l'astuce :
soit xxxx le nom d'un fichier fopen("xxxx","rb") va ouvrir le data fork et fopen("xxxx/..namedfork/rsrc","rb") va ouvrir le ressource fork. Ce n'est pas très élégant mais cela fonctionne.
Nous obtenons donc ceci :
La barre de menu est correctement affichée et gérée.
La fenêtre s'ouvre avec un titre et on peut la déplacer.
Le document musical se charge apparemment correctement.
L'affichage essaie de s'exprimer mais avec beaucoup de mal.
On progresse, on progresse...
|
|
|
| by Didier Guillion | |
| |
|
On y est, enfin ! 
Après quelques versions beta et trois RC, La version 1.5.0 est en cours de mise à disposition sur le site. Elle devrait apparaître d'ici quelques minutes.
Mais, par expérience, et une fois de plus en totale conformité avec la loi de Murphy, il y a de bonnes chances qu'un gros problème non détecté jusqu'ici se soit glissé dans cette version, et que nous devions poster une sous-version très rapidement pour corriger ça.
Quelqu'un veut parier? 
Bon week-end !
|
|
|
| by Olivier Guillion | |
| |
|
Nous avons avancé sur le portage de Melody Player sur Mac OS sans Carbon. L'astuce était de faire croire au Mac OS que notre application est une application Cocoa écrite en Objective-C.
Ce se fait via une petite amorce toute simple dont voici l'intégralité :
Code:
#import <Cocoa/Cocoa.h>
int main(int argc, char *argv[])
{
if(NSApplicationLoad())
{
InitAppFileName(*argv);// Pour le chemin sur les ressources
AcamInitSettings();
[NSBundle loadNibNamed:@"MainMenu" owner:NSApp];
mymain();
}
} |
|
C++ et Objective-C n'étant que des sur-couches au langage C on peut donc au sein d'un même projet, mixer les trois types de langages et appeler les fonctions de l'un à partir d'un autre.
Puis il a fallu lier avec Acam et le minimum de librairies. Nous avons ainsi obtenu un exécutable complet. Il va nous permettre de tester et peaufiner l'implémentation d'Acam sur Mac/OS.
Prochaine étape, gestion des accès aux fichiers et aux chemins.
|
|
|
| by Didier Guillion | |
| |
|
Nous étions en train d'envisager sérieusement de publier la nouvelle version de PDFtoMusic/PDFtoMusic Pro (v 1.5.0) quand nous nous sommes rendu compte d'un problème de calcul sur certains fichiers.
Conformément à la Loi de Murphy, le problème ne survient que sur les versions Windows 95 du programme, et en version publique (non déboguable). On investigue, donc, et la nouvelle version est en standby jusqu'à la résolution de cette bizarrerie. |
|
|
| by Olivier Guillion | |
| |
|
Certains noms de polices embarquées dans le PDF pouvait contenir des caractères entrainant une erreur de l'export en MusicXML, un filtre a été appliqué à ces caractères.
Des barres de ligatures ou de tuplets pouvaient être confondues avec des tenuti, c'est corrigé.
Certains coulés étaient pris pour des tête de note en triangle, c'est corrigé.
|
|
|
| by Didier Guillion | |
| |
|
Depuis sa mise en eau en juillet dernier, les plantes ont pas mal poussé dans notre aquarium
Pour doper un peu l'éclairage faiblard (un tube de 15W) prévu pour ce bac, nous avons bricolé une rampe de leds composé de 240 leds SMD 5050, qui ajoutent 48W de puissance.
S'il le faut, nous envisagerons la réalisation d'un complément à base de led dans la gamme de l'ultra-violet, pour favoriser la pousse des plantes.
Et ce week-end, après une visite à la bourse d'aquariophilie de Montauban, de nouveaux pensionnaires ont fait leur apparition dans le bac :
Une quarantaine de crevettes "Red Cherry" (taille réelle 2cm)
et une douzaine de corydoras pygmées (ce sont des mini-mini poissons), tout mignons avec leur micro-moustache (taille réelle du poisson complet, moustache comprise : 1,5cm grand max)
Il ne reste plus à ce petit monde qu'à s'acclimater. |
|
|
| by Olivier Guillion | |
|
| |
|
|
