Nous progressons avec l'aide d'un accordéoniste dans la compréhension de l'instrument. En fait si il y a antagonisme entre la main gauche et la main droite, l'instrumentiste va pouvoir décider de jouer la main gauche de manière staccato de manière à proposer un poussé/tiré compatible.
Pour gérer ceci, on peut maintenant dans Harmony définir la durée des accords main gauche pour l'accordéon.
Correction d'un décalage d'élément dans la selection de la version du fichier pour la sauvegarde.
Enfin, Melody Player a été mis à jour pour accepter le nouveau format de fichier et les nouveautés.
Bon week-end !
|
|
|
| by Didier Guillion |  |
| |
|
Les nouvelles versions d'Harmony Assistant (9.8.1) et Melody Assistant (7.8.1) viennent d'être mises à disposition sur notre site
Les fichiers annexes (documentations, historique des modifications, etc) sont en cours de mise à jour.
Cette version ayant nécessité un nouveau format des fichiers de partition, Melody Player, dans sa version actuelle, ne peut pas lire les fichiers nouvellement créés, il faudra attendre quelques jours que nous sortions la nouvelle version du player.
En attendant, il vous suffit de sauvegarder au format précédent en le spécifiant dans "Configuration > Préférences générales", onglet "Sauve". |
|
|
| by Olivier Guillion |  |
| |
|
On nous contacte régulièrement pour signaler un problème qui en fait n'en est pas un. Lors du calcul des tablatures pour accordéon, la main gauche (celle qui joue les accords) impose le sens tiré ou poussé de l'accordéon. Ce sens impose à son tour les notes que l'on peut jouer à la main droite.
Certaines notes ne sont disponibles qu'en poussé ou qu'en tiré, donc il arrive qu'aucune solution soit trouvée et qu'un "?" s'affiche lors du calcul de la tablature.
Nous avons ajouté une option qui déconnecte le calcul de la main gauche et de la main droite, le résultat ne sera pas réaliste mais sans "?".
Egalement :
On ne pouvait définir les valeurs par défaut de l'effet "Texte", c'est corrigé.
|
|
|
| by Didier Guillion | |
| |
|
- Windows: Le déplacement de notes en sélection discontinue pouvait faire apparaître un bref instant des tiges de notes vertes dans l'angle supérieur gauche de la fenêtre du document
- L'export Myrweb lorsque la vue courante n'était pas la vue générale altérait les paramètres de la vue générale
- Certaines opérations pouvaient faire perdre l'échelle et la position courante de visualisation de la partition. Ces opérations ont été reprises afin de corriger le problème. Cela inclut:
- L'export Myrweb
- L'export MusicXML
- L'export SVG multi-pages
- Le jeu du Karaoké
- Le forçage du nombre de mesures par ligne
- Le changement de tonalité
- L'export graphique depuis l'aperçu avant impression
- L'impression de la partition
- L'impression de la grille d'accords
- L'impression des paroles
- L'impression des cartons d'orgue de barbarie
- L'affichage d'un modèle de portée avec MyrScript
|
|
|
| by Olivier Guillion | |
| |
|
Pour finir la semaine, nous revenons sur le format MusicXML.
En export MusicXML, correction du positionnement des paroles, elles sont maintenant exportées avec les deux systèmes de coordonnées (ligne et position absolue) afin d'offrir un maximum de compatibilité.
Prise en compte des modes de justification dans les paroles en import MusicXML.
Prise en compte de la position verticale de la ligne de parole en import MusicXML.
Lors de l'import, une vérification de la cohérence des informations entre numéro de ligne et position précise est faite. Ceci permet de traiter correctement les fichiers MusicXML qui ont des données de numéro de ligne de parole erronées.
Bon week-end ! |
|
|
| by Didier Guillion | |
| |
|
Si nous avions travaillé seulement sur Windows, nous n'aurions pas eu besoin de trop modifier nos fichiers sources C. Hélas, nos programmes doivent aussi se compiler sur MacOS, et là les choses se gâtent.
Un peu partout depuis les 30 dernières années, nous avons utilisé le type "long" pour désigner les entiers 32 bits. Mais d'après le grand livre du C, la taille en bits de ce type peut varier en fonction de la plateforme sur laquelle on est.
Sur Windows, le "long" reste à 32 bits, même si on compile un programme en mode 64 bits. Sur Macintosh par contre sa taille est doublée, ce qui rend la version 64 bits du programme incompatible avec tous les fichiers que l'application a pu sauvegarder précédemment, et pose des problèmes quasiment insolubles.
Seule solution, cesser d'utiliser ce type, et le remplacer pas le tout nouveau typage du C à nombre de bits définis, en l'occurence int32_t.
Nous avons entamé des essais de remplacement globaux, suivis d'une grosse session de correction du code pour éviter les alertes de compilation (le compilateur dit qu'il peut y avoir un problème, mais ce n'est pas sûr). C'est un travail de forçat.
Nous avons commencé par la seule librairie ACAM (notre socle de compatibilité entre les différents systèmes) et une très très petite application, avec une seule fenêtre et 3 boutons.
Nous avons effectué environ 6000 remplacements dans les 300 fichiers source C, puis avons commencé à traiter une à une les 1200 alertes de compilation afin de les faire disparaître.
Nous en sommes environ à la moitié, et pour l'instant, aucune ne pouvait déboucher sur une véritable erreur. Mais au moins, nous aurons une compilation plus "propre", et cela évitera que les vraies indications de problème se retrouvent noyées dans les alertes inutiles. |
|
|
| by Olivier Guillion | |
| |
|
Nous continuons à explorer l'éventuel passage en 64 bits et recherchons la solution la plus simple et la plus solide.
Sur macOs nous avons compilé et exécuté un petit programme 64 bits en mode "console". Nous avons ensuite converti notre projet de librairie Lua en 64 bits, lié avec le programme de test et invoqué. Cela semble fonctionner.
Deux choix s'offrent maintenant à nous :
- Ne pas toucher à nos sources mais construire un environnement de compilation qui rends nos projets compatibles entre 32 et 64 bits.
- Modifier, via un automate, l'ensemble de nos sources pour les rendre directement compatibles.
Mais dans tous les cas un outil réellement efficace d'analyse de code et de localisation d'éventuel problème de perte de données dans des conversions pointeur/long nous manque encore cruellement.
Les outils d'analyse de Xcode, basés sur Clang ne sont pas assez "intelligents".
|
|
|
| by Didier Guillion | |
| |
|
Cela fait assez longtemps maintenant que les systèmes d'exploitation sont passés en 64 bits.
D'abord Linux, puis Mac OS font maintenant pression sur les développeurs pour que leurs applications soient portées en 64 bits, menaçant d'arrêter à plus ou moins court terme le mode de compatibilité qui permet de continuer à les faire fonctionner.
D'abord, soyons clairs : à moins que l'application gère de très gros volumes de données (vidéo, photographie HD...) son passage 64 bits n'apporte strictement rien, au contraire.
Le code et la place mémoire nécessaire pour les données seront augmentés, la rapidité restera sensiblement identique, et ce ne sera pas plus stable.
Nous avons, ces dernières années, fait quelques tests pour évaluer le travail nécessaire, et c'est un gros, très gros travail. Chaque système semble avoir géré cette transition à sa façon, demandant plus ou moins de travail au développeur. Jusqu'ici le pire est le Macintosh, qui n'a pas hésité à changer la taille du types standard C "long" de 32 à 64 bits, rendant le portage cauchemardesque pour les développeurs ayant utilisé ce type.
Sur Windows, c'est mieux. En une journée de travail, nous sommes presque parvenus à faire apparaitre une fenêtre avec des boutons et une zone de saisie.
Le problème est que nous n'avons pas trouvé moyen de demander au compilateur de nous indiquer les sources potentielles de problème. Nous devons donc compiler, lancer, attendre un crash, et lorsqu'il survient, effectuer les corrections nécessaires et recommencer. Cela peut fonctionner pour un test simple, mais est inenvisageable pour une application comme Harmony Assistant, où il faudrait plusieurs années pour tester tous les cas (si une telle chose est possible)
Donc, nous essayons de trouver un moyen plus sûr et plus rapide d'effectuer un tel portage, qui nous mobiliserait un certain temps, pour aboutir à une application strictement identique, juste un peu plus lente et plus gourmande en mémoire.
Le plus tard sera donc le mieux, et, à l'issue, ce travail ne pourra certainement pas être fourni gratuitement. |
|
|
| by Olivier Guillion | |
| |
|
Amélioration de l'affichage des tablatures pour accordéons : l'affichage des numéro de case dans les accords se fait par ordre croissant.
Changer le doigté d'une tablature guitare ne recalculait pas les diagrammes d'accords de la ligne d'accord.
Correction du numéro de case par défaut dans le menu contextuel des tablatures guitare.
Correction du calcul du diagramme d'accord à partir des doigtés tablature quand on était en notes aigues.
Mise en place d'un mécanisme de nettoyage des diagrammes d'accords générés automatiquement pour correspondre à la tablature.
Correction d'un gros problème (corde incohérente) quand on posait une note sur la portée standard d'une portée avec tablature prioritaire.
|
|
|
| by Didier Guillion | |
| |
|
Une version beta privée d'Harmony Assistant (9.8.1 Beta 1) a été mise en ligne, et ceux qui attendaient cette préversion pour tester des corrections ou nouvelles fonctionnalités qu'ils avaient demandées ont été (ou vont bientôt être) prévenus.
Si vous considérez que vous avez été oublié (c'est possible, et nous sommes alors désolés), envoyez-nous un petit e-mail, nous vous donnerons le lien de téléchargement.
Dans cette version, ces derniers points ont été ajoutés :
- Corrections de problèmes sur l'édition des tablatures, notamment pour guitare et accordéon
- Amélioration graphique des coulés utilisés comme liaison de prolongation : ils évitent maintenant le pointé de la note lorsque c'est nécessaire
Bon week-end ! |
|
|
| by Olivier Guillion | |
| |
|
Essentiellement travail sur le format MusicXML.
Correction du numéro de canal en export MusicXML
Affichage du numéro de canal en association portée/instrument.
Export de la nuance PPPPP en MusicXML
Correction d'un problème d'échelle d'affichage des nuances en import MusicXML
Correction d'un problème de positionnement graphique des temps en MusicXML.
|
|
|
| by Didier Guillion | |
| |
|
Correction d'un problème de changement de durées des notes de la sélection, lorsque la sélection couvrait plusieurs portées, ou une portée fusionnée
Correction d'un problème potentiel d'enregistrement de son pour instrument numérique utilisateur, ou pour une voix RealSinger. Ce problème était apparent sur Macintosh et Linux.
Amélioration: le déplacement d'une note dans un groupe de notes liées entre elles par des "coulés" utilisés comme des liaisons de prolongation déplace maintenant tout le groupe. |
|
|
| by Olivier Guillion | |
| |
|
Nous avons repris à la base la logique du changement de tempo. Maintenant l'utilisateur peut définir le pourcentage à appliquer à l'ensemble des tempi de la partition.
On peut donc ralentir ou accélérer l'exécution d'une manière globale.
Les valeurs courantes et originales sont affichée sur la partition.
Le changement d'une valeur intervient également en direct sur le jeu de la musique. |
|
|
| by Didier Guillion | |
| |
|
Nous poursuivons la transition de nos produits physiques du CD-ROM vers la clé USB.
Après le CD-ROM Myriad, c'est au tour de la base de sons GOLD de subir cette transformation. Dans un premier temps, les trois modes de livraison de la base GOLD (téléchargement, Clé USB ou CD-ROM) cohabiteront, pour probablement aboutir à terme à la disparition pure et simple du CD-ROM.
Le CD-ROM de la base GOLD était un vrai CD, gravé, et pas un CD réinscriptible, ce qui rend sa modification impossible.
Impossible de faire évoluer les installateurs, de corriger des sons de la base ou d'en ajouter, donc.
Avec la clé USB, cela devrait simplifier les procédures.
Seul bémol, il n'existe pas de moyen standard de protéger physiquement une clé USB en écriture, technologie pourtant déjà fonctionnelle sur les disquettes 8" des années 70.
Sur certains systèmes, donc, l'utilisateur risque d'avoir la possibilité de modifier le contenu de la clé, ou même de la reformater. 
Ce sera à lui de faire attention. |
|
|
| by Olivier Guillion | |
| |
|
Un nouveau mode fait son apparition : le mode Marteau. Il permet de cliquer sur des notes de la partition pour les entendre de manière individuelle. Le jeu se fait sur l'instrument associé à la portée et avec la hauteur définie par la clef courante.
Bon week-end ! |
|
|
| by Didier Guillion | |
| |
|
Les ornements de type "coulé" sont en place graphiquement et ergonomiquement. Ce type d'ornement peut être associé aussi bien à une note ou un silence qu'à une clé.
Correction de crash ou de disparition d'icône dans le Dock lors de sa désactivation / réactivation
Correction d'un décalage graphique entre la visualisation de la zone de sélection et sa véritable position sur certaines fenêtres texte, notamment sur les sections présentant des exemples dans la documentation MyrScript
Crash possible lors du chargement de fichiers MP3 contenant des tags ID3 en Unicode
Correction d'un problème de forçage des sorties sonores vers la MIDI lors du jeu de partitions depuis le Juke-box
MyrScript: Corrections de problèmes dans la gestion des informations de date/heure
La base en seconde des valeurs internes de manipulation de date ayant changé, si des valeurs de ce type ont été stockées par un script, elles risquent de ne plus correspondre à la même date (66 ans d'écart)
MyrScript: la fonction permettant de jouer rapidement une série de notes a été améliorée, pour prendre en compte des numéro de demi-ton non entier, autorisant ainsi le jeu de quarts de tons ou de commas |
|
|
| by Olivier Guillion | |
|
| |
|
Notre logiciel de gestion de galeries photo n'a plus évolué depuis maintenant une bonne dizaine d'année. Développé principalement avec AppleScript Studio, un outil d'Apple, il s'est retrouvé bloqué lorsque Apple a décidé de ne pas poursuivre les évolutions de ce produit.
Aujourd'hui nous en ouvrons les sources en opensource, (ou du moins les sources qui ne sont pas trop sensibles).
|
|
|
| by Didier Guillion | |
| |
|
Comme prévu, nous proposons maintenant Sapiens (jeu d'aventure-arcade de la fin des années 80) en projet open-source.
Une page permettant de télécharger l'archive du projet a été créée :
Sapiens Open Source
Sur le forum de discussion, la section qui jusqu'ici était destinée à notre produit open source sur Macintosh "Galerie" a été ouverte aux discussions à propos de Sapiens:
Forum Open Source
Le projet est fourni en l'état, avec quelques petites pièces manquantes. Il faudra certainement aux personnes intéressées un tout petit peu de travail, notamment extraire certaines données qui sont fournies sous la forme d'un fichier ressource Macintosh, avant de pouvoir recompiler le projet et envisager un portage.
Avec un peu de chance, si le principe consistant à partager avec la communauté le travail effectué est respecté, ces petites tâches en amont n'auront besoin d'être réalisées qu'une seule fois. |
|
|
| by Olivier Guillion | |
| |
|
|
