Répétitions jamais exécutées
Dans une partition multi section chaque section est sensée être une entité indépendante. Si une section utilse un renvoi par D.S. ou D.C. plus aucunes répétitions par barres de reprises ou D.S. ou D.C. ne fonctionnent dans les sections suivantes. C'est étrange car les répétions non éxécutée"s après D.S. et D.C. étaient un défaut majeur des versions 0.9.x de MuseScore et corrigé avec les versions 1.x. C'est donc une forte régression...
Commentaires
Les sections n'existaient pas dans la version 1.x, pas de regression de ce côté là. J'imagine qu'on peut discuter du fait que les sections soient indépendantes concernant les reprises. Aujourd'hui il est possible de les rendre indépendante en changeant les noms des sauts et de marqueurs ou de ne pas le faire, si on veut faire répéter des sections, on a donc le meilleur des deux mondes.
Pour la non exécution des reprises après un DC, c'est toujours le cas dans 2.0 et c'est une tradition musicale dont on a déjà parlé il me semble. Le fait que les répétitions ne soient pas jouées dans une coda est un bug corrigé pour la version 2.0.1 à venir #52511: Musescore 2.0 resolves DC al coda before repeat bars. #35006: Jumps ignored after first jump. #52511: Musescore 2.0 resolves DC al coda before repeat bars.
En réponse à Les sections n'existaient pas par [DELETED] 5
Je me suis peut-être mal exprimé... il ne s'agit pas de reprises interconnectés ( reprises effectuées entre sections ) mais bien de reprises propres à la section qui ne fonctionnent pas si cette section suit une section qui a utilisé dans son corps un renvoi par D.S. ou ses variantes et ceci qu'on change le nom des sauts et des marqueurs ou pas ( je laisse ici le D.C. de côté puisqu'il fait revenir en début de 1ère section ce qui peut se justifier si les sections ne sont pas totalement indépendantes l'une de l'autre ceci demandant à être bien précisé ).
Quand aux barres de reprises non rejouées après un D.C. ( ou D.S. ) cette tradition n'est qu'américaine... et ne semble n'avoir qu'une trentaine d'années mais peu importe : ce que je vois c'est que ce qui marchait avec 1.3 ne fonctionne plus avec 2.0 ( et dans 1.3 les noms des sauts et des marqueurs y sont bien différents donc 2.0 ne devrait pas s'y tromper ). Autre problème : dans 1.3, deux D.S. al coda pouvaient pointer un même signe segno et avoir chacun un to coda et coda différent ( et ça marchait ) il suffisait de le préciser dans les leurs propriétés et d'indiquer sur la partition "To Coda 1", "To Coda 2", "Coda 1", "Coda 2" pour que ce soit clair pour l'exécutant, ceci ne semble plus possible.
Le test joint a été rédigé sous 1.3. Comme son nom l'indique les reprises y sont complexes ( et les barres de reprises sont rejouées quand le renvoi est fait par un saut nommé différemment mais c'était peut-être un bug puisque pas dans l'optique de la programmation ).
Ce test ne fonctionne absolument plus avec 2.0 ( seul le 1er D.S. al coda est exécuté ), j'aurais admis que les barres reprises ne soient pas rejouées par le second D.S. mais tout le reste devrait marcher y compris le D.C. al fine.
Maintenant est-ce que je sois sous Vista à une influence sur le fonctionnement de
2.0 ?
En réponse à Je me suis peut-être mal par Miré
Oups... alerte! Je reçois un crash avec le fichier joint (Reprises complexes) en lançant la lecture (bouton Play) à partir de la dernière Nightly 08149c9.
Fonctionne normalement avec la 2.0.
La correction des bugs cités plus haut serait-elle en cause ou pas?
Je laisse le soin à lasconic de rédiger le rapport si besoin.
EDIT: "La correction des bugs cités plus haut serait-elle en cause ou pas?" Bien possible en effet. En tout cas, tout est normal jusqu'à cette Nightly du 14 avril: 5ef66ca
Et ça se gâte (crash, lent... mais tout de même) sur la suivante: feafcc2
En réponse à Oups... alerte! Je reçois un par cadiz1
Bon, je m'apprêtais à rédiger le rapport (le Segno semblait impliqué, mesure 6, et aussi le DS al Coda c mesure 28: en supprimant l'un ou l'autre, la lecture démarrait normalement)
Sur ce, je m'aperçois qu'en supprimant simplement ce DS al Coda c, puis en le remplaçant à partir de la palette "Reprises" (et en éditant pour ajouter la lettre "c"), eh bien, tout va bien...!
Du coup, je ne comprends plus trop ce qui se passe.
Le DS al Coda c "original" était dans le style "Texte de la reprise" (je remets le fichier qui "coince"): 0Reprises complexes 2_0.mscz
Après l'avoir remplacé (via la palette), il est dans le style " Texte de reprise de droite". Et la, ça roule. C'est un simple constat. Les reprises et moi, ça fait deux (ou disons que c'est une préoccupation mineure... pour moi), mais dans ce cas, c'est "prise de tête" assurée!
2Reprises complexes 2_0.mscz
En réponse à Bon, je m'apprêtais à rédiger par cadiz1
Je ne vois aucune différence... le premier D.S. al coda b est parfaitement exécuté. En revanche les barres de reprises ne sont pas jouées ( bug), le second D.S. al coda c est ignoré ainsi que le D.C.
Au passage : "texte de reprise de droite/de gauche" ne serait-ce pas plutôt "à droite" et "à gauche" qu'il vaudrait mieux lire ?
Mais je vois dans l'inspecteur les 2 "To Coda" être "personnalisés" au lieu de "aller à la coda" dans "type de repère". C'est logique puisqu'ils sont renommés mais la cerise sur le gâteau c'est que si je remet le nom par défaut ( aller à la coda ) j'ai la surprise de voir le premier D.S. superbement ignoré, les barres de reprises jouées( enfin ), avec une curiosité : la barre de reprise fermante, après les 2 itérations de reprises demandées, renvoye le curseur sur le Coda b ( alors que le D.S. n'a pas été exécuté ), rejoue les 2 itérations par barres, ignore le deuxième D.S. et ensuite exécute le D.C. al fine... C'est-y pas beau cette pagaye :))
Le fichier joint est à lire avec 2.0 pas avec une nightly afin de parler de la même chose.
En réponse à Je ne vois aucune par Miré
Effectivement, nous ne parlons de la même chose. Pour ma part, je relève un crash en ouvrant ton fichier mode Lecture avec la dernière Nightly. C'est le genre de "souci" qui n'est jamais anodin. Et que je tente de comprendre pour que d'autres utilisateurs n'aient pas à le subir lors de la prochaine mise à jour.
De ton côté, tu sembles toujours obnubilé (ça n'est pas un reproche!) par ces questions de reprise.
Une petite question qui me trotte dans la tête depuis un moment: quelle utilisation "majoritaire" as-tu de MuseScore pour vouloir ainsi résoudre des "parcours" sonores peu communs (en tout cas, d'après ma perception)?
En réponse à Effectivement, nous ne par cadiz1
Rédiger des partitions est ma préoccupation principale et je rédige, en ce moment, des recueils de musiques régionnales... les reprises, si elles marchent : c'est bien, sinon du moment qu'on peut les écrire... ça me suffit... devrait me suffire plutôt.
Car ceci rejoint ta question sur les parcours sonores peu commun : les documents que je compulse ( certains ) sont parfaitement incompréhensibles dans leurs articulations si on n'écoute pas le rendu sonore. En effet les cahiers manuscrits très anciens, rédigés par des amateurs pas forcément avertis et aujourd'hui décédés depuis lurette, sont bourrés d'approximations et surtout une partition complète tient sur un 1/2 feuillet et donc les reprises y sont sont nombreuses, imbriquéeset pas toujours clairement indiquées . Je n'ai pas toujours une source sonore fiable pour en comprendre le déroulement c'est là que MuseScore fait son entrée : en rédigeant la partition et en l'écoutant j'arrive à la comprendre. Avec 1.3 il était rare que je n'arrive pas à en reproduire le shéma ( un seul échec à ce jour à cause des endings limités à 2 et de bug de to coda ) et a normaliser et simplifier ensuite. Avec 2.0 je me heurte à un mur... qui m'oblige à travailler d'abord avec 1.3 et ensuite transférer dans 2.0 ( avec à la clé des surprises parfois désagréables comme des mesures déglinguées ). Bref si je pouvait user directement de 2.0 ça m'arrangerais.
Ceci étant dit j'admet que je pousse parfois MuseScore à la limite de ses possibilités mais le crash que tu as "vécu" et le changement de comportement en changeant le nom du type de repère ( chose un peu surprenante avoue-le ) font parti de ces disfonctionnement qu'on ne trouve que par hasard ou si on "fouine"...
En réponse à Rédiger des partitions est ma par Miré
Ok, démarche bien comprise. C'est une sorte de collectage, mais via des documents écrits (manuscrits).
Les "mesures déglinguées" ont été remises d'aplomb, tu le sais, probablement?
Il n'y a aucun hasard dans le fait d'ouvrir un fichier, de lancer la lecture, et de tomber sur un crash. C'est un constat, ni plus ni moins.
Je ne dirais pas "fouiner", mais une fois le dysfonctionnement avéré, "traquer" le bug (et pourtant, je n'ai absolument rien de "l'âme" d'un chasseur dans la vie courante...), pour, à force d'essais et de tests, resserrer les mailles du filet, pour finalement débusquer le "coupable" et reproduire à volonté ses effets néfastes dans deux-trois mesures seulement. Mon tableau de chasse est bien fourni...!
En réponse à Ok, démarche bien comprise. par cadiz1
Je viens de faire des tests avec la dernière nightly ( a757b42 ). Celà rejoint ce que je disais à propos du changement de comportement quand on modifie les noms des repères.
Avant de lancer la lecture il suffit de renommer les sauts à leurs noms par défaut.
Dans mon fichier, on voit via l'inspecteur, que les 2 D.S. al Coda sont marqués : "Jouer jusqu'à : codax/coday" respectivement. Il suffit de supprimer le x et le y des mots coda et ça ne crashe plus.
Pour les répétitions çà ne marche pas mieux pour autant mais l'important est que modifier le nom de la direction ( alors que le repère est bien nommé ainsi ) déclenche le plantage.
Modifier le nom des repères n'a apparemment pas d'influence.
J'ai joins mon fichier modifié comme précisé plus haut. Normalement il ne doit pas planter. Si tu peux me le confirmer ;)
En réponse à Je viens de faire des tests par Miré
"Dans mon fichier, on voit via l'inspecteur, que les 2 D.S. al Coda sont marqués : "Jouer jusqu'à : codax/coday" respectivement. Il suffit de supprimer le x et le y des mots coda et ça ne crashe plus."
Intéressant, mais apparemment, il y a d'autres facteurs plus déterminants encore qui rentrent aussi en ligne de compte.
Je confirme, oui, que ce fichier "modifié" ne plante pas.
A partir de "l'enseignement" de ton fichier (je l'ai réduit à quatre mesures "essentielles"), j'ai pu reproduire le plantage à partir d'un nouveau fichier créé dans une récente Nigthly. J'ai envoyé le rapport, fourni le lien de ce fil, et indiqué le jour (14 avril) à partir duquel ça plante. #56951: Starting playback with repeats in a certain order causes a crash
On ne peut pas faire plus.
En réponse à "Dans mon fichier, on voit par cadiz1
Compris !!! en supprimant juste le y de "Jouer jusqu'à" du "D.S. al Coda c" ce dernier est ignoré par MuseScore ( inexistant pour lui ) car il ne sait pas où il faut aller et le fichier ne plante pas car tu as vu juste : un D.S. placé après le Coda entraîne le plantage. En revanche le D.C. n'est pas exécuté. Si on supprime carrément le D.S al coda c et ses repères. les autres répétitions fonctionnent normalement y compris le D.C.
Moralité : la manière de nommer les repères n'influe pas sur la stabilité, c'est juste ce D.S. placé après le coda qui perturbe MuseScore et le fait planter.