-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pilotage MIDI #5
Comments
L'idée ici est de pouvoir assigner les contrôles du logiciel à des potentiomètres et des chariots sur des surfaces de contrôle MIDI, histoire de faciliter son utilisation car il est plus facile/marrant de tourner un potard que d'appuyer sur les touches du clavier alpha-numérique. |
Ici je pense que l'apprentissage MIDI sera important, puisque selon moi il va falloir être en mesure de pouvoir créer une association entre un contrôle MIDI avec un nuage particulier. Les associations doivent pouvoir être exprimées en Control-Change, voire en NRPN. |
"un nuage particulier" et/ou un "un échantillon" (un rectangle) |
si on veut associer un controleur midi à chaque grain, on va tres vite saturer en terme de possibilités. |
Je ne crois pas, ça dépend de l'utilisation d'un utilisateur. J'imagine qu'il suffirait probablement d'implémenter l'apprentissage MIDI et de ne pas coder en dur "qui fait quoi" dans le logiciel pour laisser chaque utilisateur définir ce qu'il veut contrôler et avec quel contrôle. Si toi tu as envie de bosser sur un sujet qui t'intéresse particulièrement comme de contrôler les nuages en MIDI, vasy, c'est super. Mon conseil est d'essayer pour toi de penser à coder en pensant un peu plus loin (comme ce que j'ai abordé dans les messages précédents). |
du coup ça demanderait de gerer un parametrage des affectations des signaux midi, qui serait peut etre à integrer dans un fichier, peut etre un fichier de sauvegarde d'un projet (voir l'issue au sujet de la sauvegarde des projets). |
bon, il s'agit ici de bien définir toutes les idées qui nous viennent à l'esprit de type de pilotages midi pour voir si la maniere dont on developpera celui ci permettra de repondre à toutes ces envies.
bon, dejà avec ça y'a de quoi se prendre pas mal la tete. n'hesitez pas à enumerer vos envies possibles aussi. |
A mon avis le plus simple est de normaliser toute valeur en domaine 0-1 et appliquer une courbe de contrôle. La courbe se définit en points de contrôle (x,y) et pour le besoin de la synthèse on conserve dans un tableau la version interpolée. |
ravi de voir ma suggestion comprise, mais malheureusement, moi je ne comprends pas la solution :) |
dans l'optique d'un expandeur midi, une autre fonctionnalité me plairait enormement.
|
pour pouvoir faire de Frontieres un expandeur midi, il serait simple de rajouter 2 parametres aux clouds :
ainsi, on peut tres simplement :
|
fonction de base midi proposée avec note on, note off, qui activent / desactivent des clouds.
|
dans l'optique de la creation de cette nouvelle classe, voici verbalisées quelques idées à son propos :
|
voici donc ce que pourrait etre cette classe : combinaison :
instrument :
tout cela fait partie d'une scene, et peut etre mémorisé avec elle. il faudrait peut etre aussi creer un parametre de verrouillage d'un cloud, afin que l'utilisateur puisse décider de ne pas permettre de le modifier par inadvertance lorsqu'il est utilisé dans des combinaisons (idem pour la position et la forme des samples) |
il y a des bugs dans l'implementation midi qui etait fournie à la base dans borderlands :
|
bon, le canal midi n'est pas à 0 en fait, il est au numero de canal -1, et comme j'emettais sur le canal 1, il mettait 0, il me faut donc ajouter 1 au numero de canal reçu |
Oui je confirme que les indications en commentaire sont erronnées.
Dans les messages midi, le canal est une valeur sur 4 bits, soit valuée de 0 à 15. Cela explique le décalage de 1, mais le calcul est juste. |
oui, c'est ce que j'ai fait pour cette meme raison. maintenant , je me penche sur la question des combinaisons.
|
J'ai pas du tout réfléchi à la question pour l'instant, mais je me suis noté de faire ça un peu plus tard. |
Ce serait une éventualité, mais sous contrainte de temps réel cela rajoute de la complication, car on n'a pas le droits aux malloc/new, toute mémoire se réserve à l'avance. |
j'ai noté la strucutre que je pense utiliser quelques messages au dessus
difficilement, à mon avis, si on veut un synthetiseur reellement polyphonique sur chaque cloud :
les grains ne sont à mon avis que des constituantes du son qu'on peut comparer à des harmoniques de celui ci, ils peuvent donc tout à fait etre accordés différemment de l'accord principal du cloud. tout ça, je sais faire. seule la question de faire une copie sans creer une latence m'inquiète, mais sinon, je ne vois pas du tout comment rendre un cloud polyphonique avec différents pitchs. |
Ok j'aime bien l'idée. Tout de même, je pense qu'il serait bien que Je verrais éventuellement un fractionnement de l'entité nuage, avec une relation 1→N avec une multitude de "variantes tonales de nuage". Le N peut être borné par un maximum tel que 32, comme une polyphonie de synthétiseur. Je pense que l'interface graphique doit continuer à manipuler des instances de Nuage, en ajout/suppression, ce qui occupe le verrou de scène et donc constitue une opération pouvant occasionner une période d'arrêt. Au contraire, les N "voix" (si on peut maintenant se permettre de réutiliser ce terme) pourraient être réservées en mémoire à l'avance, et seul le fil audio se permettrait de les manipuler. Cette opération serait compatible avec le temps réel. J'en profite pour glisser un lien vers une structure de donnée que j'ai réalisée très récemment pour un synthé TR : https://github.com/jpcima/libADLMIDI/tree/std-structures/src/structures |
ça, dans mon idée, c'est le cas, et on peut tres bien melanger les deux façons de faire du son en continuant à travailler en temps réel sur les clouds, même si un musicien autre est en train de jouer en pilotage midi.
c'est ce que je ne vois comment realiser, c'est pour ça que je me suis tourné vers la logique de copie temporaire du cloud.
c'est quoi, ce verrou de scene dont tu parles ?
meme commentaire que ci dessus, ça je ne sais pas comment le gerer
je vais jeter un oeil voir si j'y comprends quelque chose. |
C'est pas évident et ça demande de s'y pencher plus en détail, raison pour laquelle je ne sais trop te donner une réponse précise pour le moment. C'est ça le verrou de scène: |
pourtant, la suppression d'un cloud ne me semble pas creer d'interruption du rendu sonore des autres clouds actifs. ou c'est si court que je ne le décele pas, et s'il y a trop de destructions dues à une polyphonie comme je la pense, ça pourrait devenir audible ? |
J'ai fait que la prise du verrou soit réalisée sur la période la plus courte possible, donc il se peut que la discontinuité ne se produise que très rarement. Il n'empêche qu'elle est possible. |
bon, si je résume :
donc, je pense que, vu que mes capacités sont loin d'atteindre les tiennes, je peux me pencher sur la partie structure de cominaisons, son implementation et les fenêtres permettant de gérer tout ça, et te laisser pour plus tard voir le lien avec les clouds. |
simple remarque : il s'agira de xrun en ce cas, et non simplement de discontinuité sonore. |
je suis en train de réfléchir à la question de la polyphonie de nouveau.
|
j'ai déposé un nouveau PR sur la gestion de la polyphonie midi je reprends ici les explications mises dans le PR, et clos "polyphonie midi, probleme de comprehention dans la gestion des envelopes #59 " qui fait double emploi avec ici. cette branche est assez conséquente :
|
@trebmuh À détailler.
The text was updated successfully, but these errors were encountered: