Question:
Algorithme de transposition d'accords entre les touches
Jonathan Potter
2015-12-07 01:35:10 UTC
view on stackexchange narkive permalink

J'écris un logiciel qui transpose des partitions entre les touches et je suis encore nouveau en théorie musicale, donc j'espérais que quelqu'un qui en sait plus pourrait me faire savoir si mon approche est correcte. Voici mon processus pour chaque note:

  1. Trouvez le degré du nom de la lettre de la note dans l'échelle de la clé actuelle.
  2. Trouvez le nombre de demi-tons relevés ou abaissés de la note. la note réelle dans l'échelle. J'appellerai cela le décalage.
  3. Trouvez la note dans l'échelle de la nouvelle clé qui est du même degré.
  4. Augmentez ou diminuez la nouvelle note par le décalage.

Voici un exemple. Supposons que nous transposions la note E # de Do majeur en Ré majeur. Ensuite, nous ferions les étapes ci-dessus comme suit:

  1. E # serait le troisième degré de l'échelle.
  2. Le décalage serait de +1 car E est en fait le troisième degré de la gamme C majeur, et E # est un demi-ton au-dessus.
  3. Le troisième degré de la gamme D majeur est F # donc c'est la nouvelle note.
  4. En ajoutant notre décalage +1 à cela le ferait F ##.

Donc F ## est le résultat de la transposition de Mi # de Do majeur en Ré majeur. Je me rends compte que vous n'auriez pas normalement un E # dans la clé de do majeur mais je pense que c'est possible et cela fonctionne pour expliquer l'algorithme.

Cet algorithme est-il correct? Dois-je aborder cela différemment?

Une question secondaire: est-il nécessaire de connaître le mode des clés lors de l'exécution de ce type d'algorithme? Les résultats semblent les mêmes que j'utilise des échelles majeures ou mineures pour les calculs de degré / décalage. Merci d'avance!


Mise à jour: Solution

Il semble que l'algorithme ci-dessus soit correct, mais peut être simplifié. La pièce du puzzle qui me manquait était que vous pouvez déterminer l'intervalle sans vous référer à l'échelle. Voici l'algorithme mis à jour. Les étapes 1 et 2 trouvent l'intervalle entre la clé actuelle et la nouvelle clé. Les étapes 3 et 4 appliquent ce même intervalle à la note que nous transposons.

  1. Trouvez la distance entre le nom de la lettre de la clé actuelle et le nom de la lettre de la nouvelle clé dans la liste de toutes les lettres (non compris les dièses ou les bémols): A, B, C, D, E, F, G.
  2. Trouvez la distance en demi-tons entre la clé actuelle et la nouvelle clé.
  3. La lettre de la nouvelle note sera la distance de la lettre (étape 1) au-dessus de la note actuelle.
  4. Ajouter dièses ou plats à la lettre de la nouvelle note jusqu'à ce que ce soit le nombre correct de demi-tons (de l'étape 2) au-dessus de la note actuelle.

En répétant l'exemple d'origine, nous aurons:

  1. D est 1 lettre au-dessus de C
  2. D est 2 demi-tons au-dessus de C
  3. La nouvelle lettre sera 1 lettre au-dessus de E #, qui est F
  4. La nouvelle note sera 2 demi-tons au-dessus de E #, qui est F ##

Merci à tous ceux qui ont répondu, et en particulier à @MattL et @Dom. Toutes les réponses et commentaires ont été très instructifs!

