Lorsqu'on pose une note avec certains ornements, ceux-ci se positionnent afin d'éviter de chevaucher les lignes de portées. Cette partie a été améliorée sur plusieurs points : Certains effets (marcato, piqué) ne pouvaient pas être positionnés exactement entre deux lignes de portées. Cela a été amélioré, mais pourra changer très légèrement la position de ces ornements par rapport à l'ancienne version. Généralement, le déplacement sera inférieur au plus petit décalage qu'aurait pu imposer l'utilisateur. Le changement le plus important concernera les piqués, relativement peu utilisés. À des échelles de visualisation faible, certains ornements apparaissaient décalés par rapport à leur véritable position (celle de l'impression). Ceci a été amélioré. Un décalage dû à l'imprécision du pixel peut cependant être encore observé dans certains cas. La position par défaut du marcato était trop proche de la note. Il en sera éloigné, comme le montre cette image (en haut, le positionnement automatique de l'ancienne version, en bas celui de la nouvelle). Le positionnement lors du chargement d'anciens fichiers ne sera pas affecté. |
|
|
by Olivier Guillion | | |
| |
|
La nouvelle gestion des pistes numériques, et de manière générale de la sortie numérique d'Harmony/Melody est maintenant fonctionnelle. Nous avons, au fur et à mesure de nos travaux, tenté de noter dans un "cahier de recettes" tout ce qui, dans le programme, risque d'avoir été affecté et qui doit être testé en profondeur. Mais la liste est devenue rapidement si longue qu'il faudra sans doute plusieurs heures (jours?) pour effectuer tous ces tests. En l'état, des pistes numériques de formats différents (taux d'échantillonnage, nombre de bits par échantillon) cohabitent dans le programme, peuvent être jouées ensemble, et des données peuvent librement être copiées de l'une à l'autre. Seuls bémols, outres les petits bugs qui seront corrigés lors des tests : Il est possible de définir un son stéréo composé de deux pistes (voix droite/gauche) de format différent. Cependant, ces deux pistes ne pourront alors pas être éditées ensemble par Bouton droit - Editer. Le travail pour faire fonctionner la boîte d'édition était bien trop grand en regard du faible nombre de fois où le cas se posera Maintenant, les pistes numériques ne sont plus nécessairement en 44 kHz / 16 bits mais peuvent être constituées d'échantillons allant de de 11kHz / 8 bits à 96 kHz/ 32 bits. Les fonctions MyrScript de manipulation des pistes numériques ne sont pas prévues pour une telle disparité de formats. Nous ne savons pas encore si nous pourrons conserver une compatibilité avec anciens scripts utilisant ces fonctions. Les échantillons sonores qui composent les sons utilisateurs devraient également pouvoir bénéficier de l'amélioration de la qualité. Cette partie n'a pas encore été reprise (et ce n'est pas de la petite bière). Il faut que l'utilisateur puisse choisir le format des échantillons qu'il enregistre avec son microphone (ou l'entrée ligne de sa carte son). Là aussi, il doit pouvoir aller jusqu'à 96kHz/32 bits Bon week-end ! |
|
|
by Olivier Guillion | | | |
|
Pas grand-chose à monter aujourd'hui. Nous sommes en pleine refonte des pistes numériques, le programme ne se compile pour l'instant plus, mais nous sommes passés de 350 erreurs à seulement 40. C'est donc la dernière ligne droite, mais notre travail se trouve compliqué par le maintien de la compatibilité avec les Macintosh à base de processeurs PowerPC (et pas Intel). En effet, sur ces processeurs, le format de stockage des valeurs entières en mémoire n'est pas ordonné de la même façon que sur les processeurs Intel. C'est ce qu'on appelle en anglais l'endianness (big endian / little endian) ou en bon français le gros-boutien / petit-boutien (tiens-le bien!) Chaque fois qu'une valeur d'échantillon sonore 16 bits, 24 bits ou 32 bits est stockée en mémoire, il nous faut prendre en compte l'endianness, et souvent écrire une fonction différente pour les deux types de processeur. Pour le PowerPC, nous travaillons quasiment en aveugle. En effet, depuis l'abandon de Roseta, l'émulateur PowerPC de MacOS par Apple, il nous est de plus en plus difficile de tester la version PowerPC d'Harmony/Melody. Et si elle ne fonctionne pas bien, les corrections deviennent un véritable cauchemar. Ceci devrait nous amener rapidement à bien réfléchir, encore une fois, à la nécessité de maintenir la compatibilité avec le PowerPC. Cela fait maintenant plus de 10 ans que ce type de processeur n'est plus utilisé par Apple, mais au prix des Macs, on comprend que certains hésitent à s'en séparer |
|
|
by Olivier Guillion | | |
| |
|
Nous avançons dans la reprise des sorties audio pour les rendre compatibles avec les échantillons 24 et 32 bits. Pour des raisons de rapidité (n'oublions pas que les premiers sons numériques dans Harmony Assistant datent du millénaire précédent), tous les calculs se faisaient sur des valeurs entières, en 32 bits. Il n'est plus possible d'effectuer les calculs internes en 32 bits si le résultat final est lui aussi en 32 bits. En effet, dans l'arithmétique entière, il faut que les résultats intermédiaires des calculs puissent dépasser l'étendue des opérandes. Pour les moins matheux, prenons un exemple. Imaginons que vous ne puissiez compter que jusqu'à 100, et que vous ne puissiez gérer que des valeurs entières. Si vous voulez, à un moment, prendre les 3/4 de la valeur 83 (qui devrait donner 62), qu'allez-vous faire? Si vous multipliez par 3 puis divisez par 4, vous allez faire 80 x 3 = 240, ce qui dépasse 100 et n'est donc pas possible. Si vous divisez d'abord par 4, vous obtenez la valeur entière 20. Si vous la multipliez ensuite par 3, vous obtenez 60. C'est un peu mieux, mais vous perdez de la précision. Devant cette impasse, et considérant que les ordinateurs ont suffisamment évolué depuis les années 2000 pour pouvoir effectuer rapidement les calculs arithmétiques à virgule, nous réécrivons la totalité des opérations internes (génération des sons, effets, mixage, filtrage, etc) en arithmétique à virgule, pour ne revenir en valeurs entières de 32 bits qu'à la fin de chacune de ces opérations. Ceci nous permet de momentanément dépasser les 32 bits pendant les calculs. Mais cela nécessite de réécrire la quasi-totalité des fonctions de calcul, puis de les vérifier en comparant avec le son produit par la version publique du programme. C'est long, et cela s'ajoutera à la liste des choses à vérifier en détail dans la prochaine beta. |
|
|
by Olivier Guillion | | | |
|
Aujourd'hui, démarrage de gros travaux de restructuration pour permettre les sorties numériques au-delà de 16 bits (24 ou 32). Cela nécessite de modifier à peu près tout. Nous avions prévu que les calculs internes se fassent à une précision juste supérieure à 16 bits (18 bits) , qui ne suffira plus si on passe au-delà. Il faut donc reprendre le calcul des sons d'instruments de la base de son, des instruments MyrSynth, VST, Virtual Singer et plus généralement des pistes numériques, ces dernières pouvant également être stockées dans n'importe lequel de ces formats. C'est un beau chantier, qui rend notre version de développement programme inutilisable pendant un petit moment. En parallèle, nous avons géré les jauges quadriphoniques dans les deux tables de mixage (ici représentées côte à côte). Les deux jauges de la stéréo se découpent alors en 4 : Reste à ajouter un bouton par instrument, pour régler directement la position du son avant/arrière. A ce sujet, pour la position gauche-droite nous avons utilisé le terme "stéréo", mais nous n'avons pas trouvé de terme court et clair pour la position avant-arriière. Le plus proche est le "fader", terme utilisé dans les auto-radios. Mais beurk. |
|
|
by Olivier Guillion | | | |
|
Le cadre des objets textes liés à la portée ne supportait pas bien la rotation. Ceci a été corrigé Le script "Montrer le nom des notes" a été amélioré (meilleur calage des noms dans les têtes de notes, prise en compte de toutes les notes de la sélection, réduction des longueurs de tiges) Un test permettant d'entendre la configuration des haut-parleurs (stéréo, quadriphonie, 5.1, 7.1 ...) a été mis en place |
|
|
by Olivier Guillion | | | |
|
Nous avons mis en place "l'orientation inverse des coulés lors de l'écriture sur une portée fusionnée dans laquelle le sens des tiges des notes est imposé". Avec un libellé pareil, ça promet, pour la doc Dans certains cas, l'utilisation d'une réverbération très forte pouvait produire des coupures dans le son, ou des crachotements. Nous avons amélioré cela en pré-filtrant les données numériques de la réverbération avec un "filtre anti-bias". Il y avait des problèmes d'affichage des numéros de mesure, et de la barre de jonction des portées, lorsqu'un repère était posé en début de ligne, sur une portée non imprimée (car vide). Ceci a été corrigé. On nous a également signalé un problème d'affichage des accolades et de crochet joignant les groupes de portées, mais nous n'avons pas réussi à le reproduire. Nous attendons de recevoir un fichier le mettant en évidence De nouvelles commandes de texte permettent d'entourer le texte dans un cercle, ou d'inverser le contraste des textes encadrés ou encerclés. Cela peut donner quelque chose comme : Cela sera principalement utile pour les repères. Melody Player a été recompilé, et des problèmes d'affichage lors de l'utilisation de partitions protégées ont été corrigés. C'est tout pour aujourd'hui, et cela clôture la semaine. Bon week-end à tous ! |
|
|
by Olivier Guillion | | |
| |
|
Roeland, notre courageux et opiniâtre traducteur en néerlandais, s'est attaqué à la documentation de PDFtoMusic / Pro. En relisant cette documentation, il a détecté de nombreuses disparités entre les options proposées dans le logiciel et leur explication dans le manuel. Il nous a donc fait parvenir un e-mail d'une dizaine de pages de demandes de clarification sur chacune de ces différences. Nous les reprenons une à une, corrigeons la documentation pour l'accorder avec le programme, puis renvoyons ces modifications à Roeland pour qu'il puisse les traduire en néerlandais. Donc, non seulement la prochaine version de la documentation de PDFtoMusic devrait être disponible en néerlandais, mais elle sera également beaucoup plus à jour, dans toutes les langues |
|
|
by Olivier Guillion | | | |
|
Une partition d'un utilisateur nous a laissé de longues heures dans la perplexité la plus totale. Il était parvenu à fabriquer des appoggiatures de silences, et même de silences fantômes, accrochées à un silence ! À tel point qu'Harmony jetait l'éponge et préférait crasher plutôt que d'essayer de comprendre de quoi il s'agissait. Nous avons finalement pu le reproduire en créant des appoggiatures sur une note, puis en cliquant sur cette note avec le bouton droit et en la changeant en silence. Ce sera donc corrigé dans la prochaine version. Jusqu'ici, en mode de pose de note, lorsqu'on passait sur l'extrémité d'un coulé, on pouvait la cliquer pour la déplacer. Mais cela empêchait de poser facilement certaines notes en accord, lorsqu'elles étaient proches du coulé. Cette possibilité a donc été supprimée, et la priorité d'action laissée à la pose de note. Un utilisateur nous a demandé que les coulés soit orientés du coté des tiges dès lors que la direction des tiges est imposée globalement pour la portée : Sur cette portée, les tiges sont toutes forcées vers le haut. Pour l'instant, un coulé apparaît comme (A). Faudrait-il le faire apparaître comme (B) ? Ceci permettrait une meilleure gestion automatique de l'orientation des coulés dans les portées multi-voix, mais nous devons d'abord réfléchir, et nous assurer que l'utilisateur n'a pas d'autres raisons d'imposer le sens des tiges. |
|
|
by Olivier Guillion | | |
| |
|
|