Nous avons été avertis, lors de la sortie de Vista, de problèmes d'installation de nos produits sur certains ordinateurs tournant sous ce système. Cela avait fait l'objet dans ce blog d'un billet en novembre 2007.
Depuis, nous avons collecté plus de renseignements sur ce problème, et dénoué l'histoire complète, ou presque.
Dans un vieil article en anglais du magazine en ligne Technet de Microsoft, l'auteur nous apprend que dès les premières versions de Windows 95, la méthode correcte permettant à un programme de connaître l'emplacement où loger, par exemple, ses fichiers de préférences, avait été établie : il faut appeler la fonction système SHGetSpecialFolderLocation.
Cependant, pour des raisons de compatibilité transitoire avec quelques programmes réalisés avec les versions beta de Windows 95, il était également possible de lire ces valeurs dans la base de registre, à l'emplacement :
HKEY_LOCAL_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
Non sans une certaine ironie, l'auteur de l'article explique que, plutôt que de lire la documentation comme tout bon programmeur est censé le faire, beaucoup d'auteurs de logiciels ont choisi la facilité, en recherchant les informations directement dans la base de registre, utilisant donc la méthode "non recommandée". C'est ce que nous avons également fait. Probablement la flemme de rechercher l'information dans les 15000 pages de documentation développeur en ligne de chez Microsoft, d'autant plus que sans connaître le nom ou même l'existence de la fonction "recommandée", que rechercher ?
Pour couronner le tout, sur le site même de Microsoft, on trouve des références à ces clés de registre, sans aucune mention de la fonction officielle à appeler à la place.
Jusqu'à Windows XP inclus, les clés de registre étaient mises à jour régulièrement (à chaque appel de la fonction officielle) afin de refléter les valeurs correctes.
Donc, si par hasard les clés de registre étaient inconsidérément modifiées par un programme, elles revenaient à la valeur correcte dès qu'un appel était fait par quelqu'un à la bonne fonction.
Nous n'avons jamais noté de problème particulier d'installation jusqu'alors.
Mais voila qu'est arrivé Vista, dans lequel ce mécanisme de mise à jour des clés a été supprimé. Et voila-t-y pas qu'un programme -nous n'avons pas encore pu déterminer duquel il s'agit - écrit des valeurs non valables dans ces clés ?
Un nom d'utilisateur "ReleaseEngineer.MACROVISION" apparaît alors en lieu et place du nom de l'utilisateur courant de Vista dans les chemins d'accès. Et lorsque le programme essaie d'ouvrir ce chemin pour y stocker ses informations, le système le lui refuse et retourne une erreur.
Résultat : sur les machines sur lesquelles ce programme a tourné, nos logiciels ne s'installent plus.
Les programmeurs fainéants sont nombreux, puisque, apparemment, Azureus, MSTag, East-Tec Eraser, Copernic Agent, Eagle Tree Data Logger, et j'en passe, mais sans oublier... Microsoft Outlook ou Microsoft Office 2000 rencontrent les mêmes problèmes.
Nous avons donc modifié nos installateurs pour leur faire utiliser la bonne méthode, et les nouvelles versions s'installeront sans problème. Mais tous nos programmes plus anciens risquent de ne pas pouvoir s'installer, et notamment la base GOLD, qui est gravée en dur sur CD-ROM, et donc non modifiable.
La seule solution que nous avons trouvée, c'est que les installateurs des nouvelles version de nos produits en profitent pour corriger ces entrées erronées de la base de registre. Cela ne leur apportera rien, à ces nouvelles versions, car elles n'en ont pas besoin, mais cela permettra une installation ultérieure correcte du CD GOLD, ou même d'Azureus 
Conclusion, si vous avez des problèmes d'installation de programmes sur Vista, installez l'un de nos produits. Le médicament est à l'intérieur !  |
|
|
| by Olivier Guillion |  |
| |
|
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 | |
|
| |
|
|