J'avais l'intention de modifier ma réponse une fois que j'aurais reçu une réponse, mais c'est peut-être une meilleure façon de procéder. Maintenant Jonathan, supposons que vous vouliez transposer de do mineur en sol # mineur. La note d'entrée est un si naturel. La note de sortie est donc Fx (F ##). Quelles sont les étapes logiques? Nous avons C + 4 est G, et G # est 8 demi-tons à partir de C. Donc nous savons que nous avons besoin de la note 8 demi-tons à partir de B naturel, et nous savons que nous devons l'appeler un F.Quelles sont les étapes logiques pour déterminer que c'est un double pointu, par opposition à, disons, un plat? ...
... Je demande parce qu'il semble y en avoir un peu plus que les étapes de mon algorithme suggéré (ci-dessous) qui utilise l'idée de Caleb. Mais je peux me tromper, alors peut-être devrions-nous examiner les deux.
Autres choses que votre solution doit aborder: que faites-vous si vous trouvez un Cx dans un morceau de C que vous transposez en F #? Cette note devrait être F ###, et les triples dièses ne sont pas autorisés. Il faudrait plutôt lire G #.
Je vous recommande d'écrire votre algorithme - quelle langue utilisez-vous? - puis postez sur SO pour voir si les gens peuvent recommander la refactorisation pour la vitesse. Il existe de nombreuses façons d'exécuter une table de consultation, qui est essentiellement ce que vous écrivez ici. - Oh, et attention aux enharmoniques, car l'interprète préférerait probablement ne pas avoir une tonne de triples bémols :-)
@CarlWitthoft Merci pour la suggestion, mais cette question concerne l'exactitude, pas l'efficacité. J'ai les compétences en programmation pour l'optimiser moi-même; Je n'ai simplement pas les connaissances en théorie musicale pour savoir que je produis des résultats corrects. Si vous souhaitez que je le dise dans la question, je peux l'ajouter.
Je pense que l'algorithme que vous avez choisi comme réponse est correct dans la mesure où il disparaît. Cependant, je vous suggère de prendre les scénarios de test que j'ai suggérés et de les analyser. Je pense que vous constaterez que quand il sera nécessaire de décider quelle note enharmonique sélectionner, votre algorithme deviendra assez lourd. (Si vous ne connaissez pas le terme «notes enharmoniques», ce sont deux notes de même hauteur qui sont écrites différemment, comme A # et Gb.)
Je serai intéressé de voir votre code lorsque vous en aurez terminé.
@BobRodes Je pense que les triples dièses sont parfaitement valables (au sens théorique). Si nous nous en tenons à l'exemple que j'ai utilisé dans ma question, mais que nous transposons un E ## au lieu de E #, alors ce serait un deuxième intervalle doublement augmenté (je pense) et le seul moyen de conserver le même intervalle pendant la transposition serait le résultat de F###. Pour autant que je sache, avoir des bémols doubles ou triples / dièses est une question de préférence. Cela devra donc être laissé à l'utilisateur, pas à l'algorithme.
Ouais, mais les gens préfèrent généralement ne pas les utiliser. Voici un article intéressant sur la façon dont MuseScore gère la transposition. http://davidbolton.info/articles/musescore_interval_transposition.html Il mentionne que Finale garde un triple dièse et Sibelius le répète.
p.s. Si vous êtes intéressé par un programme gratuit doté d'une bonne fonction de transposition, vous voudrez peut-être télécharger et installer MuseScore.
@BobRodes C'est un article incroyable, merci de l'avoir signalé! C'est bon de savoir que je suis sur des sentiers battus puisque Finale le fait de la même manière. J'ai fini d'implémenter l'algorithme et vous pouvez voir le code source ici: https://github.com/jpotterm/google-apps-chord-transposer. Le gros du travail est effectué dans la fonction de transposition du fichier server / note.gs (il peut bouger si je refactore à l'avenir). J'espère que vous le trouverez utile, et merci pour toute votre aide!
Voici un autre article sur les bizarreries de notation musicale: http://homes.soic.indiana.edu/donbyrd/InterestingMusicNotation.html. L'auteur mentionne qu'il y a "au moins cinq" exemples de triples objets tranchants / plats dans toute la littérature musicale! Si vous transposez des partitions, vous voudrez peut-être faire quelque chose pour les éviter.
Six réponses:
Matt L.
2015-12-07 02:20:25 UTC
view on stackexchange narkive permalink

L'échelle utilisée n'est en effet pas pertinente. Ce qui compte, c'est l'intervalle entre la note fondamentale et la note actuelle. En utilisant votre exemple, un E # est une tierce augmentée de la note fondamentale C. Donc, si la racine change en D, la note transposée est une tierce augmentée à partir de D, qui est un F ##.

Au lieu de travailler avec des demi-tons (ce qui vous donnera une ambiguïté dans la dénomination des notes), vous devez travailler avec des intervalles, ce qui vous permet de distinguer un Mi # d'un F (pour C comme racine, le premier est un tiers augmenté, le dernier un parfait quatrième).

Très instructif, merci! Je pense que c'est ce que je fais. Donc, l'algorithme que j'utilise vous semble correct?
@JonathanPotter: Oui, mis à part l'utilisation de "l'échelle de la clé actuelle", ce qui n'est pas nécessaire. Prenez l'intervalle entre la note fondamentale d'origine et la nouvelle note fondamentale et décalez la note actuelle de ce même intervalle. Cela gardera l'intervalle entre la note et la note fondamentale identique.
Je voudrais marquer à la fois cette réponse et la réponse d'@Dom's comme étant correctes, mais je ne peux en faire qu'une: (Vous avez donc mes remerciements et mon vote favorable.
Dom
2015-12-07 03:00:42 UTC
view on stackexchange narkive permalink

Matt a raison, vous voulez penser par intervalles lorsque vous pensez à la transposition, car cela vous permettra de savoir comment vous devez nommer la note ainsi que la distance en demi-tons dont vous avez besoin pour déplacer la note.

Donc, dans ce cas précis, vous transposez toutes les notes d'une seconde majeure, ce qui signifie que vous déplacez chaque note vers le haut de deux demi-tons et le nom de la note est basé sur le nom de la lettre suivante.

Disons juste pour simplifier que la valeur de la note a été énumérée comme ceci:

 0 1 2 3 4 5 6 7 8 9 10 11C C # / Db DD # / Eb EFF # / Gb GG # / Ab AA # / Bb B 

Et disons aussi que nous avons les lettres de note énumérées comme ceci:

 0 1 2 3 4 5 6C DEFGAB 

Revenons donc à votre exemple, le E # correspondrait à la valeur de note de 5 (F) et à la lettre de note de E (2), quelle que soit la tonalité dans laquelle vous vous trouvez. Lorsque vous souhaitez déplacer cette note d'une seconde majeure , vous augmenteriez alors la valeur de la note de 2 et la lettre de la note de 1 donnant une valeur de note de 7 (G) et la lettre de note de F (3) à partir de ces deux valeurs, vous pouvez attribuer un nouveau nom à la note.

J'ai mis à jour la question avec un nouvel algorithme basé sur votre réponse (et celle d'@MattL's). A-t-il l'air d'avoir bien compris?
Oui, mais surtout si vous voulez continuer à faire des logiciels basés sur la musique, j'essaierais de garder l'algorithme en termes musicaux. Les étapes 1 et 2 sont combinées si vous dénotez simplement l'intervalle comme un 2e majeur (dont vous connaissez la distance en demi-tons et le nom de la lettre que vous souhaitez déplacer) que vous pouvez créer une infrastructure à faire avec un peu de travail supplémentaire.
Oui, dans mon code, j'ai créé une abstraction pour les intervalles, mais j'ai pensé qu'il était utile dans cette question de spécifier explicitement comment on procéderait pour trouver l'intervalle puis l'appliquer. Mais j'ai mis à jour la question pour donner une meilleure explication des intervalles.
Caleb Hines
2015-12-07 08:51:00 UTC
view on stackexchange narkive permalink

Si je peux suggérer une alternative plus simple: utilisez une approche "Ligne de cinquièmes" pour assurer l'orthographe correcte des notes tout en ne nécessitant aucune connaissance du degré d'échelle.

La ligne des cinquièmes est construite de la même manière que le Cercle des cinquièmes mieux connu, mais il n'assume pas d'équivalence enharmonique, il ne se referme donc pas sur lui-même et s'étend à l'infini dans les deux sens. C'est une structure pratique à utiliser avec des algorithmes qui se soucient correctement de l'orthographe des notes.

...
B ♭
F
C
G
D
A
E
B
F♯
C♯
G♯
D♯
A♯
E♯
B♯
F♯♯
...

L'algorithme devient alors:

  1. Découvrez combien d'espaces le long de la ligne vous transposez. Dans ce cas, passer de C à D équivaut aux deux cinquièmes.
  2. Trouvez la note que vous voulez transposer, puis allez plus loin. Dans ce cas, aller aux deux cinquièmes au-delà de E♯ vous amène à F♯♯.

Si vous souhaitez en savoir plus, j'ai introduit le concept Line of Fifths dans ma toute première pile échange de réponse, concernant une manière algorithmique de déterminer les noms d'intervalles: Procédure générale pour déterminer le nom d'un intervalle à partir d'une clé majeure / collection diatonique.


Mise à jour : Comme ce n'est pas tout à fait évident et que BobRodes a posé des questions à ce sujet, je mentionnerai que dans ce schéma, n'importe quelle note peut être représentée par un seul nombre - sa position le long de la ligne. Bien que vous puissiez éventuellement mettre l'origine n'importe où, je trouve que le calcul fonctionne mieux si F = 0 et les nombres augmentent à mesure que vous vous dirigez vers les dièses (C = 1, G = 2).

Il n'est pas nécessaire de stocker un tableau entier de noms de notes, car il existe un simple mappage un à un entre le nom d'une note et sa position sur cette ligne. Vous devez stocker explicitement 7 paires (mappant la plage F-B aux nombres 0-6), mais une fois que vous avez cela, la position de n'importe quel nom de hauteur peut être trouvée (et vice versa).

La clé est de réaliser que tout nom de hauteur peut être représenté par la paire {letter, numberOfSharps} - où un numberOfSharps négatif signifie utiliser des bémols. Par exemple F♯♯♯ est (F, 3) tandis que G ♭♭ est (G, -2). Pour le convertir en une position le long de la ligne, vous utilisez la formule:

  7 * numberOfSharps + letterToNumber [letter]  

Donc pour C♯♯♯ , puisque C = 1 et qu'il y a 3 dièses, la position le long de la ligne serait 7 * 3 + 1 = 22.

La relation inverse (convertir une position en nom de hauteur) peut être trouvée en utilisant un combinaison de division entière par 7 pour obtenir le nombre de dièses et de division modulaire (position mod 7) pour obtenir la lettre.

Très intéressant Caleb. Bien que je sache que vous pouvez théoriquement vous étendre à l'infini, en pratique, nous n'allons pas au-delà de ## et bb comme vous le savez sûrement. Donc, si vous écriviez un algorithme, où remonteriez-vous d'un B ## ou d'un Fbb? Non pas que vous rencontriez l'un ou l'autre de ces 99,9% du temps, mais que feriez-vous si vous le faisiez? Je pense que vous pourriez simplement monter ou descendre d'une sixième diminuée au lieu d'un cinquième, faisant passer B ## à G # et Fbb à Ab. Qu'est-ce que tu penses?
Je ne vois aucune raison pour laquelle le wrapping serait nécessaire et j'ai mis à jour ma réponse en conséquence. Cependant, si vous le souhaitez, vous pouvez simplement ajouter / soustraire 12 à la position de la note, afin de vous rapprocher de 0.
La raison est pratique. Personne n'utilise plus que le double dièse / double bémol en notation (presque personne). Si vous essayez réellement de créer un logiciel qui transpose de la musique réelle, vous atteignez une limite difficile à Bx et Fbb.
Bien sûr, vous auriez du mal à l'afficher ou à l'imprimer, mais il n'y a aucune raison théorique que l'algorithme de transposition soit intrinsèquement limité.
Eh bien, une partie de l'algorithme de transposition serait la note réelle à produire, n'est-ce pas? Je veux dire, je comprends votre point de vue, mais cela ressemble à la façon dont vous définissez la limitation. Un algorithme qui ne peut pas produire les notes qui sont réellement utilisées dans la transposition au nom d'être en quelque sorte illimité est une contradiction dans les termes, n'est-ce pas?
Je vois votre point. Mais cela signifie-t-il que vous avez besoin d'un autre algorithme pour déterminer quelle note imprimer?
Merci! Après avoir essayé plusieurs stratégies pour résoudre le problème, j'ai trouvé et implémenté celle-ci, et elle semble avoir très bien fonctionné. La modification a été particulièrement utile, j'étais sur le point de créer le tableau complet jusqu'à ce que vous indiquiez comment mapper facilement à un nombre. Cela fonctionnait très bien tel quel pour les accords, mais j'ai également utilisé le même algorithme pour transposer les notes sur la feuille. Pour cela, j'avais besoin d'ajouter une logique supplémentaire afin de gérer les informations d'octave (par exemple E5 vs E6). J'ai également fini par implémenter le triple-sharp et le triple-flat sur mon application, au moins pour pouvoir vérifier l'exactitude de certains cas de bord.
Tekkerue
2015-12-07 05:31:13 UTC
view on stackexchange narkive permalink

Vous n'avez que 12 clés dont vous devez vous soucier (même les touches mineures ne sont que des doublons en termes de notes du majeur relatif), il serait donc très simple de créer un tableau de chaînes à 2 dimensions à utiliser comme table de recherche pour les noms de chacune des notes pour chaque touche. Cela vous permettra de spécifier comment chaque note sera appelée pour les 12 touches et vous pourrez déterminer si vous voulez appeler une note un "A #" ou un "Bb".

De plus, vous pouvez également décider quoi pour appeler des notes en dehors de la clé (de nombreux morceaux contiennent des accords / notes de l'extérieur de la clé). Par exemple, vous pouvez choisir d'utiliser le nom D # dans la clé de sol majeur (puisque sol majeur en a un dièse), tandis que vous pouvez choisir d'utiliser le nom Eb en fa majeur (puisque fa majeur en a un bémol).

Cela rendra les changements de touches très simples car tout ce que vous avez à faire est de changer la racine et tout le reste concernant les accords / notes en interne dans la clé restera exactement le même.

??? ... pourquoi le vote vers le bas? Jonathan est en train d'écrire un logiciel et a demandé un algorithme pour la transposition des clés, alors je lui ai proposé une suggestion sur la façon de coder ce qu'il essayait de faire. Je suis programmeur et musicien et j'ai de l'expérience dans ce domaine car j'ai moi-même créé un logiciel de musique qui incluait la possibilité de transposer des clés. Ma réponse s'adressait à un autre programmeur qui comprendra probablement ma suggestion. :)
Eh bien, je suis un autre programmeur aussi, et votre algorithme n'explique pas comment «vous pouvez déterminer» comment appeler une note. Il doit inclure cela si elle doit être considérée comme une solution.
Mais ce que vous appelez une note dépend de la clé dans laquelle vous vous trouvez, donc ce que vous appelez réellement une note sera différent. Les noms des notes peuvent être trouvés en recherchant sur Google les 12 touches principales différentes, puis en les saisissant manuellement dans la table de recherche. Cela éliminera les bizarreries comme "E #" d'apparaître dans la clé de Do majeur car le tableau pointera toujours vers le nom "F" et non "E #". Je suppose qu'il a besoin de plus d'informations sur le type de scénarios qu'il tente de rendre compte.
Je suis d'accord que plus d'informations sont nécessaires. Mais si l'OP a besoin d'écrire des partitions transposées, les "bizarreries" que vous mentionnez ont leur place et leur utilisation dans la musique. Voir ici: https://www.youtube.com/watch?v=A3j57AdHSvg (c'est un peu flou, désolé, mieux que je puisse trouver). Regardez sur la troisième ligne, première mesure, dernier temps, note supérieure de l'accord. C'est un E #. Si vous l'avez écrit F, vous devrez écrire un naturel dessus (parce que le F précédent est pointu), puis mettre un pointu sur le prochain F. Ce n'est pas aussi facile à lire.
p.s. Si l'entrée et la sortie du programme sont toutes deux de la musique réelle, alors les noms enharmoniques des notes n'ont pas d'importance comme vous le dites. Si ce sont des partitions, votre idée est une simplification excessive irréalisable, comme mon exemple devrait le démontrer. La plupart des échecs de développement de logiciels dans notre entreprise sont dus à une compréhension incomplète des exigences; c'est un bel exemple de cela. :)
La clé est l'un des nombreux facteurs qui déterminent ce que vous appelez une note. Si vous êtes dans la clé de C, vous pouvez voir C # et / ou Db selon le contexte dans lequel vous vous trouvez, c'est même le cas pour E # et F comme dans ce cas. La clé seule ne suffit pas, vous avez besoin du contexte et de plus d'informations et dans ce cas, en utilisant simplement la clé, vous obtiendrez un F au lieu du E # souhaité, ce qui n'est pas ce que l'OP veut.
La partie de la partition était la pièce qui manquait dans le message d'origine, mais il a mis à jour le message et a clarifié cette partie maintenant. :) Oui, dans les partitions, il y a aussi l'aspect visuel de la façon dont elles apparaissent sur le papier pour le rendre plus facile à lire, ce qui peut l'emporter sur la théorie classique des accords / clés comme le fait l'exemple de Bob. Je m'attendais à une conversion de tableau d'accords étant donné qu'il a déclaré qu'il était nouveau dans la théorie musicale et que la conversion des partitions est une tâche assez ambitieuse à entreprendre.
@Tekkerue: est étonnant de voir comment une entreprise va dépenser 5 millions de dollars pour répondre aux exigences, et quand tout le monde est à la taille profonde dans la phase de développement et que les parties prenantes y vont, ce n'est pas du tout ce que je voulais dire, 20 personnes s'asseoiront autour d'une table et diront bien, je s'attendait à cela à cause de ce «donné» très raisonnable et logique, etc., etc., etc. C'est pourquoi la moitié de toutes les initiatives de développement logiciel échouent. S'il vous plaît, comprenez qu'il ne s'agit pas d'une critique personnelle, mais d'une observation sur quelque chose que nous, les informaticiens, faisons tous et que nous devons faire attention à éviter (et ce n'est souvent pas le cas) lorsque l'argent est sur la table.
BobRodes, bien sûr, mais c'est un forum Web gratuit où quelqu'un a posé une question qui a déclaré qu'il était nouveau dans la théorie musicale et n'a pas spécifié au départ quel type de logiciel il écrivait. Donc, dans le cas de quelqu'un de nouveau dans la théorie, supposer que l'approche la plus simple était raisonnable. Mais si c'était un travail, je l'aurais criblé de questions pour déterminer ce qu'il voulait et je n'aurais certainement pas codé quoi que ce soit sans obtenir plus de directives. De plus, je développe en fait mon propre logiciel là où il n'y a pas de place pour la confusion quant à mes besoins, donc pas de soucis là-bas. :)
Il est clair que vous comprenez très bien pourquoi j'ai dit que ce n'était pas une critique mais une observation. LOL
Je n'allais pas entrer dans une dispute à ce sujet, mais vous avez paraphrasé mon commentaire sur «l'attente» d'un certain résultat parce que c'était raisonnable compte tenu des informations initiales. Donc, votre «observation» était clairement dirigée vers ma réponse et j'ai expliqué pourquoi c'était inutile ... arrêtons-nous là. :)
BobRodes
2015-12-07 13:44:58 UTC
view on stackexchange narkive permalink

