dubstructor

Had exactly the same problem at the beginning. It turned out to be a faulty LCD...

My mistake, I forgot that the PNP conduct when the base potential is LESS than the emitter one. Some little workaround to do.

"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).

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 ?

: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.

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

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.

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

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 ?

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

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 .

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.

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.

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

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

Hi jimhenry ! Should have come to this as I saw both 74hc165 and 595 ics on the 'midibox kb' schematics :-[ There are actually diodes on each line whose anodes point in the direction of semi-octave pins, so those are to be seen as lines, right ? OK, sounds normal. Just one more question : does it matter if the contacts are not 0 ohms ones, but ca. 850 kohms ( :o ) ? As I said, kind of a conducting rubber.... if yes, is there another way to get rid of that than replacing them with metallic surfaces ? OK, thanks a lot for opening my eyes. Peace. Dubs

Hi clem, thanks for your answer. Meanwhile I've found something interesting, the midibox KB. Actually a kind of "scan-matrix". Adapting the code will be no problem but the main issue is rather hardware : this keyboard doesn't really behave like a scan-matrix, like two pins switching on when you hit a key (one for the semi-octave = the line, and one for the note inside this semi-octave = the column), but those two pins go connected to each other ! Rather exotic. I think I go screwing some lines in the keyboard inner circuitry, and replace the contacts with two-poles switches, in order to have a good ol' well-known scan-matrix. The pss-595 is not velocity sensitive (sigh ! but I would have been even more disappointed to have a velocity keyboard I cannot use) but anyways I'm going straight to look for qbas, maybe eventually it will serve. Last detail : it is said on the notice that up to 29 keys polyphony can be achieved. I don't understand at all how the pss main board deals with it, but all that I can say is that the keyboard is directly connected on two AN90b22 which are basically arrays of commuting transistors. And that's it (multiple-faced circuit >:( ). (BTW did someone already use those ICs in a matrix-type kb ?) Thanks again clem. Peace Dubs

Yes ! Oui effectivement j'avais pas vu ça. On en apprend tous les jours ^^ Bon effectivement il va me falloir quelques adaptations, le plus chaud étant que mes broches fonctionnent par paires, ce serait tellement simple si c'était un système lignes/colonnes (dans mon cas, demi-octave/note) ; mais du coup je peux adapter la circuiterie interne du clavier pour aboutir à ça et pomper le schéma du KB. Concernant la polyphonie, je sais pas comment la carte du synthé se débrouille mais sur la notice (téléchargée) ils vantent une polyphonie max de 29 touches ! J'ai du mal à piger comment ils peuvent retrouver sans ambigüités sur les octaves, les 29 touches en scannant toutes les paires possibles - par exemple, si on détecte une impédance basse entre les paires 2-10 et 1-11, comment faire la différence avec la combinaison de touches qui mène à 1-10 et 2-11 ? (J'ai vérifié, les impédances en cas d'appui sont toutes légèrement différentes, mais les différences sont aléatoires, donc la carte ne peut pas se baser là -dessus). Tout ce que je sais, c'est que le port du clavier passe d'abord par deux AN90b22 qui ne sont que des boîtes de transistors en commutation. Et ça s'arrête là parce que le circuit est en double-couche, après j'y comprends plus rien. 'fin bon bref j'ai fait un petit calcul : sur 49 touches, avec un tel système, on peut avoir une polyphonie de 3 notes sans gros risque d'erreur, après ça se gâte ; ce qui correspond à peu près à ce qui est dit sur le midibox KB, donc je pense qu'effectivement c'est une bonne piste, et de toute façon mes talents de pianiste ne nécessitent pas 15 touches en même temps... Donc bon merci beaucoup matoz je vais creuser dans cette direction. Peace

Salut les midiboxeurs, bon je reposte cette fois en français, on sait jamais. Alors voilà le truc : J'ai trouvé y'a pas longtemps dans une poubelle un yamaha pss-595 désossé. Comme je ne pouvais pas décemment le laisser aux rats, je l'ai ramené chez moi pour essayer d'en faire quelque chose. Ce qui m'intéressait surtout, c'était le clavier lui-même, parce que la jouabilité du jeu de boutons de ma midibox ou de mon clavier d'ordinateur laissent à désirer. Donc j'ai d'abord voulu essayer le clavier avec la carte électronique du synthé, qui n'avait pas l'air trop défoncée et qui avait le bon goût d'avoir déjà des ports midi. J'ai effectivement eu des messages note sur mon pc, seulement, la carte déconne et ce n'est pas une panne de base, vu la jam que ça me met, ce sont les contrôleurs qui sont morts. Donc j'ai regardé comment fonctionnait le clavier lui-même, dans l'espoir de pouvoir le connecter sur mon DIN. Et là je suis en panne d'idées ... C'est donc un clavier 49 touches, bien sûr, je pourrais remplacer sa circuiterie interne par 49 bon vieux contacts, seulement, il me faudrait un paquet de nouveaux 165 sur mon DIN, et vu le fonctionnement je suis sûr qu'il y a un moyen de ruser... Donc ce clavier sort sur 15 broches, qui fonctionnent de la manière suivante : - les 9 premières correspondent chacune à un ensemble de 6 touches contigües (soit un demi-octave) - les 6 dernières correspondent à quelle touche est pressée parmi ce demi-octave. Par exemple : pour la touche la plus grave (un Do0), on a une connection entre le pin 1 (premier demi-octave) et le pin 10 (première note du premier demi-octave). pour la touche juste au-dessus (Do#0), connection entre pin 1 et pin 11 . ... pour la 6ème touche la plus grave (Fa#0), connection entre pin 2 et pin 10. etc ... Mais attention ce ne sont pas des connections "simples" : quand la touche correspondante n'est pas pressée, l'impédance qui existe entre les 2 broches est bien infinie, mais elle n'est pas nulle quand la touche est enfoncée : elle est à peu près de 850 kohm. Y a-t-il un moyen quelconque d'adapter ce schéma de fonctionnement sur le DIN ? (j'ai pensé à utiliser un tableau de transistors, et/ou de remplacer les contacts, faits d'une sorte de caoutchouc conducteur mais fortement résistif). Je me pose cette question seulement parce que l'aspect matriciel du fonctionnement de ce clavier pourrait m'épargner beaucoup de circuiterie DIN, donc de place. Pour l'aspect programmation, ce n'est pas un problème, j'ai déjà ma petite idée concernant la gestion de la polyphonie. Bon, si personne n'a d'idées, je me résoudrai à m'acheter de nouveaux 165 et à re-penser l'intégration du DIN. En attendant, je n'espère pas une solution complète, seulement des idées, des suggestions seraient bienvenues ... Merci d'avance. Dubs

Hi midiboxers, let me explain this mysterious title. Having recently found a disassembled yamaha pss-595 in a trash bin (!) I couldn't decently leave to rats, I brought it back home to see what I could do with. Most of all I was interested by the idea of playing on a real keyboard, instead of the bunch of switches I'm using. (My computer keyboard does this too, though a bit non-intuitive). I first tried with the electronic board (with built-in midi ports), which was seemingly complete and in a rather good state, and I actually got midi note messages sent to the computer. Only, it behaves too strangely to be playable .... sometimes it works, sometimes not, sending random notes, forgetting some note-offs, and it rapidely comes to crashdown until I switch it back on. Plus, I tried it as standalone, but integrating it in my midibox would involve the use of a merger, and I'd rather keep the building of a merger for more serious needs.... So I studied the working scheme of the keyboard itself, to connect it directly on my DIN module. That's where I need some ideas, because I miss so imagination here.... So this is a 49 keys keyboard, of course I could replace the circuitry with 49 contacts then connect it directly to the DIN, only this would involve ordering some more 165's and I'm pretty sure there is a way to "cheat". The keyboard output is a 15-pin port, and here's the way it works : - the first 9 pins each correspond to 6 contiguous keys (one semi-octave) - the last 6 pins are for which key in a given semi-octave is pressed. That means, when you hit the lowest key (C0) for instance, a connection occurs between pin 1 (lowest semi-octave) and pin 10 (first key of lower semi-octave). When you hit C#0, these are pins 1 and 11 that are connected ; when you hit F#0 (the sixth lowest key), these are pins 2 and 10 (first key of the second lowest semi-octave), and so on (please let me know if those explanations are not clear, I'll try to make a drawing). Not to simplify things, these are not simple connections : the impedance is infinite when the corresponding key is not pressed, but around 850 kohm when it's pressed. Is there any way to turn this working scheme into one interpretable by the DIN ? (I thought of using transistors .... or replacing the contacts, which are made through a sort of conducting high-resistive foam). I only ask this question because I find this "matricial" aspect very interesting, it could spare me many DIN circuitry, that's a matter of space (I would deal later with the programmation aspect, especially in the polyphony handling when playing chords). If nobody can show me the way, I surrender and go for new SR and a re-conception of my DIN module. I'm not looking for complete solution, just clues, ideas, or suggestions are welcomed.... Thanks by advance. Dubs

Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah (kbits==kbyte/8?"YES YOU GOT IT!":"no poor loser.") Uuuuuh looks like the datasheet ;) OK except I don't understand the word "chunk" and am actually drunk at white rhum I think I get it lylehaze. Won't bother U anymore (maybe) What would I do without ya :D ?

