Bug report : when using clef, the spacing is changed by the software between closing the file and opening it!
Hello to the whole team!
And first of all, sincere congratulations for all your work, your efficiency, and the quality of the software you offer us; I'm a composer, and it's a pleasure to work with MuseScore every day!
I'm here to report a bug that's not serious at all, but sometimes very annoying!
I noticed that as soon as I use a clef within a measure, the spacing is systematically modified between the moment I save and close my file, and the moment I reopen it.
This is sometimes very annoying when you've aligned certain other elements (text, expressions, various markings) and everything is changed.
I think this is probably a refresh that happens while editing but shouldn't be performed as soon as the file is opened... so if you could take a look at this, that would be great!
So sorry for my English, I'm French! ;)
Musically Yours,
Vincent A. Jockin
Composer
| Attachment | Size |
|---|---|
| musescore-bug-report.gif | 47.07 KB |
Comments
Bonjour,
"So sorry for my English, I'm French! ;)"
Dommage, vous vous êtes embêté pour rien: vous êtes sur le forum français de musescore. 😉
Le GIF montre un symptôme, mais pour en connaître la cause (cela ne me parle pas, de suite), nous avons besoin de tester votre fichier .mscz.
Si le comportement est le même en sélectionnant simplement les 5 mesures affichées (pas sûr?), joignez uniquement ces 5 mesures (via menu Fichier / Enregistrer la sélection).
Sinon, le score en son entier. Mais puisque vous composez, je suppose que cela va constituer un frein important pour vous. Sachez néanmoins que vous pouvez retirer de suite la partition du forum dès qu'elle sera prise en charge par l'un d'entre nous.
In reply to Bonjour, "So sorry for my… by cadiz1
Funny though that I see this post regardless only looking at en and de forums
In reply to Funny though that I see this… by Jojo-Schmitz
Indeed, I was surprised myself to read .org/en in the address bar. There is definitely for the past few days an access issue with the sub-forums (and forums), as you reported on GitHub.
In reply to Indeed, I was surprised … by cadiz1
I've seen this happening before, occasionally.
In reply to Bonjour, "So sorry for my… by cadiz1
Bonjour,
Merci bcp pour votre réponse...
Je vous joins ici le fichier MSCZ et l’export PDF ; vous pourrez observer l'espacement correct sur l’export PDF, et l’espacement "par défaut" (avant toute manipulation, à l’ouverture du fichier) sur le fichier MuseScore...
En espérant que vous puissiez faire remonter ce petit bug vraiment pas grave (mais il pourrait être le symptôme de qq chose de plus profond, c’est pour ça qu’il faut toujours faire remonter les infos de façon la plus claire possible)... Et puis j’avoue que c’est le genre de petits défauts contrariants, surtout quand on est perfectionniste et qu’on voudrait que les choses ne bougent plus une fois la partition achevée...
Encore mille mercis pour votre patience !
Bien musicalement,
Vincent
Fichier MuseScore : bug-report-spacing.mscz
Partition PDF : bug-report-spacing.pdf
In reply to Bonjour, Merci bcp pour… by Vincent A. Jockin
Une capture d'écran du fichier .mscz
![mscz.png]( "mscz.png")
![pdf.png]( "pdf.png")
Et celle du fichier .pdf
Pourriez-vous préciser où se situe le problème exactement, car là, pour l'instant, cela ne me saute pas aux yeux.
In reply to Une capture d'écran du… by cadiz1
Observez bien l’espace entre avant la clef de fa ou avant la clef de sol (même problématique) !
Certes, cela peut paraître anodin... mais le seul hic, c’est que dès qu’on touche à une note dans une mesure ou ce genre de problématique est présente, toutes les autres mesures du même système se réarrangent en fonction ; et c’est très pénible de penser que la mise en page ne bougera plus d’un iota alors même qu’elle ne fait que changer et donne un sentiment de qq chose d’instable, et surtout d’incohérent !
Si encore il y avait un moyen de bloquer tout espacement automatique sur une mesure (ou un système) ; si on pouvait dire à MuseScore, "voilà, cette mesure tu n’y touches plus", cela résoudrait en partie le problème... mais je ne crois pas que ce soit possible, voire souhaitable... il faudrait tout simplement que l’espacement ne bouge plus entre le moment où on quitte la partition et le moment où on y revient... car à partir du moment où on ne rajoute ni altération ni nouvel élément, je ne vois pas pourquoi cela changerait ! Et ce n’est pas encore le cas à ce stade, la preuve : le fichier n’est pas comme nous l’avons laissé ! ;)
Merci pour votre patience...
In reply to Observez bien l’espace entre… by Vincent A. Jockin
"c’est très pénible de penser que la mise en page ne bougera plus d’un iota alors même qu’elle ne fait que changer et donne un sentiment de qq chose d’instable, et surtout d’incohérent !"
Mon avis: oubliez de vouloir faire de la mise en page au fur et à mesure de la saisie de votre partition. Au fil de l'ajout des notes, des nuances, et foule d'autres choses, le programme s'adapte, recalcule les choses. A la fin de la saisie de la partition, procédez alors à la mise en page finale, et lorsque vous en êtes satisfait, utilisez des verrous de système (le moyen pour "Si encore il y avait un moyen de bloquer tout espacement automatique sur une mesure (ou un système)", là où souhaité, à chaque fin de système, pourquoi pas, et là, ça ne bougera plus, du tout.
In reply to "c’est très pénible de… by cadiz1
Évidemment, tant qu’on modifie des éléments, il est normal que ces derniers soient pris en compte et que les espacements changent en fonction. Mais le problème n’est pas là. Dans le cas qui nous occupe, justement, on ne modifie RIEN ! On sauvegarde un fichier avec certains espaces et on ouvre le même fichier avec des espaces différents ; ce n’est pas normal... je n’ai rien fait entre temps ; le code informatique ne peut pas dépendre du temps qui fait ou de ce que j’ai mangé le midi (ça c’est pour faire une citation de Kaamelott) !
Bien entendu, j’avais essayé le verrouillage système qui ne produit hélas aucun effet (et c’est bien dommage) !
Mais merci quand même. MuseScore est absolument formidable... et c’est vraiment dommage de ne pas tenir compte de ces petits rapports de bug qui feraient (me semble-t-il) toute la différence. Et cela met en exergue un manque d’exigence fort regrettable.
Faut-il que je passe directement à Dorico ? où j’ai qd même un maigre espoir que l’info remonte ? lol
Bonne soirée à vous
In reply to Évidemment, tant qu’on… by Vincent A. Jockin
" On sauvegarde un fichier avec certains espaces et on ouvre le même fichier avec des espaces différents"
Pour tout vous dire, j'aimerais voir un fichier complet démontrant cela.
L'info commence à circuler sur les forums, puis lorsque le bug semble avéré (et s'il n'est pas déjà signalé, ce qui en semble être le cas, mais il y a un tel flux en ce moment, en pleine préparation de la 4.6 qu'il est quasiment impossible de tout suivre), il part vers Github: https://github.com/musescore/MuseScore/issues
Ce sera une solution, rassurez-vous. Mais j'ai vu passer et pu tester plusieurs centaines de bugs (milliers plutôt...) , et j'aimerais bien comprendre le "vôtre" avant de le déposer sur Github. Pour l'instant, il m'échappe. D'où ma curiosité de voir un fichier le démontrant. Et parce que aussi et surtout, pour qu'un bug soit rectifié, il faut, première chose, mais absolument essentielle, pouvoir le reproduire à la commande sur un tout nouveau fichier, étape par étape.
In reply to " On sauvegarde un fichier… by cadiz1
En attendant: testez votre partition avec la version alpha de la future 4.6, et dites-nous si vous observez toujours la même chose. Ici: https://musescore.org/en/node/382028
Ou mieux encore, avec la toute dernière nightly: https://musescore.org/en/nightly-builds
In reply to " On sauvegarde un fichier… by cadiz1
Je comprends et je vous remercie...
Si vous voulez constater "mon problème" par votre propre expérience :
![bug-report-ms-spacing.png]()
1/ Ouvrez un nouveau fichier et choisissez une portée de piano (faisons simple) !
2/ Dans "Paramètres de la page" mettre la "Hauteur d’interligne de portée (sp)" à 1,000mm
3/ Écrivez ces qq mesures (la musique est idiote, c’est simplement pour qu’on se comprenne et qu’on parle de la même chose) :
4/ Sélectionnez les deux clefs de sol ; et dans "Apparence" mettez leur "Espace de début" à 0.5 (pas indispensable pour observer le bug, cela le rend simplement plus flagrant).
5/ Fermez votre fichier (pas besoin de quitter MuseScore).
6/ Ouvrez à nouveau votre fichier et l’espacement n’est plus comme il était en quittant ! Pour le recouvrer (et je ne sais pas pourquoi) il faut par exemple sélectionner le f (nuance forte) et le déplacer d’une note (shift + flêche horizontale) puis le remettre à sa position, et là, comme par magie, l’espacement revient et ne bougera plus ! Enfin, jusqu’à ce qu’on sauve et qu’on ouvre à nouveau le fichier... ad vitam aeternam ! C’est vraiment étrange... et très honnêtement, pas normal.
J’espère sincèrement que tout ceci vous permettra de mieux appréhender "mon problème".
Trois remarques (si je peux me permettre) :
1/ Le problème ce produit particulièrement lorsqu’on met des changements de clefs ; cela dit, je l’ai également observé avec simplement qq altérations, voire avec rien d’autres que des notes (mais il faut bien dire que les changements d’espacements sont bien plus minimes, plus difficilement observables, mais présents qd même).
2/ Il est fort possible qu’un calcul (ou la prise en compte d’un élément) soit oublié à l’ouverture de la partition ; après le premier changement, l’espacement de bougera plus jamais...
3/ Si je laisse une "Hauteur d’interligne de portée (sp)" à 1,750mm (valeur par défaut), le bug n’apparaît plus ; il y a probablement un calcul d’espacement qui ne tient pas compte de cette valeur ou qui ne prend pas en compte la modification de cette valeur.
Dans notre exemple (et pourquoi, je ne sais pas) à partir d’une hauteur d’interligne de 1,400mm le bug disparaît ! Pour moi, cela vient forcément d’une mauvaise prise en compte de cette valeur dans le calcul de l'espacement... mais il y a bien un problème, et dans les grosses partitions d’ensemble, on travaille avec une hauteur d’interligne bien souvent sous 1,000mm ; on est donc assuré d’avoir constamment ce bug !
Dernière info : ma config est iMac macOS Ventura 13.7.7
Encore merci pour votre patience.
Bien musicalement,
Vincent
In reply to Je comprends et je vous… by Vincent A. Jockin
Ok, merci, mais faisons les choses dans l'ordre si vous le voulez bien. Commencez par tester votre ou vos fichiers comme dit avec la version alpha, et une nightly, la dernière en date, puis dites-nous si vous observez le même comportement, ou pas? Il est fort possible que cela ait été rectifié : on va approcher les 700 "commits = enregistrements de modifications dans le code, pour cette seule version 4.6. Impossible de tout vérifier et de vous le dire ce jour.
Si ce n'est pas le cas, j'essaierai de le reproduire et, en cas de confirmation, il sera temps alors de le déposer sur Github.
In reply to Ok, mais faisons les choses… by cadiz1
Ok. Mais, la version Alpha va-t-elle supprimer ma version 4.5.2 actuelle, ou je peux faire cohabiter les deux ?
(config macOs 13.7.7)
In reply to Ok. Mais, la version Alpha… by Vincent A. Jockin
Non, aucun risque. Vous pouvez installer parallèlement la version Alpha (qui apparaîtra sous le nom "MuseScore4 Testing") de même que les Nigthlies, à votre actuelle 4.5.2. Elles cohabiteront en toute quiétude.
Veillez à une chose cependant. Evitez d'enregistrer votre fichier avec l'alpha (4.6) sous peine très probablement de ne pas pouvoir le rouvrir avec la 4.5.2. Mais comme la version finale 4.6 va arriver dans ce mois, le risque est très mince. Ou pensez simplement à renommer votre fichier de suite en l'ouvrant avec la version Alpha, ou faites-en une copie (Menu Fichier / Enregistrer - Autre commandes /Enregistrer une copie)
In reply to Non, aucun risque. Vous… by cadiz1
Grand merci ! Sincèrement.
Et je vous dirai si le problème persiste...
In reply to Non, aucun risque. Vous… by cadiz1
Hélas... bug persistant sur les deux nouvelles versions Alpha & Nightly (celle du 04.09.25) !
Je pense donc que ce petit bug n’a jamais été remonté...
N’hésitez pas à le tester chez vous ! Normalement, vous devriez constater le même désagrément...
Encore merci pour vos explications et votre ténacité ; vous avez raison de vouloir vous assurer de la véracité d’un bug avant de le faire remonter et je comprends très bien votre démarche. Aucun problème.
Bien à vous,
In reply to Hélas... bug persistant sur… by Vincent A. Jockin
Pour l'instant, ce que je constate, à partir de votre premier fichier .mscz, c'est que l'Espace de début est bien conservé après enregistrement/réouverture du fichier.
Sur votre fichier, je note toutefois des différences, outre l'Espace de début, il y a un Décalage horizontal, qui n'a pas le même effet bien entendu. C'est intentionnel?
Sur la première clef, on a ceci (0,5 / - 0,5) :
Et la deuxième clef (0 / -1) :
In reply to Pour l'instant, ce que je… by cadiz1
Et si je fais -0,5 partout (Espace de début et décalage horizontal à l'identique pour les deux clefs), mes valeurs - 0,5 n'ont pas bougé après réouverture du fichier. Serais-je en train de louper quelque chose?
In reply to Et si je fais -0,5 partout … by cadiz1
Le mieux serait de réaliser le même exercice que j’ai décrit dans mon message de ce jour (4 septembre) à 7:44.
Au moins, nous parlerons de la même chose...
Je suis parti d’un fichier vierge. Si vous suivez les instructions, vous observerez très certainement le bug dont il est question. Tenez moi au courant !
Autres précisions (relatives à vos derniers messages) : entendons nous bien, les valeurs d’espacement ne sont pas modifiées (celles de l’onglet "Apparences") ; ce sont les espaces dans leur affichage qui diffèrent entre le moment où nous clôturons le fichier et le moment où nous l’ouvrons à nouveau...
Merci beaucoup pour votre sollicitude.
In reply to Le mieux serait de réaliser… by Vincent A. Jockin
"Le mieux serait de réaliser le même exercice que j’ai décrit dans mon message de ce jour"
Et bien, c'est que j'avais déjà fait. Fichier créé pour piano, à l'échelle, et modification de l'Espace de début (0,5) des deux clefs mesures 2 et 3 première portée. J'enregistre, rouvre: l'espace de début est identique, voir: test piano.mscz
"ce sont les espaces dans leur affichage qui diffèrent entre le moment où nous clôturons le fichier et le moment où nous l’ouvrons à nouveau..."
C'est ce que je ne vois pas, ou pas encore (parce que vous, vous connaissez par coeur votre fichier, vous y travaillez depuis longtemps, pas moi...)
In reply to "Le mieux serait de réaliser… by cadiz1
En mettant la Hauteur d’interligne à 1,000mm ?
In reply to En mettant la Hauteur d… by Vincent A. Jockin
Oui, quand je parle d'échelle, c'est la même chose.
In reply to Oui, quand je parle d… by cadiz1
Je vous fait une vidéo... j’ai l’impression de devenir fou ! Je ne fais rien de spécial et il n’y a pas de raison que ce bug n’arrive que sur ma machine.
In reply to Je vous fait une vidéo... j… by Vincent A. Jockin
"Je vous fais une vidéo... "
Ok, à partir du fichier que j'ai créé et joint plus haut ("test piano.mscz") svp. Pour que nous puissions comparer si besoin avec nos machines.
In reply to "Je vous fait une vidéo... "… by cadiz1
J’ai fait la vidéo à partir de votre fichier ; et le bug est bien persistant...
https://we.tl/t-xco2X4HhOm
Constatez par vous-même et tenez moi au courant...
Bien à vous,
In reply to J’ai fait la vidéo à partir… by Vincent A. Jockin
Après avoir cliqué sur le forte ("f"), faites-vous une autre action, ou pas?
In reply to Après avoir cliqué sur le f,… by cadiz1
Absolument rien, comme vous le montre la vidéo... on ne change absolument rien... à tel point que le fichier n'est pas considéré comme modifié ! il s’agit bien d’un rafraîchissement qui n’est pas lancé au démarrage... cela me semble évident maintenant, ou bien que ce calcul ne prend pas en compte la bonne valeur de la hauteur d’interligne (puisqu’à partir de 1,400mm — dans notre exemple — le bug disparaît)...
Il me semble que l'exemple est suffisamment spécifique pour permettre d’identifier le problème au niveau du code !
In reply to Absolument rien, comme vous… by Vincent A. Jockin
Note : ma vidéo est enregistrée en temps réel !
In reply to Note : ma vidéo est… by Vincent A. Jockin
J'ai pris mon Mac, cliqué sur le "forte", attendu quelques secondes pourtant... et rien ne se passe, rien ne bouge chez moi.
In reply to J'ai pourtant pris mon Mac,… by cadiz1
Alors : sélectionnez le, et appuyez simplement sur la touche SHIFT ! Et dites moi si qq chose se passe ? ou non...
In reply to Alors : sélectionnez le, et… by Vincent A. Jockin
Dans ce cas oui. Mais vous me disiez que vous ne faisiez rien d'autre que sélectionner le f?
In reply to Dans ce cas oui. Mais vous… by cadiz1
Ah désolé... je pensais rien d’autre comme modification... pardon !
C’est le seul moyen pour que le rafraîchissement ait lieu... et c’est un vrai problème !
Imaginez une partition avec des dizaines de changements de clefs... il faudrait aller sur chaque mesure incluant des clefs et faire cette opération pour recouvrer les espacements tels qu’ils étaient à la fermeture du fichier... impensable ! Il faut prendre qu’ils soient correctement calculés dès l’ouverture...
J’espère que c’est enfin plus clair !
In reply to Ah désolé... je pensais rien… by Vincent A. Jockin
Vous partez sur une hypothèse, de problème de rafraîchissement que je ne comprends pas. Il commence à se faire tard. Bonne fin de soirée.
EDIT (avant de me préparer à tomber dans les bras de Morphée...): En quoi la touche Shift a quelque chose à voir avec le rafraîchissement d'une page? Dans un navigateur web, le rafraîchissement "normal" c'est F5 ou Ctrl Ou Shift +F5
MuseScore n’a pas de « rafraîchissement de page » au sens web. Par contre, Shift est souvent utilisé pour étendre une sélection (par ex. Shift + clic, Shift + flèche), mais n’est pas associé à un "rafraîchissement" visuel du score.
In reply to Vous partez sur une… by cadiz1
Bonjour,
Déjà, mettons nous d’accord sur le terme de “rafraîchissement”.
Ce terme est utilisé en informatique depuis bien avant la création du Web et signifie simplement : renouvèlement de l’affichage des éléments présents sur un écran pour en actualiser le contenu.
En informatique, dès qu’on code un programme qui réalise des affichages, on doit prévoir des procédures de rafraîchissement.
Afin d’être le plus rigoureux possible, j’ai synthétiser le problème par un bref schéma :
![musescore-bug-report.png]()
Normalement, en informatique la phase d’initialisation (I) en plus d’autres processus (souvent appelés uniquement au démarrage), inclus le processus de rafraîchissement (R).
Or ici, pour une raison restant à ce jour inconnue, on remarque que ce n’est pas le cas ! Il faut (par exemple) sélectionner une nuance (dans la mesure concernée) puis presser la touche SHIFT pour lancer le rafraîchissement (R). Mais il s’agit là d’un exemple, je pense que beaucoup d’autres actions vont lancer ce rafraîchissement ; rafraîchissement qui aurait dû être appelé lors de l’initialisation (I).
Sans cette action notre fichier après l’ouverture (S0) n’est pas identique à la situation (Sn), celle que nous avions en quittant la partition précédemment. C’est bien le problème. Or le fichier (dès la nouvelle ouverture) devrait être exactement le même qu’avant la fermeture précédente. Cela me semble même la base, surtout en informatique...
Alors pourquoi ? Nul n’est sait rien (hormis les codeurs qui verront tout de suite de quoi il s’agit), mais c’est bien factuel.
Pour tout vous dire, je pense même profondément que ce bug est réparable en qq minutes, car bien déterminé ; il n’a simplement pas été identifié à ce jour...
Je vous donne maintenant un exemple concret de désagrément. Imaginons. Je viens de travailler toute une journée sur une partition. Il est tard, j’enregistre et quitte MuseScore. Le lendemain, j’ouvre ma partition et lance une impression... la partition ne sera pas imprimée telle que je l’avais laissée la veille (et c’est un exemple de désagrément parmi tant d’autres).
Enfin, autre chose de très important pour les codeurs (s’il advenait que ce bug manifeste soit remonté). Il y a visiblement un lien avec la valeur de ”Hauteur d’interligne” dans la prise en compte du rafraîchissement à l’initialisation. Selon cette valeur, le bug est présent... ou non !
Je ne pense pas pouvoir être plus précis, plus factuel et plus rigoureux. J’ai beaucoup de travail en ce moment, notamment sur MuseScore, et j’ai volontiers perdu tout ce temps car j’aime l’esprit de l’Open Source, et cette possibilité qu’a chacun de contribuer à son modeste niveau. Mais j‘espère sincèrement que tous ces efforts n’auront pas été vains...
Bien musicalement,
Vincent A. Jockin
compositeur
In reply to Bonjour, Déjà, mettons nous… by Vincent A. Jockin
Bonjour,
Il est temps de vous rendre sur Github: https://github.com/musescore/MuseScore/issues
Au préalable, vous devrez simplement ouvrir un compte (mail, mot de passe)
Surtout pas de grandes tirades, soyez le plus synthétique possible, pas plus de 4-5 étapes décrivant les conditions de ce qu'il advient. Joignez video (le format MOV est accepté de suite de mémoire), et fichier .mscz (en revanche, vous devrez le zipper).
In reply to Bonjour, Il est temps de… by cadiz1
Merci à vous !