À mon humble avis, le moyen le plus efficace de faire ce que vous voulez d'un point de vue informatique est la solution de Caleb Hines. Il y a moins de pièces mobiles que la solution de Dom (désolé Dom). Créez simplement un tableau (un tableau de base zéro) contenant sa «ligne de cinquièmes». Vous devrez gérer la condition aux limites de l'endroit où aller depuis les extrémités de la ligne, qui sont Bx et Fbb. En l'absence d'une meilleure suggestion de sa part, je changerais les quintes en sixièmes diminuées: G # suit Bx, Ab suit Fbb. Il est très peu probable que vous voyiez l'une de ces notes (ou que vous deviez les transposer), mais vous devez en tenir compte. Si vous ne le faites pas et qu'ils arrivent, votre programme échouera de façon spectaculaire et la raison ne sera pas très évidente.

Donc, votre algorithme ressemblera à quelque chose comme ça. Tout d'abord (en supposant que vous avez déjà créé le tableau avec la «ligne des cinquièmes»), déterminez la distance entre la clé d'entrée et la clé de sortie:

  1. Commencez par le premier élément du tableau.
  2. Itérez le tableau jusqu'à ce que vous trouviez l'une des deux clés.
  3. Continuez à itérer le tableau jusqu'à ce que vous trouviez l'autre clé.
  4. Soit X égal à la différence entre les deux décalages.
  5. Si la première valeur trouvée est la clé cible, laissez X = -X.