Hi there ! So here's the plot, I'm using a single, 24lc512 chip as bankstick, and guess what, I have NO problem writing and reading it ! Wonderful. I was just wondering something, tried to look for it on both forum and wiki, but it doesn't seem to bother anyone .... So here's the question : with the MIOS_BANKSTICK functions, one can access adresses from 0x0000 to 0xffff, right ? So if I compute well, 65536 bytes. But in a 512k bankstick, shouldn't there be 512*1024 = 524288 bytes ? Ie, eight times 65536 ? Note, that's not really a problem since my apps usually don't need more than a couple thousand bytes on ROM. But I'd like to understand.... Thanks to anyone who'd kindly waste a little time explaining. Blessings

Are you using real MIDI cables ? Or a home made pair of twisted wires like I first did ? Because I had the same problem than you, correct midi request (are you sure you set the good ID ? The number at F0 00 00 7E 40 XX 01 F7), first block then... nothing. It all solved when I used MIDI cables and sockets - after some experiments on polarity though. Just to be sure : - if you use a gm5, when viewed from above, the left socket is gm5's midi in (that you have to connect to core's midi out) and I let you guess what follows for the right one. - the sockets on my core are soldered like shown below. If it still doesn't work though, or if you're already in the right configuration, just do the test in 3 and let us know (beware particularly of the LED polarity - it should lit). If datas actually reach your PIC, this LED should flicker when, for example, you use the keyboard tool of miosstudio and hover your mouse on it. You've got to well observate the LED because the flickering is not obvious, since it's a normally lit LED. The more events you send at a time, the better it is. You can also send a sysex with midiox if you know how to do this. If it doesn't flicker, check your MIDI device routing (the surest procedure is : restore default internal routing - open the midi device routing window - link your device IN LEFT PANEL to "MIOS studio IN port" in the right one, and "MIOS studio OUT port" IN LEFT PANEL to your device in the right one.), then retry to send a big amount of datas the way you want. If it still doesn't flicker, maybe your opto is broken - there's some tests in the troubleshooting guide to figure it out, or maybe datas don't even reach it : you can do the test in 5 to see if datas are actually available after your core's midi in . With all that, you should at least know if the problem is before the core, between the core's in and the pic or in the PIC itself. I assume there's no problem in your midi out path (from core to PC) since you do see the sysex. core midi sockets pinning.JPG core midi sockets pinning.JPG

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH IT WORKS !!!!!!!!! I *** LUV Y'ALL **** GUYS !!!!!!!!!!!!!!!!! Hmpffffffff .... OK breathe in, breathe out, let's go . I made all my tests using my first PIC. Right there I just stuffed smash' one, though I thought both of them were OK since I had the startup sysex on both. Hence I also thought that I could have spared one month. And.... it appears that waiting for smash' wasn't such a waste of time after all because when I tried it, then uploaded my tiny app, this marvelous wonder I have been running after for such a long time finally occurred : I can now control plugins buttons of my favourite DAW with my own hands !!!!! It's fantastic !!!! I'm so glad, you cannot imagine the strength I feel in myself right now (of course you can, I guess all of you went through the same things than I just went through). It's now confirmed that my LCD is out of order, but who cares ? So bless ya TK who, with your great sense of standardization and your pedagogic skills, made totally affordable for everyone the world of PIC programming ; lylehaze for your precious, accurate and very well shared electronics knowledge ; smash for your perfect material (whose I never doubted though, again) , and every other who contribute to make this a real community where you can feel there's always someone ready to help you, give you the idea you didn't have, in one word where you never feel alone and lost in this hostile 0 and 1 jungle. EDIT : I know this looks like a congrats' speech from a Grammy awards. But I guess I wouldn't be happier if I had won one ;)

Yeah thanks a bunch you've really helped me a lot. Concerning your suggestions, I already began my quest for the thread that fits me, because I just realized I'm out of the subject of this topic. Nevertheless, it seems not to be as much an LCD issue than a 'general' issue, since, LCD left apart, I should have a reaction on pot tweaking with my app, and anyways, any other app I've tried is well uploaded, but not active. But yeah now troubleshooting is mine, so let's shoot troubles, one by one. "Gonna fiiiiiiind you, and take it slowly" (fugees loud in my ears ^^) EDIT : TK I've tried to re-upload the MIOS. Once again the upload worked well, but it doesn't solve the problem. Besides, my own code begins at 0x3000 like expected. I keep on searching. You're right, it gets better every step. I'm far more released from doubts than two days ago. Again, a big thanks for your support and advices. Keep on having fun too !