Jump to content

dubstructor

Members
  • Posts

    45
  • Joined

  • Last visited

About dubstructor

  • Birthday 01/01/1

Profile Information

  • Gender
    Not Telling

dubstructor's Achievements

MIDIbox Newbie

MIDIbox Newbie (1/4)

0

Reputation

  1. Had exactly the same problem at the beginning. It turned out to be a faulty LCD...
  2. My mistake, I forgot that the PNP conduct when the base potential is LESS than the emitter one. Some little workaround to do.
  3. "De ce que j'ai pu comprendre, il dit que quand il presse le bouton de mute, la led s'allume temporairement et qu'elle s'éteint quand il le relache, et le mute se désactive également. Donc je suppose qu'il nous demande si il devrait utiliser un bouton à bascule, ainsi le mute deviendrait actif et le resterait après une pression-relâchement du bouton, et redeviendrait inactif lors d'une nouvelle pression." (oui tiens y'a aussi cette solution, j'y avais pas pensé : y'a des boutons, t'appuies une fois, hop c'est on, une autre fois, hop c'est off, et tout ça de manière mécanique sans avoir à le gérer en soft) "Je suppose à travers son 'englais de pigeon' que c'est ce qu'il veut dire" (pas très gentil tout ça). "Je pense que le problème vient de la façon dont le logiciel hôte traite la commande. Je n'en suis plus certain, mais je crois que le LC envoie un signal "OFF" quand le bouton est relâché. Il a probablement juste à configurer l'hôte pour ignorer ces messages "off", ainsi la fonction mute bascule à chaque signal "on". Je sais comment configurer ceci dans Sequoia.... j'ignore comment c'est pris en charge dans d'autres application, ni quelle application djahan utilise." Donc : 1 - est-ce juste un problème de LED ou est-ce que le problème concerne aussi l'action, à savoir le muting effectif d'une piste ? 2 - quel logiciel ? 3 - y'a-t-il une option pour ignorer les messages midi off ? 4 - si non, investis dans des boutons à bascule (latch en anglais).
  4. Ouais. Et achète quelques écrans supplémentaires pour en mettre dans tes chiottes, ta salle de bain et ta cuisine. Bon plus sérieusement je me suis un peu penché sur la question, et bien que ce que je t'ai dit n'était pas faux, l'application lc est malheureusement entièrement codée en assembleur, pas même un petit main.c pour y fourrer son grain de sel :( Pour des raisons personnelles (et parce que nom de dieu, j'aime bien comprendre ce que je fais) j'apprends actuellement l'assembleur, si t'as le temps et le courage, google les cours de bigonoff. Bon après j'ai vu le fofo anglais, alors c'est clair que ton anglais est pour le moins .... euh ..... hésitant :P , mais franchement y'avait pas la moitié des réponses qu'étaient pertinentes (après, peut-être qu'ils n'ont pas pigé la question). lc_io_tables machin truc ou je sais plus quoi, faut oublier. Basiquement c'est pas là -dedans qu'on gère le comportement "toggle" d'un bouton (ce que tu cherches à faire). Un bouton est perçu par le contrôleur suivant son état, enfoncé, relâché, point c'est tout. Il faut nécessairement créer une routine dont le fonctionnement est ce que je t'ai expliqué, c'est pas juste un paramètre du contrôleur. Mais de toute façon y'a pas vraiment de question à se poser : d'après ce que j'ai compris (l'app lc ne faisant pas partie de mes projets) c'est le logiciel hôte qui allume/éteint les LEDs. Apparemment tous les voyants dépendent de ce que le logiciel renvoie comme midi in. Donc..... c'est au niveau du paramétrage de ton logiciel que ça se passe. Et en tout premier lieu : est-ce que le logiciel que tu utilises renvoie bien des données midi à ton contrôleur ?
  5. :D :D :D :D :D :D :D Bin je veux ouais ! J'ai failli attendre ! 2h20 pour un message posté à un petit 4h du mat'. Inadmissible. Où va-t-on si les midiboxeurs sont pas 24/24 au taquet derrière leurs écrans. N'importe quoi.
  6. And what do you guys think of this ? Q0 is a basic NOT door. Input low : - pin 1 left floating, X value is pin 1 measurement . - pin 2 set to ground . - pin 3 set to +5V, pin Y discontinued, should keep the previous value (measurement) of pin 3. - pin 4 left floating. Input high : ..... So, continuous X and Y values ? Or total mess ? (Not sure about the behaviour of Qx and Qy emitters when the base is low. In the worst case, I'd leave them apart and on AIN_NotifyChange only consider those two pins half of the time; or putting some RC filter to reject jitter ... But what is the main part of this circuit worth ?) xy switcher.JPG xy switcher.JPG
  7. Je ne sais pas si quelque chose a déjà été implémenté pour le faire automatiquement, mais voici ma solution. En utilisant la fonction MIOS_DIN_NotifyToggle(), le contrôleur réagira à chaque changement d'état du bouton, c'est-à -dire aussi bien à l'appui qu'au relachement. Dans ce cas, il n'y a pas besoin de mémoriser la valeur (on ou off) envoyée par le bouton, puisqu'elle correspond à l'état du bouton. Ce que tu cherches, au contraire, nécessite de se creuser un peu plus la tête car il faut mémoriser quelque part cette valeur. Que tu veuilles allumer ou éteindre ta LED, l'action sera la même : appui - relâchement d'un bouton. Donc, physiquement, rien ne distingue l'action "éteindre la LED" de l'action "allumer" : il faut une information supplémentaire. La solution que j'ai trouvée est (pour simplifier) de stocker les états des LEDs dans un tableau, que j'initialise à zéro. Dans DIN_NotifyToggle(), je ne traite l'appui sur le bouton QUE lorsqu'il est enfoncé, pas relâché. J'inverse alors en mémoire l'état de la diode correspondante, puis je mets le flag d'affichage à un, pour pouvoir traiter ce changement d'état lors de l'appel de DISPLAY_Tick(). Et c'est dans DISPLAY_Tick que je colle la routine qui gère l'allumage/extinction des LEDs, via la fonction MIOS_DOUT_PinSet(...). Ce qui donne en gros (dans main.c) : .... //exemple pour traiter 8 boutons devant se comporter de cette façon #define NB_LEDS 8 .... unsigned char led_status[NB_LEDS] ; .... void Init() { .... unsigned char i ; for(i=0;i<NB_LEDS;i++) led_status[i]=0 ; //toutes les LEDs éteintes au début. Bien sûr tu peux aussi en avoir certaines allumées //au début de l'application app_flags.DISPLAY_UPDATE_REQ=1 ; //voir la fonction DISPLAY_Tick. Flag de requête de rafraîchissement d'affichage. ..... } void DISPLAY_Tick() { if(!app_flags.DISPLAY_UPDATE_REQ) return ; //signifie : ne rien faire et immédiatement quitter la fonction si le flag de réaffichage est à 0 . app_flags.DISPLAY_UPDATE_REQ=0 ; // on réinitialise le drapeau ....... unsigned char i ; for(i=0;i<NB_LEDS;i++) MIOS_DOUT_PinSet(i,led_status[i]) ; //ici est l'instruction qui allume ou éteint directement les diodes ...... } void DIN_NotifyToggle(unsigned char pin,unsigned char pin_value) { switch(pin) { case 0 : .... break ; case 1 : .... break ; case 2 : .... break ; //tout ça dépend de quels numéros sont attribués aux boutons qui nous intéressent ici. // par exemple, admettons que le pin n° 23 soit le bouton qui commande la LED branchée sur le pin n° 4 : case 23 : if(pin_value) break ; /*traduction : si le changement d'état qui a amené à l'appel de cette fonction vient du pin 23 et que sa valeur actuelle est non-nulle, ça signifie qu'il y a 5V sur ce pin, donc qu'il n'est pas connecté à la masse, donc que l'interrupteur est ouvert, donc qu'il vient d'être relâché. Donc : break (ne pas traiter les instructions suivantes du case). Ou même return à la rigueur, comme ça on ne perd même pas de temps à traiter inutilement le reste de la fonction. Note bien au passage que pin_value vaut 0 quand le bouton est enfoncé, 1 sinon. 0=ON, 1=OFF (!) */ led_status[4] = !led_status[4] ; //dans le cas contraire, inversion de l'état de la LED 4 ; flags.DISPLAY_UPDATE_REQ=1 ; break ; ...... } Voiloù. Bon ce code n'est pas parfait (notamment dans le fait d'utiliser un unsigned char d'un octet pour stocker une valeur qui ne peut valoir que 0 ou 1) mais c'est juste pour avoir l'idée. J'insiste sur le fait qu'ici on traite uniquement de l'affichage au niveau des diodes, concernant la véritable action du bouton, il faut ajouter le code correspondant (le tableau led_status peut être recyclé pour d'autres usages). En espérant avoir été utile et pas trop lourd à lire .... Dubs.
  8. Wow :D ::emoted:: lucem : thx for the explanations. In fact, there is a debouncing routine in here, quite transparent since, even with my close-to-zero asm skills, I successfully adapted it to my buttons behaviour. My bad, I've looked at things a bit too rapidly. Sorry for the programmer who sweated on things I didn't even notice. First time ever I write some asm code. Well, "it isn't that difficult after all", I thought. But I tried with all my goodwill to understand how the driver scans the io pins, and even if I understand the basis, I'm totally unable to solve this problem : how can I use both sm and normal pins ? Well, time for me to finally set myself in asm mode. So I've begun reading bigonoff's lessons. Won't hurt. Anyways I would still greatly appreciate if someone could point me in the right direction. Maybe I eventually move this to the mios programming section. Scanmatrixly yours. Dubs
  9. Awwwww too bad.... Nevertheless, I may be wrong but it seemed to me that the SID V2 (whose I actually haven't got into yet because I eventually plan on building a V1 on a 452) combines both sm and classic buttons? OK, time for me to REALLY get into asm to see how that works and look for possible workarounds... On debouncing, I think there's some code already, but I'd like to improve it since lazy fingers walking on the keyboard sometimes trigger a note even with a very weak touch. Well, I think I just have to decrease the sensitivity. Looking for it though, I found something very interesting and complete on the matter, might eventually be of someone's interest : http://www.ganssle.com/debouncing.pdf You noticed it too ?
  10. Hi back fellows ..... Finally made it after the midibox kb schematics, adapted the code a little bit and .... THIS KEYBOARD STUFF WORKS PERFECTLY 8) !!!! Still a few questions though (only for those who are into scan-matrixes and asm programming) : Where do I have to specify the DOUT/DIN pins which are dedicated to either sm or "normal" use ? Cuz' for now, I can't use keyboard + normal buttons . Is it possible to add some debouncing in the code ? I mean, regarding the 18f452 abilities ? (I didn't actually understand that much how the sm drivers work since their guts are out of some asm stuff and for now only C talks to me :-[ ) Well .... that's pretty much of it I guess. Thanks to everyone that made it possible ;) Thanks to everyone that'll help me bring it to perfection Thanks to my mother :D Peace. Dubs
  11. OK so now we definitely ARE on the same board ;) I'll make my experiments with midibox kb this week-end. BTW, maybe you can have a look on a datasheet for your synth ? Good holidays! Peace, Dubs .
  12. Errrrr.... Finally made this basic test, and .... I don't know how neither why but the voltage drops to ca. 0,7 V when a key is pressed .... with 10k pull-ups :o :o :o :o :o OK, I'm now dealing with the SR connecting.
  13. Hi SIDsyndrome, that's actually exactly what I'm trying to do with a broken synth I found in a trash bin. Does your synth have MIDI ports ? Mine have, but sadly they're unusable because of some issue with the synth µcontrollers. However, would they work, I thought about two different solutions : - sending synth MIDI out to your PIC Tx pin, via optocoupler and so on, then somehow programming your PIC for turning the incoming midi messages into something readable by the device you're attempting to control .... but this would assume a rather unusual connecting scheme, where your PIC would send midi to another device than the one it receives midi from, and I wouldn't advice it (unless someone more reliable than me in this domain says the contrary ....). Clearlier (I hope ...) : basic scheme : control surface -> DIN/AIN/... -> PIC) -> MIDI out -> (controlled device ) <- MIDI in <- ( modified scheme : your synth ) -> MIDI out ----------> PIC) -> MIDI out ------------------------> (controlled device ) <- MIDI in left unused] ) <- no MIDI in from controlled device] ( DON'T TRY THIS unless someone-who-knows tells you to do, it might lead to your pic destruction. BTW, it will prevent you from doing the loopback tests if you're not already sure your core is properly working. Here comes the second solution : first ensure that the MIDI messages are the ones you want, typically note on/off, by midi-plugging your synth directly on any device that can show you the messages actually sent, like a pc with miosstudio. Then, go to the merger page to see how you can merge your midibox and your synth messages. AFAIK, this will probably be achieved by using a second PIC (well, if I understood well, you can use the same PIC for both merging and your application, depending on your programming skills, but this could dramatically slow down its performances.) /////////////////////////////////////////////////////////////////////////////////////////////// OR you don't have midi ports, or don't want to use them. Time to play the screwpull and meter. You have to disassemble the keyboard from your synth, then see : - how it was connected ; - how is its inner circuitry designed ; - what happens when one or more keys are played (the previous step normally already gave you at least a clue for that). For instance, it appeared that mine basically works as a scan-matrix. What about yours ? One more time, I precise that I have good basic electronics skills, but the world of PICs is still a step beyond that I haven't reached yet. If you're planning on using your keyboard as a standalone MIDI device for controlling your SID, then wait for wiser advices. If you're hoping to use it only as a control surface directly talking to your PIC w/o any midi in-between, then you have to understand how the keyboard works. I'm only sharing my ideas because we're on the same ship. Hope that helps. Peace, Dubs.
  14. Hi jimhenry ! Know, i'll surely give up before having to buy the whole yamaha factory ;) Actually I think these are the normal impedance since the rubber on every contacts of both keyboard and motherboard is highly resistive. Plus, when I plug the keyboard on its original board and the board via midi to my pc, I do have midi note messages - before one asks, yes, I have the half-working original synth board, but I tried all possible ways to fix it, successless. According to its strange behaviour, my guess is it's been thrown down because of built-in µcontrollers problem. I actually know a little bit on resistor bridges theory, so I guess that the pull-up resistors have to be at least five times as resistive as those 850 kohm ones ? Ie, round 4 or 5 Mohm .... but like you I think this would limitate the current to hardly for the registers to work well .... Well, anyways I've got to check it out. And if that doesn't work, I'll try my contacts replacing workaround. Thanks for all that help ! Peace. Dubs
  15. Alors pour ceux qui passeraient par là et se poseraient les mêmes questions : hé beh en fait y'a pas de souci, c'est typiquement le fonctionnement d'un clavier de type "scan-matrix". Comprenez bien : je pensais jusqu'à maintenant qu'une scan-matrix fonctionnait de la manière suivante : une partie des pins pour les lignes, une partie pour les colonnes, et quand vous pressez une touche, le pin ligne et le pin colonne correspondant deviennent ON, et basta. C'est-à -dire qu'on ne devrait observer aucune connection entre ces deux pins, juste un changement d'état logique de chacun des deux, mais de manière indépendante. Or, le vrai fonctionnement, c'est que la partie ligne doit être relié aux sorties (DOUT), et la partie colonnes aux entrées, ce qui explique cette connection observée entre la paire de pins qui correspond à la touche activée. Je commence vaguement à piger comment tout ça fonctionne mais pour les explications, on verra plus tard :P
×
×
  • Create New...