Ensuite, parcourez toutes les notes du morceau (un proposition non triviale!). Pour déterminer la hauteur transposée d'une note:

  1. Itérez le tableau jusqu'à ce que vous trouviez l'élément contenant la note. Soit Y égal le décalage de cet élément.
  2. Si Y + X est supérieur à la limite supérieure du tableau (nous appellerons la limite supérieure U), soit A = le décalage de C #. Sortez l'élément dont le décalage est A + Y + X - U.
  3. Si Y + X est inférieur à zéro, soit A = le décalage de Ab. Sortez l'élément dont le décalage est A + Y + X.
  4. Dans le cas contraire de 2 ou 3 (condition non aux limites), affichez l'élément dont le décalage est Y + X.

Cela devrait vous aider à démarrer. Si vous pouvez creuser des trous dans ma logique, faites-le par tous les moyens.

Inutile de gaspiller toute cette mémoire précieuse ou de vous limiter aux limites d'un tableau fini! Représentez simplement une note sous la forme d'un numéro unique et créez une correspondance entre ce numéro et le nom de la note. J'ai mis à jour ma réponse avec plus de détails. Avec un entier 32 bits, cela vous permet d'obtenir au moins jusqu'à F avec 306 783 377 dièses. Ce qui devrait être plus que suffisant pour paraître infini sous toute transposition possible ...
Ce n'est pas utile, cependant, en termes pratiques. Vous n'allez généralement pas au-dessus de deux objets tranchants ou plats. En tant que tel, vous devez élaborer une note enharmonique à transposer si l'algorithme produit un triple dièse ou plat. Vous allez devoir faire cela pour résoudre le problème actuel. http://homes.soic.indiana.edu/donbyrd/InterestingMusicNotation.html contient des informations intéressantes à ce sujet.
Tim
2015-12-07 02:19:48 UTC
view on stackexchange narkive permalink

