Cet été nous avons travaillé dur sur le chantier afin que tout soit prêt pour l'automne. Il a fallut gérer au jour le jour les artisans : maçon, plaquiste, électricien, fenètrier, chauffagiste... Un alpiniste est même venu poser des tuiles à douilles sur le toit, fort pentu. Pour l'instant nous sommes dans notre échéancier, il nous reste une partie de l'électricité à finaliser, l'armoire réseau à poser, l'escalier et la mezzanine à installer qui vont séparer l'espace en deux bureaux, et enfin, le planchéiste qui va poncer et vitrifier les parquets. Nous nous occupons de tout ce qui est plâtre (et il y en a des trous à reboucher !), enduits et peinture. Afin de vous donner une idée, voici une galerie qui reprends les travaux depuis notre première visite du lieu : http://www.myriad-online.com/perso/photos/locauxmyriad/ |
|
|
by Didier Guillion | | |
| |
|
Il y a 23 ans, nous sortions Vega, un jeu pour Commodore 64, avec en musique de fond, la Toccata en Ré mineur de Bach (trrrès original ) entré note à note par Marc Tarrabia dans un programme fait maison. Ce n'était pas encore, à l'époque, des insruments numérisés, mais il y avait le SID, le circuit sonore du Commodore 64, un circuit "analogique" où on réglait les fréquences, les formes d'onde et les paramètres des filtres. Notre programme de composition n'était pas à proprement parler un éditeur de partition, mais plutôt un interpréteur de lignes de commandes, et les fichiers musicaux ressemblaient beaucoup à ce qu'est le format ABC aujourd'hui. Il nous a servi pendant très longtemps, pour créer des musiques pour nos jeux destinées à d'autres ordinateurs que le Commodore 64. Chaque nouvelle machine nécessitait de nouvelles techniques. De la modulation delta sur MO5 (musique à deux voix sur une sortie en tout ou rien), à la gestion du circuit AY 8912 sur Amstrad CPC, ou du Yamaha YM sur Atari ST, il fallait faire preuve de crétivité technique. Par exemple, le circuit de l'Atari n'était pas prévu pour jouer des sons numérisés, c'était un synthétiseur analogique, comme celui du Commodore, mais moins bien. Pourtant, en changeant la valeur du volume de sortie, on entendait la membrane des haut-parleurs changer de position. Et plus le volume était mis fort, plus la membrane était poussée loin. Donc le mouvement de la membrane était dépendant d'une valeur numérique qu'on fixait dans le volume. De là à utiliser cela pour jouer un son numérique, il n'y avait qu'un pas, que nous avons franchi allègrement pour "Sapiens". Et nous en avons profité pour lui faire jouer 4 sons à la fois, en "tâche de fond", une première dans la musique sur cette machine. Gilles Soulet avait composé la musique, et les instruments avaient été enregistrés ici et là avec les moyens du bord. Les bases du module interne de calcul des voix, d'ajout des sons qui est le coeur de la sortie numérique d'Harmony Assistant étaient déjà jetées. C'était il y a tout juste 20 ans. Ensuite, un passage sur l'Amiga avec "Albedo", où nous avons utilisé son fabuleux circuit sonore numérique polyphonique (toujours des musiques de Gilles Soulet). Il a fallu attendre pas mal de temps avant que les cartes sons numériques 8 bits (type SoundBlaster) se démocratisent sur les PCs. Pendant très longtemps, nous n'avons pu compter que sur le haut-parleur interne. Après l'Amiga, c'était une sacrée régression, comme passer d'un orchestre symphonique à un kazoo. Harmony Assistant se profilait déjà à l'horizon, mais n'a donc eu la possibilité de jouer en numérique qu'à partir de sa version 2.0, deux ans après la sortie de la première version. Pour la suite, il suffit de lire l'historique des versions d'Harmony Assistant en partant du bas de la page. C'est assez amusant de voir à quel moment les fonctionnalités principales sont apparues. |
|
|
by Olivier Guillion | | | |
|
Plutôt que d'utiliser un algorithme "générique" de reconnaissance de forme, nous avons décidé d'essayer de développer un algorithme spécifique pour repérer les éléments les plus cruciaux de la partition, c'est-à-dire les têtes de noire et de blanche, les rondes et les pauses. Un premier essai de recherche des têtes de noire par cette méthode donne ceci: Les têtes repérées sont marquées d'un point vert. Il y a encore quelques erreurs, avec un faux positif sur les clés et l'accolade du haut, ainsi qu'un autre dans la ligature du bas. Ceux-ci devraient pouvoir être éliminés en ajustant l'algorithme, ou par la suite lors de la détection de ces éléments (une tête ne peut chevaucher ni une clé, ni une accolade, ni une ligature). A suivre, le repérage des têtes "creuses" (blanches et rondes). |
|
|
by Olivier Guillion | | |
| |
|
Avec la préparation d'Harmony Assistant 9.4, le projet ScanToMusic a quelque peu été délaissé ces derniers temps. Nous avons commencé à nous y remettre ces derniers jours. Nous avions essayé d'appliquer des algorithmes "génériques" de reconnaissance de forme sur les objets de la partition. A l'évidence, cette méthode est très gourmande en temps de calcul, et, même si elle peut donner des résultats, n'est pas vraiment efficace, car elle ne tient pas compte de la logique d'une partition. Par exemple, il n'y a jamais de tête de noire sans tige, ou de tête de note située ailleurs que sur une ligne ou exactement entre deux lignes. Tenter de les détecter ailleurs serait non seulement une perte de temps, mais génèrerait également tout un tas d'erreurs inutiles. Donc avant de commencer la reconnaissance de ces symboles, il faut d'abord extraire très précisément les lignes de portées, calculer les distances entre les lignes, et extraire les lignes verticales. A partir d'une partition de ce type : Nous obtenons ceci : En vert les lignes horizontales détectées, en rouge les verticales. Les extrémités des segments sont en bleu. Les lignes de portée sont bien détectées. Il y a peu d'erreurs (sauf le mélisme de "Ladies chain", qui pourra facilement être éliminé par la suite), et l'accolade qui trompe un peu le programme pour déterminer le début exact des lignes. Mais quand il y a une accolade, il y a généralement une barre verticale qui joint les portées à gauche, et qui permettra d'élaguer ce qui dépasse. Il y a beaucoup plus de "fausses" lignes verticales (dans les clés, les caractères ou les silences), mais pour l'instant cela nous suffit. il est plus facile d'éliminer ce qui a été trouvé à tort que d'inventer une ligne là où le programme ne l'a pas vue. Les lignes de portées nous permettent maintenant de déterminer avec précision la valeur de l'interligne, et donc des symboles (têtes de notes, silences...) qu'on peut s'attendre à trouver dessus. |
|
|
by Olivier Guillion | | |
| |
|
Harmony Assistant peut être utilisé en 8 langues différentes. A chaque nouvelle version, des options apparaissent, et avec elles des menus, boîtes et messages d'alerte. D'autres fonctions sont modifiées et nécessitent de changer un texte, d'ajouter un bouton, etc. Nous traitons nous-même les versions française et anglaise du mieux que nous pouvons, mais devont compter sur l'aide précieuse de quelques utilisateur pour traduire les nouveautés dans les 6 autres langues. Pour que le programme fonctionne, et que n'apparaisse pas une boîte ou un menu vide, nous recopions la version anglaise des nouveaux textes dans chacun des fichiers "ressource" des 6 langues, en marquant ces textes pas encore traduits avec "!!". Puis les textes, anciens et nouveaux, sont envoyés aux différentes personnes qui se sont proposées pour nous aider. C'est assez gros, plusieurs dizaines (centaines?) de pages. Il leur suffit alors de rechercher les "!!" et de traduire les phrases manquantes dans leur langue. Une fois cela fait, il reste la documentation. Et quand je vois une explication longue et détaillée d'une nouvelle fonctionnalité, sur plusieurs pages, je me dis "Aïe ! / Ouch! / ¡Ay! / Ahi / Ai! / Autsch! / Itaï!" |
|
|
by Olivier Guillion | | |
| |
|
Peu de modifications au programme aujourd'hui. La plupart des fonctionnalités mises en place semblent fonctionner correctement. Certaines méritent encore quelques petits ajustements, mais le plus gros est fait. La chasse aux accès illégaux à la mémoire a été faite. Ceci permet de détecter les erreurs de programmation qui touchent à la mémoire "dynamique", c'est-à-dire les zones de mémoire que le programme utilise lorsqu'il en a besoin, et "libère" (les rends à nouveau disponibles aux autres applications) lorsqu'il a fini. Il peut arriver que le programme essaie d'utiliser une zone de mémoire déjà libérée, ou fasse des accès hors de la zone qu'il s'est allouée. Selon ce qui a eu lieu avant, la version du système, ou le manque de bol, cela peut engendrer des "crashes" à l'apparence aléatoire chez les utilisateurs. Nous avons donc à notre disposition un système développé "maison", qui rend le programme très sensible à ces accès non autorisés, et qui produit un crash à chaque fois que ça a lieu. Si le programme passe le test, alors cela veut dire qu'il ne commet aucune irrégularité, et qu'il sera donc "stable" chez tout le monde. Malheureusement, on ne peut jamais être sûrs de tester toutes les options, dans tous les cas possibles. Donc il y a toujours une possibilité de crash, le tout est de la minimiser. |
|
|
by Olivier Guillion | | |
| |
|
Outre des petites corrections mineures, incluant la prise en compte de paroles multiples dans le script "Changer le style des lignes de paroles", nous avons testé la version Windows sur les versions du système à notre disposition. En effet, même si notre système de développement permet une compatibilité accrue, il peut nous arriver d'utiliser sans nous en rendre compte des fonctionnalités du système qui sont apparues sur des versions récentes. Ceci pourrait empêcher nos programmes de fonctionner correctement sur les versions plus anciennes. A titre d'exemple, la gestion des caractères accentués "Unicode" et la rotation de textes ne fonctionnent sur Windows 95/98 que si une librairie supplémentaire (appeleée Unicows) est installée. Donc, régulièrement pendant les sessions de beta, nous retroussons nos manches, et faisons un brin de paléoinformatique. C'est là qu'on se rend compte que Windows 95 démarre très, très vite sur un processeur Core Duo Mais, un peu plus à chaque fois, nous nous demandons combien de temps il nous faudra maintenir la compatibilité de nos programmes avec des systèmes d'exploitation vieux de 10 ou 12 ans ! Plusieurs fois, nous nous sommes dits qu'on pourrait sans problème laisser tomber ces vieux systèmes, qui ne sont plus maintenus par Microsoft lui-même. Mais à chaque fois, un rapide tour d'horizon nous a montré qu'un nombre étonamment élevé d'utilisateurs d'Harmony/Melody les utilisaient encore. Et donc, à chaque fois, l'échéance a été repoussée. Pour combien de temps ? |
|
|
by Olivier Guillion | | |
| |
|
Bon, normalement, nous évitons de faire de la pub pour des sites "marchands" sur ce blog. Mais là, c'est un peu différent. Depuis des années, je fais un tour de temps en temps sur ThinkGeek. Je n'y ai jamais rien acheté, c'est juste pour avoir un aperçu des derniers gadgets loufoques - mais hi-tech - que la technologie moderne est capable de produire. On y trouve de tout, mais alors, vraiment de tout, à commencer par beaucoup d'humour et un solide second degré (voire même troisième ou quatrième), et puis surtout, des choses qu'on n'aurait jamais osé imaginer : de la rampe de missiles de bureau, commandée par le port USB, au T-shirt égaliseur graphique, pendule, ou jeu de tennis sur télé, en passant par le kit Stonehenge. Plus c'est inutile et décalé, et plus ça devient rigoureusement indispensable. |
|
|
by Olivier Guillion | | |
| |
|
Une erreur dans la précision de l'impression rendait les courbes (coulés, liés) crénelés lorsqu'on choisissait "Tout imprimer". Le problème n'était pas présent avec l'option "Imprimer page". Cela a été corrigé, mais nécessitera des tests d'impression plus poussés sur la version beta 6. A noter que pour économiser du papier, il est possible de tester en imprimant sur un fichier PDF. Le problème était également visible dans ce cas-là. Un "lissage" manquant dans les thèmes graphiques Windows a été remis en place. Avec certains thèmes, cela pouvait nuire à l'aspect des barres de titre des fenêtres. Plusieurs problèmes liés à la fusion de deux portées de taille différentes ont été corrigés. Cela pouvait entraîner un mauvais affichage des notes jouées, et des difficultés à saisir les notes à la souris sur ce type de portées. Enfin, un problème d'utilisation de caractères accentués dans les noms des séquences lors de l'import de fichiers styles Yamaha (.sty) a été résolu sur XP, mais il nous avait été signalé également des problèmes spécifiques à Windows 98 lors de cet import. Nous devrons donc le tester sur cette version de Windows. Heureusement, nous avons la possibilité de tester assez facilement nos produits sur Windows 95, 98, 2000, XP et Vista. Cela ne nécessitera donc pas de ressuciter un vieil ordinateur poussiéreux pour faire ce test |
|
|
by Olivier Guillion | | | |
|
Il y a des modules auxquels on croirait ne plus jamais avoir à toucher, tant ils ont été testés et retestés. Parmi ceux-ci, le "coeur" du synthétiseur logiciel d'Harmony Assistant, le module qui génère les signaux audio à partir des sons d'instrument et des notes à jouer. Repris pour la dernière fois un peu après la sortie de la base GOLD 2, en 2005, pour y ajouter un lissage destiné à atténuer les effets du phénomène "d'aliasing", il était considéré comme dénué de tout problème particulier. Or, l'autre jour, j'ai cru déceler des crachotements indésirables dans une musique. En isolant la basse, j'ai obtenu ceci. Vous entendez, le petit claquement à la fin de chaque note? J'ai donc vérifié consciencieusement les échantillons utilisé, les paramètres de relâche, les points de boucle, sans succès. Je me suis alors rendu compte que ce problème était en fait dû à l'utilisation d'un processeur d'effet de type "flanger/chorus". Après recherche de la partie fautive du programme, et correction, on obtient maintenant cela. Plus de craquement, sauf tout à fait à la fin, mais là, c'est dû au fait que j'ai coupé sauvagement le fichier pour que le mp3 ne soit pas trop long. D'accord, c'est assez discret. Mais si cela avait été plus évident, nous nous en serions rendu compte depuis longtemps. |
|
|
by Olivier Guillion | | |
| |
|
Chose promise, chose due... La version beta-5 vient d'être mise à disposition ici. Elle contient toutes les nouveautés, améliorations et changements annoncés sur ce blog au cours des deux derniers mois, ainsi que dans les fils marqués [FAIT] ou [DONE] (selon l'inspiration) dans l'Atelier Démocratique. Nous attendons maintenant les retours des beta-testeurs. Il y a dans cette version beta pas mal de modifications qui nécessitent d'être testées en profondeur, donc nous aurons probablement pas mal de rapport de problème dans les jours qui vont suivre, pour peu que la météo continue à être catastrophique Ne vous inquiétez pas si on ne vous répond pas tout de suite, il nous faut le temps de reproduire, localiser et corriger le problème signalé. Bons tests, et bon week-end, donc |
|
|
by Olivier Guillion | | |
| |
|
Pas mal de corrections de problèmes aujourd'hui (rien de grave, la version de développement courante semble bien stable) et quelques nouveautés : des facilités associées au click droit, en particulier dans l'édition des accompagnements, des transparences sur la règle affichée en mode taquet. Nous cherchons un moyen standard (qui marche sous Windows et Mac/OS) pour afficher également les petites icônes en transparent. Mais pour l'instant sans succès. Si aucun rapport de problème important ne tombe cette nuit, demain nous devrions pouvoir soumettre une nouvelle béta aux testeur |
|
|
by Didier Guillion | | | |
|
La prochaine version beta devrait sortir, si tout va bien, vers la fin de cette semaine. Ont été implémentés, suite à des demandes sur l'Atelier démocratique : - Le menu qui apparaît lorsqu'on fait un clic droit sur la grille d'accord, permettant de choisir rapidement un accord déjà présent dans la grille - la zone de sélection "fine" qui permet de jouer la musique à partir d'un point donné a été rendue plus tolérante. Même si la zone fait plus de 2 ou trois pixels, elle est quand même considérée comme fine. Ensuite, de petits problèmes existants depuis de nombreuses versions ont été corrigés sur l'édition des matrices d'accompagnement en mode page. Enfin, nous finissons de rechercher les endroits où le programme ne tient pas compte des portées visibles dans la vue pour appliquer une action à la zone de sélection. |
|
|
by Olivier Guillion | | |
| |
|
Aujourd'hui, nous avons corrigé quelques problèmes "cosmétiques", comme le coulé en pointillé, dont les points seront maintenant ronds au lieu de carrés, et leur taille et espacement réglés par le paramètre "épaisseur" du coulé. Mais la majeure partie du temps a été consacrée à localiser les endroits où un calcul automatique du sens des tiges était nécessaire, et à tester en profondeur le logiciel, en vue de la sortie de la prochaine version beta. Nous nous sommes également remis dans le bain de l'import/export MusicXML, afin de pouvoir traiter les problèmes qui nous ont été signalés à ce sujet, dans l'ordre décroissant de clarté du rapport. |
|
|
by Olivier Guillion | | | |
|
Après les accroches (ligatures) automatiques, le sens des tiges Certaines opérations, comme l'ajout de demi-tons, le passage à une autre octave, ou le changement de clé, ne modifient pas la position des notes en temps, simplement leur hauteur. Or, un calcul d'accroche automatique passait tout de même, ce qui pouvait altérer les corrections manuelles que l'utilisateur aurait pu effectuer sur la zone. En ce cas, il était donc seulement nécessaire de recalculer le sens des tiges. Mais il apparaît que la fonction "recalculer le sens des tiges", déjà existante dans le programme, ne tient pas compte du fait que la note est déjà présente dans un groupe d'accroche. Par exemple, à partir de ceci : l'ancien algorithme donnait cela : alors que le nouveau donnera : En effet, la deuxième note, même si elle devrait être théoriquement orientée vers le haut, garde le même sens que la précédente, à laquelle elle est accrochée. Une fois que cela sera fonctionnel, il faudra alors appeler le nouveau recalcul des tiges partout où c'est nécessaire, et il y a de grandes chances que nous en oubliions quelques-uns. La prochaine beta-version promet d'être importante ! |
|
|
by Olivier Guillion | | |
| |
|
Grorom, un des béta testeur nous a envoyé un rapport comme nous les aimons : précis, clair et... ardu. Il remettait en question la gestion du mise en forme des coulés dans des cas particuliers. Nous nous somme replongé sur ce module et l'avons largement amélioré. Ce n'est toujours pas parfait, mais ce sera beaucoup mieux. En particulier, les coulés sont automatiquement recalculés lors du décalage de la hauteur des notes ce qui peut entrainer une inversion des tiges. Même recalcul lorsque l'on applique un instrument transpositeur à la portée. A tester dans la prochaine béta. Sinon, ces dernières semaines, les travaux ont bien avancé dans nos nouveaux locaux. Le plaquiste a terminé le plafond et les murs. Le cablage électrique est quasiment terminé. J'ai terminé les joints des murs apparents : C'est un gros travail de patience, surtout en haut d'un échafaudage de 5m, il faut compter deux heures par mètre carré. Sylvie a attaqué la première couche de peinture. Escalier et mezzanine sont en phase de fabrication et devraient être placés mi-septembre. Pour l'instant nous sommes dans nos planning, si tout se passe bien, déménagement en Octobre ! |
|
|
by Didier Guillion | | |
| |
|
Aujourd'hui, nous avons attaqué une modification assez importante, qui demandera des tests intensifs : la refonte de l'algorithme d'accroche automatique. Le but est de faire en sorte que l'accroche automatique ne recalcule les accroches qu'aux environs immédiats de la note qu'on modifie ou qu'on ajoute. Ainsi, les modifications effectuées manuellement sur les accroches, même en mode automatique, seraient moins facilement détruites par les opérations ultérieures. Dit comme ça, ça a l'air simple. Mais chaque opération d'édition, ajout de note, copier/coller, changements de durée, etc, doivent déterminer leur zone d'application. Par exemple, si, en mode non limité à la mesure, on insère ou supprime une note au tout début d'une portée bien remplie, il y a des chances que toutes les notes derrière se décalent, et donc que leurs accroches doivent être recalculées. Par contre, si on colle dans une mesure un ensemble de notes qui fait exactement la même durée, seules les notes de cette mesures devraient voir leur accroche recalculée. De plus, cela fait apparaître de petits problèmes. Par exemple, l'opération "Couper" oubliait de recalculer les accroches. Ce n'était pas très grave auparavant, car la prochaine opération sur la portée recalculait tout. Mais maintenant, peu d'opérations demandent un recalcul total, donc l'erreur d'accroche reste visible beaucoup plus longtemps... La majeure partie de la journée a donc été passée à mettre cela en place. Nous avons également repris l'affichage des effets afin de les rendre tous proportionnels à la taille de la portée. Certains avaient en effet été oubliés. |
|
|
by Olivier Guillion | | |
| |
|
Cette version beta est maintenant en cours depuis deux mois, et il est temps de "stabiliser" tout cela. Concrêtement, cela signifie arrêter un format de fichier stable, qui restera tel quel jusqu'à la sortie de la version publique, et tester en profondeur les nouvelles fonctionnalités qui ont été ajoutées, et les corrections apportées. Parallèlement, il faut commencer à travailler sur les mises à jour des autres programmes, Melody Assistant, le plug-in et le "player", puis s'occuper des documentations dans un maximum de langues. Donc, il n'y aura maintenant plus de gros changement à la structure du programme, et les demandes en cours qui n'ont pas été traitées seront ajoutées à l'Atelier démocratique pour la prochaine version. Seules les corrections de problèmes bloquants ou les modifications simples n'ayant pas d'incidence sur le reste des fonctionnalités du programme seront maintenant traitées. Ainsi, bien sûr, que les signalements d'erreurs qui ne manqueront pas de nous parvenir lorsque la version beta-5 sera disponible (bientôt) |
|
|
by Olivier Guillion | | | |
|
Des problèmes ont été repérés dans la gestion des matrices d'accompagnement et de rythme en mode page. Ces problèmes concernent l'édition, clic, déplacement, suppression, des éléments de matrices et des objets qui peuvent y être associés. Cela date d'assez longtemps, apparemment (certainement de la mise en place du mode page) mais n'avait jamais été signalé. Ce sera quand même corrigé Le placement des changements de clés au milieu d'une mesure vide donnait des résultats étranges : si on cliquait dans la marge gauche de la mesure, cela ajoutait la clé dans cette mesure, comme attendu, mais si on cliquait un peu à droite, vers le milieu de la mesure, cela insérait une clé de taille réduite au début de la mesure suivante. Ce sera également corrigé. Enfin, des erreurs de positionnement liées au nouveau "mode gravure", qui interféraient avec le mode grégorien et les pistes numériques, ont été corrigées. |
|
|
by Olivier Guillion | | | |
|
Le module gérant le déplacement des objets dont la réécriture a été annoncé à l'étape 44 à été couplé avec le module gérant l'affichage des distances entre les objets. Ainsi lorsque l'on déplace un objet on a en direct sa position précise. Ceci devrait faciliter les mises en place. L'affichage des noms des repères sous forme de lettre a été étendu au delà de 26 repères, après "Z" on passe à "AA". Enfin, certaines difficultés d'affichage des poignées des tuplets et de saisie de ceux-ci (particulièrement quand le tuplet était très éloigné de la note) ont été résolues. |
|
|
by Didier Guillion | | |
| |
|
Croyez-vous que les problèmes d'assistance technique, les difficultés de passage aux nouvelles technologies et les soucis de préservation des données sur des supports fiables sont apparus avec l'informatique ? Détrompez-vous, et appréciez cette perle d'humour norvégien. Malheureusement, les sous-titres sont en anglais, donc si vous ne parlez pas norvégien, et ne lisez pas l'anglais, je crains que vous n'ayez besoin d'assistance |
|
|
by Olivier Guillion | | |
| |
|
Un utilisateur de Melody rencontre des problèmes d'entrée du code d'enregistrement sur son PC portable équipé de Windows Vista. Lorsqu'il entre son code, il obtient une alerte "Can't write file" suivi d'un texte lui disant qu'il y a peut-être une erreur ou un manque de place sur son disque dur. Nous soupçonnions un problème de droits d'accès, aussi nous avons aujourd'hui effectué des tests poussés sur Vista : création de comptes (administrateur, standard et invité), installation des versions publiques d'Harmony et de Melody sur les différents comptes, enregistrement des versions... sans rencontrer aucun problème. Lorsque l'installateur est lancé, on obtient bien sûr une série de boîtes d'alerte de Vista disant que ce programme n'est pas signé numériquement, et que de le lancer pourrait avoir des conséquences très graves sur l'état de votre machine, etc, mais si on dit OK, ça s'installe comme il faut. Si le compte d'utilisateur n'est pas "administrateur", le mot de passe est demandé pour pouvoir écrire dans les zones "sensibles", mais tout est alors installé: fonte, programme, préférences... En résumé, nous ne comprenons pas comment cet utilisateur a bien pu recevoir un message pareil, à moins qu'il n'ait vraiment un problème sur son disque dur ? Ou alors, c'est parce que nous utilisons Vista Ultimate, et qu'il a peut-être une autre version ? Donc on sêche. Si quelqu'un a une idée, ou surtout est capable de reproduire les symptômes signalés, qu'il n'hésite pas à se faire connaître |
|
|
by Olivier Guillion | | | |
|
|