Cela faisait -presque- tout juste un mois que nous n'avions pas posté de nouvelle version beta de nos produits, c'est maintenant chose faite.
Nous espérons secrètement que cette version beta sera la dernière de la série, et que la version publique pourra être diffusée rapidement.
Nous nous attendons cependant à pas mal de retours sur cette beta (si les beta-testeurs ne sont pas trop épuisés) car de gros changements ont été apportés, probablement les dernières améliorations de cette importance apportées au produit avant sa sortie.
Ces changements concernent le copier/coller des notes, qui a été complètement repris, les ajustements des coulés, et pas mal de choses spécifiques au Macintosh, avec un nouvel installateur pour le Myriad Music Plug-in, la première version beta du plug-in QuickLook annoncée sur la page de la beta, et une grosse ruse pour contourner le problème d'impression des lignes verticales (voir billet précédent).
Nous n'espérons donc pas que cette beta soit exempte de problèmes (faut pas rêver, quand même), ni même qu'ils pourront être réglés rapidement, mais seulement qu'ils ne seront pas importants au point de nécessiter une autre beta pour tester convenablement les fonctionnalités.
|
|
|
| by Olivier Guillion |  |
| |
|
Pas mal de petites améliorations ont été apportées au programme aujourd'hui:
- prise en compte des espacements du mode gravure dans les lignes d'accord, et les lignes de paroles sur une mesure vide.
- Meilleure gestion des accroches des notes lorsqu'on lie deux notes entre elles (Edition > Action > Lier)
- Correction d'un problème d'échelle des notes dans les vues
- Toujours dans les vues, la case a cocher "Afficher les tempi" affecte maintenant toutes les portées de la vue, y compris celle où les indications de tempo avaient été écrites.
- Ajout de la possibilité de régler la police de caractères du chiffre des multi-répétitions et multi-silences
- Elimination des caractères invalides dans les paroles des chansons lors de l'export XML (ces caractères empêchaient le fichier XML de se charger correctement par la suite)
- Correction et vérification de l'option "Edition > Ajouter", mise à mal par la nouvelle gestion du copier/coller. Il reste également à vérifier les opérations de copier/coller sur les sélections discontinues (Maj+clic sur les têtes de notes).
Dès que tout cela sera un peu plus stable, une version beta suivra rapidement. |
|
|
| by Olivier Guillion | |
| |
|
Alors que le nouveau copier/coller commence à fonctionner de manière satisfaisante, mais nécessitera des tests assez intenses durant les sessions beta, nous avons repris les algorithmes d'ajustement automatique des coulés.
Des bornes de courbure des coulés ont été introduites, avec des ajustements complexes de ces bornes en fonction de la taille du coulé. En effet, plus le coulé est petit, et plus on peut, proportionnellement, l'incurver.
Nous avons donc mis en place une fonction faisant appel aux technologies les plus avancées, allant de la théorie du chaos aux algorithmes génétiques soumis à un bombardement de neutrons, en passant par les travaux du mathématicien Alfred Louche, ce qui nous permet de certifier ici que tous les ajustements ont été effectués "à la Louche". 
Ca donne par exemple ceci:
Autrement dit, il faudra également bien le tester dans la prochaine beta.
Les interrogations sur la prise en charge des fichiers MusicXML (extension .xml) par le plug-in QuickLook sur Macintosh nous ont conduit à nous pencher sur le format MusicXML 2.0 compressé "officiel" (extension .mxl), et à l'implémenter dans QuickLook ainsi que dans Harmony Assistant. HA devrait donc être capable, dès la prochaine beta, de lire ces fichiers, et peut-être de les écrire.
Pour l'instant, les exemples dans ce format ne sont pas pléthore, mais ç'aurait été bête de passer à coté, sachant que les dernières versions de Sibelius et du Dolet pour Finale gèrent ce format. |
|
|
| by Olivier Guillion | |
|
| |
|
Aujourd'hui, la journée a été passée à travailler sur le nouveau collage de notes, l'opération s'avérant plus complexe que prévu.
Auparavant, comme dans tous les autres logiciels (traitement de texte, etc), une logique informatique simple était établie, et le résultat des opérations de copier/coller dépendait de cette logique. C'était quelque chose du type:
Lors du copier, le contenu de la zone de sélection est copié dans le presse-papier. Lors du coller, la zone de sélection est effacée, puis les données du presse-papier insérées au point de sélection, sans traitement ou ajustement particulier.
Là, nous avons ajouté deux clauses : si les notes de plusieurs portées sont copiées et collées,
- Le synchronisme des notes traitées est préservé
- Le synchronisme du reste des portées est également préservé.
En clair, des notes qui se jouent en même temps et qui sont copiées, se joueront toujours en même temps lorsqu'elles seront collées, et l'opération de collage ne désynchronisera pas le reste de la portée.
Si vous n'aviez utilisé jusqu'ici le copier/coller que sur une seule portée à la fois, ou sur des mesures entières ne contenant pas de fractions de notes liées, vous n'aviez peut-être pas eu besoin d'un nouvel algorithme. 
Les cas possibles sont nombreux, car cela dépend à la fois des figures rythmiques et des positions relatives des notes copiées, mais aussi de celles des notes dans la zone de sélection avant le collage (effacées), ainsi que des notes situées avant et après cette zone de sélection.
Normalement, à l'usage, le fonctionnement ne devrait pas choquer, et les résultats devraient sembler logiques, mais que de travail pour que ça paraisse simple ! |
|
|
| by Olivier Guillion | |
| |
|
Le nouveau copier-coller de notes commence à fonctionner. Reste à régler quelques décalages qui se produisent inopinément, et refaire fonctionner les collages un peu délicats, par exemple sur des portées avec lois, ou entre portées batterie standards et portées batterie en grille.
Un problème déjà signalé a été corrigé : l'aspect des appogiatures sur les tablatures pour Luth baroque. Elles s'affichaient avec des valeurs numériques, elles s'afficheront désormais avec des lettres.
Le format de papier en export graphique ne fonctionnait vraiment pas très bien, et ce depuis plusieurs versions publiques : quand la taille du papier était forcée, l'export graphique était influencé. Ceci a été corrigé.
M Coquerel, gagnant du 18eme Concours a répondu à quelques questions. Son entretien est disponible sur le site
Merci à lui de nous laisser découvrir son cheminement créatif...
Enfin, les premières soumissions au 19ème Concours ont été publiées ici
|
|
|
| by Olivier Guillion | |
| |
|
Aujourd'hui, première journée de travail de cette nouvelle année, nous avons corrigé tout un tas de petites choses signalées par des utilisateurs, allant de l'export graphique aux tablatures pour banjo.
Quelques personnes nous ont joint des fichiers qui nous laissent assez perplexes.
Par exemple, un des fichiers contenait une partition sans aucun instrument. Théoriquement, supprimer tous les instruments est impossible, à moins d'utiliser un script pour faire cela. Mais là, ce serait du vice...
Un autre fichier qui nous pose problème est un fichier ETF (finale) qui semblerait montrer que nous n'avons rien compris à la manière dont la métrique est stockée dans ce format. Au lieu de trouver un couple de paramètres à 1 / 3072 pour signifier un 3/4, on trouve 114/114, 115/115, et autres couples de ce type (qui donnent, sous HA, la signature 128/64). Ce n'est qu'à partir de la mesure 40 qu'on trouve enfin les valeurs attendues.
Et pourtant, Finale l'importe sans problème et montre bien du 3/4. Nous avons dû rater quelque chose quelque part...  |
|
|
| by Olivier Guillion | |
|
| |
|
|