Il y a un léger défaut dans le fait que ce ne serait probablement jamais un E # dans la clé de C, mais le concept semble être dans la bonne direction. Vous devez être plus conscient musicalement.

En relisant votre question, il est évident que j'ai mal compris ce que vous vouliez. Je m'excuse.

L'OP a mentionné qu'il savait qu'il n'y aurait normalement pas de mi # dans la clé de do majeur, mais en théorie, cela pourrait arriver. Et l'exemple a été délibérément choisi pour être un peu bizarre, afin de «contester» la méthode.
Tout passage assez chromatique dans la clé de C pourrait en avoir un. Par exemple, l'Étude Op. 10, le numéro 2 est en Do et la mesure 7, quatrième temps, la note supérieure est un E #. Peut-être que votre critique du manque de conscience musicale de l'OP est déplacée, Tim?
@BobRodes, en regardant la pièce, il semble que le mi # est pour que l'interprète puisse rapidement voir d'un coup d'œil qu'il est chromatique (toutes les notes dans une belle pente). Ce n'est pas un problème théorique mais un problème visuel de la façon dont il apparaît sur la partition pour le rendre plus facile pour l'interprète. Un algorithme aveugle convertissant en une clé différente pourrait très bien bousiller cette belle pente visuelle sur la partition indiquant qu'elle est chromatique. Ce genre de chose ne fonctionnera probablement pas très bien avec un algorithme aveugle car l'algorithme ne saurait pas la raison pour laquelle le E # a été utilisé au lieu du F. "théoriquement correct".
Je vous renvoie à mon commentaire sur votre message. Vous avez tout à fait raison, c'est avant tout un problème visuel. Mais il existe des algorithmes qui afficheront toujours cet intervalle comme une seconde mineure plutôt que comme un unisson augmenté. L'idée de Caleb Hines a l'air de l'être, par exemple, même si je voudrais tester les conditions aux limites de manière plus approfondie avant de faire une telle déclaration.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...