Bonjour a tous,
Je voudrais concevoir une surface de contrôle MIDI et pour ça
Je souhaiterais réaliser deux matrices :
La première de 64 (voir plus) potentiomètres rotatif et faders (multiplexage analogique ?)
la seconde de 64 (voir plus ) Encodeurs rotatif(Multiplexage Numérique ?)
Toutes les deux sur un port série genre SPI je n'ai pas besoin de fonction mémoire
j'aurai besoin d’être guidé dans le choix des composants et de la conception hardware
A bientot
Djé
Salut,
J'imagine déjà la taille de l'engin et les contraintes mécaniques (à ne pas négliger).
As-tu trouvé un appareil tout fait de ce genre dans le commerce? J'aurais presque tendance à t'orienter vers du hack pur et dur...
Je pense qu'on peut trouver un contrôleur comprenant des potars et encodeurs en nombre pour pas trop cher, même s'il ne remplit pas les fonctions que tu souhaites. Une bestiole chez Behringer coûtera moins cher que le prix des potars et encodeurs seuls. Tu bénéficiera en plus d'une belle boîte en ferraille assez solide que tu pourras repeindre, une alim, interface signaux midi, prises, multiplexeurs et buffers, et une bonne partie du câblage déjà fait...
Il ne te restera plus qu'à l'ouvrir, et remplacer le µP maître par un arduino MEGA (j'ai peur qu'un UNO soit trop léger niveau E/S) et faire un beau programme maison! si un tel appareil existe déjà, ce serait un gain de temps et d'argent!
J'ai regardé vite-fait, mais pas trop trouvé, tu dois savoir mieux que moi ce qui existe dans ce domaine...
Hello Super_Cinci,
Merci de ta réponse effectivement il existe un grand nombres de surfaces de contrôles MIDI ce qui se rapproche le plus
c'est
http://lividinstruments.com/hardware_builder.php
mais malheureusement il ne transforme que les données en contrôleurs continu et moi j'ai besoin de Sysexs (system exclusifs)
Pour rentrer un peu plus en détail concernant ma réalisation c'est de créer une sorte de Shield Master modulaire Avec:
64 entrées Switch (SPST) pour ca c'est bon j'utilise un bus SPI drivé par des 74HC165 (Serie)
64 Sorties Leds pour ca c'est tout bon aussi sur un Bus SPI drivé par des 74HC595 (paralelle)
je voudrait fonctionner sur le même principe pour les Pots et encodeurs un bus SPI(ouI2C) mais la question est de savoir
quel multiplexeur utiliser et si il faut un PIC pour la gestion ou toutes autres solution.
pour "l'acroche" des pots,Faders,encodeurs,switch,leds je compte utiliser les cartes OmniBoard de chez Livid qui sont pas
cher et modulaires.
L'arduino assurera la conversion des données et le routage MIDI.
Mon utilisation ne serra pas une surface de contrôle hardware mais par exemple
de modifier un Synthé en intégrant physiquement des contrôles dans le châssis.
comme cet exemple d'integration
A bientot
Djé
Ok, je vois grossièrement. J'ai ouvert récemment un pupitre lumière DMX qui avait pris la flotte pour le nettoyer. Le principe de câblage reste le même : des potars et boutons, du traitement de données et une sortie série. Malheureusement, je n'ai pas relevé les circuits internes, mais pour gérer 35 potars, il y avait plusieurs chips genre multiplexeurs analogiques et des registres à décalage pour 60 boutons, le tout arrivait sur deux µP genre 48 pin et centralisé par un µP plus petit qui générait les trames DMX vers un MAX490qqchose. J'imagine que pour toi, le petit µP sera l'arduino, il te manque ce qui ira entre tes potars/boutons et l'arduino...
Le truc du pic peut être pas mal, le pic s'occupe de lire les données des potars, compter les impulsions de tes encodeurs et envoie tout ça à intervalles régulier à l'arduino qui centralise, transforme et crée des trames midi.
Vu le nombre de contrôles, il te faudra peut-être plusieurs pics...
Pour les encodeurs, il doit exister des compteurs à deux entrées (clk UP et clk DOWN) avec latch de sortie 3 états. tu mets toutes les sorties de tes compteurs sur un bus // et tu viens les lire via un démultiplexeur d'adresse qui va sélectionner le compteur à lire. Il existe peut-être même des CI spéciaux encodeurs qui pourraient gérer 4 encodeurs par exemple (8 entrées clk), deux bits d'adresse (00 à 11 pour 4 compteurs), une pin /enable, sortie 8 bits 3 états... mais je connais pas...
A creuser...
Salut onoff
Il y a eu une discussion similaire il y a quelques mois pour quelqu'un qui voulait aussi utiliser une palanquée de potars.
Pour multiplexer les potars, pas de problèmes. Des mux analogiques type CD4051/52/53 vont faire l'affaire.
L'Arduino ne dispose que de 6 entrées analogiques mais un seul ADC. Ca ne sert donc a rien d'utiliser le multiplexeur interne du chip. Autant tout multiplexer en externe vers une seule entrée analogue d'Arduino.
Un premier niveau constitué de 8 CD4051 pour les 64 potars
Un 2eme niveau constitué de 1 CD4051 pour les 8 mux de premier niveau.
De mémoire, l'ADC peut convertir a environ 15kHZ (si on veut conserver les 10 bits de résolutions, on peut monter a plus si on réduit à 8 bits).
Ce qui permet de scanner l'ensemble des potars plus de 200 fois par secondes.
C'est suffisant même pour des contrôleurs live, même si je comprend que ce que tu veux faire c'est que de la programmation par sysex, donc tu peux prendre ton temps.
Pour ce qui est des encodeurs rotatifs, ca risque d'être plus délicats. Je ne suis pas sur qu'on puisse les multiplexers facilement.
D'habitude on gère les encodeurs rotatifs par interruptions. Mais là vu le nombre, ca ne va pas le faire.
Il va probablement falloir pas mal d'entrées pour gérer un max d'encodeurs en //.
A approfondir...
A première vue je serais tenté de prendre 2 chips :
A+
J'ai regardé vite fait les encodeurs en quadrature, en fait (et je découvre, j'apprends...) c'est assez simple, il suffit de mettre un compteur U/D sur l'encodeur (signal A sur Clk, signal B sur "count direction"), et de lire la valeur de sortie // du compteur. Mais va falloir un compteur par encodeur plus toute la série de latchs qui vont avec et un démultiplexeur assez large pour adresser les 64 latchs. Il doit pourtant bien exister des "compteurs multiples", non? ou alors des pics en pagaille...
Super_Cinci:
J'ai regardé vite fait les encodeurs en quadrature, en fait (et je découvre, j'apprends...) c'est assez simple...
Bonjour super_cinci
Si le principe est assez simple une fois assimilé, la gestion d'encodeurs multiples n'est pas si simple en pratique.
la première chose à prendre en compte pour dimensionner est déjà de connaitre la récurrence possible des impulsions en quadrature :
c'est très différent de gérer 64 encodeurs à 16 états par tour avec une occurence ~ d'un tour/" ou de gérer des encodeurs à 400 états mis derrières des moteurs (pour reaction) tournants à des vitesse de qq milliers de tours par minute.
Il faut là déjà faire le choix de l'encodeur, en "audio/lumière" la majorité des encodeurs utilisés sont des 16-->64 changements d’états par tour, et ensuite déterminer le taux maxi de changement d’état par seconde.
une possible solution au moins théorique serait là de détecter d'abord si il y a eu changement d’état sur le global (situation N # N-1)
ça nécessite d'une manière ou d'une autre déjà de conserver l’état ancien, ensuite d’acquérir l’état actuel et ensuite comparer.
pour 64 "modules" = 64 bits pour les voies A et autant pour les voies B soit au final 256 (N N-1) bits pour aboutir à une résolution des états.
Bonjour a tous le monde,
Et merci pour ces Infos,
Comme je me doutais que les Encodeurs seraient le plus délicat je revois la nombre a 16 en règle générale ils assurent que peu de fonctions : hauteur par Demi-Ton des oscillateurs, sélection des formes d'ondes, Etc... et il se peux également que pour certains paramètres je n'est besoin que de quelques positions (genre sélecteur) je vais également creuser dans ce sens pour avoir quelque chose de flexible.
Je clarifie le fonctionnement souhaité
Encodeurs :
c'est je "touche" (un pulse) un encodeur il devient prioritaire, il est identifié (scan), il fournit une valeur, dernière valeur connue doit être conservé dans un buffer, je "touche" un deuxième idem etc... concernant le décodage la conversion doit être programmable depuis l'arduino
que le décodage soit fait en interne ou externe les messages a sortir sont du type :
-RealTime sysex codé généralement en 7 Bit MSB/LSB ou maxi 14 Bit littéralement les valeurs d'inc/decrement sont 0-127.
-Controleurs Continu (ou tout autres messages MIDI )
Pour les potars tout pareil sans buffer car l’état de la valeur analogique (0-5V) est reprise directement par le mouvement.
ce n'est pas a proprement parlé un "surface de contrôle" mais plutôt une interface de contrôle de paramètres en temps réel intégré
A bientot
Djé
onoff:
...
Comme je me doutais que les Encodeurs seraient le plus délicat je revois la nombre a 16 en règle générale ils assurent que peu de fonctions :
Bonsoir
ce n'est pas tellement ce qu'il sont censés faire qui est là important, c'est surtout de déterminer quel est le taux maximum de changement d'etats pour une periode de temps donnée.
mais evidemment reduire de 64 à 16 les encodeurs augmente le temps de traitement disponible pour les des actions à suivre sur changement d'etat.
Artouste:
onoff:
...
Comme je me doutais que les Encodeurs seraient le plus délicat je revois la nombre a 16 en règle générale ils assurent que peu de fonctions :Bonsoir
ce n'est pas tellement ce qu'il sont censés faire qui est là important, c'est surtout de déterminer quel est le taux maximum de changement d'etats pour une periode de temps donnée.
mais evidemment reduire de 64 à 16 les encodeurs augmente le temps de traitement disponible pour les des actions à suivre sur changement d'etat.
Bonsoir,
Peut tu approfondir si tu veux bien ? ou me faire un petit schémas ?
A bientot
Djé
Je vais certainement dire un truc inutile, mais deux boutons "suivant" et un "précédent" (ou un encodeur) qui sélectionnent une fonction, et un (autre) encodeur qui permet de choisir la donnée, le tout agrémenté d'un petit LCD pour s'y retrouvé serait moins cher et plus simple...
chépô...
Super_Cinci:
Je vais certainement dire un truc inutile, mais deux boutons "suivant" et un "précédent" (ou un encodeur) qui sélectionnent une fonction, et un (autre) encodeur qui permet de choisir la donnée, le tout agrémenté d'un petit LCD pour s'y retrouvé serait moins cher et plus simple...chépô...
Hello,
Toutes pistes sont bonnes même des fois si elles semblent C.... je suis un spécialiste 
moi j'aime bien ça me permet d'avoir pleins de pistes donc merci et surtout je préfère ca aux messages du type
"tu veux faire tous ca?" ou "bonne chance dans tes recherches"
ici au moins il y a des pistes de réflexions 8) surtout pour moi qui ai que des compétences limitées.
pour certaines fonctions effectivement j'avais pensé a un boutons (gestion en boucle de quelques états) et quelques leds en sortie pour indiquer la valeur mais ça ne peux pas remplacer les encodeurs
Une fois fini, ça pourrait ressembler a ça
Merci a tlm et bonne Journée
Djé
Dans les projets finis, je parle d'un préampli d'enregistrement 24 voies que j'ai fait. il se place entre les sorties de la table de mixage et l'enregistreur 24 pistes. Puis j'ai voulu rajouter une partie "écoute", où l'on pouvait faire un petit mixage des 24 voies dans un casque. Il m'aurait fallu 50 potars, plein de boutons et il n'y a plus de place... J'ai fini par opter pour la solution potars numériques, arduino et interface logicielle sur un PC (ou un peut-être un terminal série prochainement : j'ai un vieux minitel qui ferait très bien l'affaire).
Bref, j'ai économisé pas mal de boutons en réalisant ce soft sur mon portable : Le PC calcule les valeurs à affecter aux potars numériques puis les envoie à l'arduino qui s'occupe de simplement transférer les valeurs dans les potars...
(c'est une piste de recherche, non?) XD. Ca évite d'acheter des tas de trucs chers, c'est moins encombrant, et c'est évolutif à souhaits, pas de câblage emmêlé... il ne resterait plus qu'à envoyer les données en série à l'arduino qui va servir d'interface midi...
Je me suis mal exprimé,
niveau soft (logic Pro) et niveau hard(remoteZero,Remote25 et 61) j'ai déjà tous ça.
Le but c'est de réaliser cette interface(que je produirait en plusieurs exemplaires sans boitier et que j’intégrerais physiquement
dans certains de mes mes synths.
Exemple:
le clavier + Le boitier PG200 (qui représente l'interface que je veux réaliser)
Le clavier fini avec le PG200 intégré.
Djé
Si si, tu t'es bien exprimé... C'est juste que matériellement, 64 potars et 64 encodeurs, ça prend de la place physiquement, car ça représente pas loin d'une façade de 15 x 30cm au grand minimum, et aussi en gestion électronique.
J'imagine que tu souhaites créer des "modules" que tu intègrerais en fonction du besoin final de chaque appareil. Je pense que ton projet est arrivé à la phase où il faut poser les besoins sur papier pour pouvoir ensuite définir la solution matérielle qui y répondra...
Je te donnais juste des idées...
onoff:
Artouste:
onoff:
...
Comme je me doutais que les Encodeurs seraient le plus délicat je revois la nombre a 16 en règle générale ils assurent que peu de fonctions :Bonsoir
ce n'est pas tellement ce qu'il sont censés faire qui est là important, c'est surtout de déterminer quel est le taux maximum de changement d'etats pour une periode de temps donnée.
mais evidemment reduire de 64 à 16 les encodeurs augmente le temps de traitement disponible pour les des actions à suivre sur changement d'etat.Bonsoir,
Peut tu approfondir si tu veux bien ? ou me faire un petit schémas ?
A bientot
Djé
bonjour
ce qui est important c'est de ne pas louper de pas (changement d'etat)
il faut donc prealablement déterminer la capacité max de lecture de changement d'etat de l'arduino.
ça passe donc déjà par le choix des encodeurs = nombre d'encodeurs et pas des encodeurs
si l'echelle de temps de scan des états est trop grand , le risque de se retrouver avec des lecture erronées (non lues) est important
avec des encodeurs en quadrature c'est la comparaison sur etat ancien/etat nouveau qui determine le sens du taux d'incrementation.
si la fenetre de lecture est trop large, il y a perte d'information.
C'est donc à toi déjà de faire la selection des encodeurs selon ton confort d'utilisation.
comme repondu plus haut : en événements musique/lumiere , le taux de changement d'etats est faible vu du temps, par facilité je le met à ~ +/- 16 changements d'etats max par seconde, ça correspond à un tour sur un encodeur 16/tours
Super_Cinci:
Si si, tu t'es bien exprimé... C'est juste que matériellement, 64 potars et 64 encodeurs, ça prend de la place physiquement, car ça représente pas loin d'une façade de 15 x 30cm au grand minimum, et aussi en gestion électronique.J'imagine que tu souhaites créer des "modules" que tu intègrerais en fonction du besoin final de chaque appareil. Je pense que ton projet est arrivé à la phase où il faut poser les besoins sur papier pour pouvoir ensuite définir la solution matérielle qui y répondra...
Je te donnais juste des idées...
Oui c'est ça,
La carte "mere"(arduino+shield) gérera toutes les I/Os et pour le front-panel (facade pots/encoders/fader etc) il y a un super truc
modulaire que je compte utiliser chez Livid Instruments
http://lividinstruments.com/hardware_builder.php
L'omiBoard
Des Exemples
et ils vendent touts les switchs pot enc fad etc...
une carte coute 15usd et les comps sont pas bien plus cher que le prix marché
Artouste:
onoff:
Artouste:
onoff:
...
Comme je me doutais que les Encodeurs seraient le plus délicat je revois la nombre a 16 en règle générale ils assurent que peu de fonctions :Bonsoir
ce n'est pas tellement ce qu'il sont censés faire qui est là important, c'est surtout de déterminer quel est le taux maximum de changement d'etats pour une periode de temps donnée.
mais evidemment reduire de 64 à 16 les encodeurs augmente le temps de traitement disponible pour les des actions à suivre sur changement d'etat.Bonsoir,
Peut tu approfondir si tu veux bien ? ou me faire un petit schémas ?
A bientot
Djébonjour
ce qui est important c'est de ne pas louper de pas (changement d'etat)
il faut donc prealablement déterminer la capacité max de lecture de changement d'etat de l'arduino.ça passe donc déjà par le choix des encodeurs = nombre d'encodeurs et pas des encodeurs
si l'echelle de temps de scan des états est trop grand , le risque de se retrouver avec des lecture erronées (non lues) est important
avec des encodeurs en quadrature c'est la comparaison sur etat ancien/etat nouveau qui determine le sens du taux d'incrementation.
si la fenetre de lecture est trop large, il y a perte d'information.C'est donc à toi déjà de faire la selection des encodeurs selon ton confort d'utilisation.
comme repondu plus haut : en événements musique/lumiere , le taux de changement d'etats est faible vu du temps, par facilité je le met à ~ +/- 16 changements d'etats max par seconde, ça correspond à un tour sur un encodeur 16/tours
Bien noté mais comme je disait plus haut le nombre de Pot/enc/switch sera variable en fonction des besoins de chaque materiels
Pour le choix des composants je vais devoir utiliser ce que fournit Livid instrument mais je pense que c'est plutot 20/24 pulses par tours
Merci
Djé
Il est sûr que les encodeurs vont "jouer" un rôle important dans le choix technique d'acquisition. Mais là où on peut se retrouver, c'est qu'on n'en tournera qu'un seul à la fois, voire deux. En tablant sur une MEGA qui propose une vingtaine de PCINT, on peut réaliser un truc du genre, avec un encodeur par PCINT. mais il existe des systèmes (comme la ST32F4 par exemple) possédant bien plus de PCINT... Il te faut donc définir les limites maximum de contrôles gérables par ta carte mère (en fonction de la technologie adoptée) puis voir si tu peux y connecter les cartes filles en nombre suffisant.
onoff:
...
et ils vendent touts les switchs pot enc fad etc...
une carte coute 15usd et les comps sont pas bien plus cher que le prix marché
sauf mauvaise lecture de la photo , ce sont de A/B en 24/tours avec "peut être une détente" :
c'est ce qui se rencontre facilement/couramment dans ce genre d'application.
la détente est un contact = l'appui/relache de l'axe de l'encodeur = contact ou disparition
ça peut etre une bonne voie si c'est bien le cas pour initier une interruption differenciée de traitement
