TK.

You can easily add the code for additional encoders to the normal MIDIbox64 application, it's done in the same way like for MB64E: define the encoder pins in mios_tables.inc, and add a routine which sends MIDI events on encoder movements to USER_ENC_NotifyChange, thats all Best Regards, Thorsten.

You can edit the 128 lable names in lc_gpc_lables.inc If you want to use MBLC as a more generic controller, you can just upload the setup_midibox_ng.hex file of the MIDIbox64E application - it allows onscreen editing, MIDI learn, different LED ring patterns, etc... but it doesn't get use of the large screen, since nobody has adapted the cs_m_display.inc file for two 2x40 displays (or graphical displays) yet Best Regards, Thorsten.

I've merged it with the old topic, because it is not necessary to open new ones, this only leads to a bad oversight in the forum. I'm currently in hurry, maybe I can think about possible problems tomorrow evening. Or maybe somebody else can help? Best Regards, Thorsten.

Welche Applikation laeuft denn auf dem Core? Gruss, Thorsten.

Hallo Basti, es koennte sich hier um einen Kurzschluss handeln. Am besten saemtliche Module (falls bereits angeschlossen) und beide ICs vom Core entfernen, und nochmal messen. Falls dann immer noch ein Kurzschluss auftritt, und Du durch eine visuelle Kontrolle an den Leiterbahnen keinen Fehler erkennen kannst, hilft nur noch das Schrittweise entloeten von "kritischen Kandidaten", die den Kurzschluss verursachen koennten - sprich: Widerstaende und Kondensatoren, die nicht zur Stabilisierungsschaltung gehoeren Das machst Du solange, bis der Kurzschluss nicht mehr da ist - dann weisst Du, woran es lag! Visuelle Kontrolle ist manchmal schneller... Gruss, Thorsten.

It's very similar to the Double Note Example Best Regards, Thorsten.

Before P18 doesn't control the MBHP_BURNER input lines, the status of the LEDs is undefined So, it's time to connect the burner with the PC, and to use the debug window of P18 to check the voltages. Best Regards, Thorsten.

Hm, this lets the question open, why did it work under MIOS V1.8 with the old PSU? Or was this just an assumption (it seems, that effects where more or less random - first it was the edit button, later the filter button which caused the reboot) Slave/Humm: enabling the Link button is important, otherwise the slave won't receive MIDI data. You can debug the slave exactly like you would debug the master core. You can run the MBSID interconnection test, you can interchange modules, you can access the slave directly from a MIDI keyboard or the PC in order to get it running... Best Regards, Thorsten.

Graphical displays don't bring any advantage so long the application doesn't provide a special display mode which gets use of graphical icons. This is currently only the case for MBLC So, a character display is the way to go for non-programmers. The performance is better, but this doesn't really matter so long only buttons have to be handled, and no time consuming tasks are running in background Best Regards, Thorsten.

Ja, es kommt Programmierarbeit auf Dich zu, diese "Schaltlogik" wird von den normalen MIDIbox Applikationen nicht unterstuetzt. Am besten baust Du das ganze auf den C Wrapper auf, dann liegt alles in Deiner Hand Das Problem mit den doppelten IDs kann ich mir nicht erklaeren - dieser Effekt ist wirklich mal was neues! ;-) Das DIN Modul wird unten angeschlossen. Am DOUT Port wuerde es zu einem Kurzschluss kommen (PIC treibt gegen 74HC165 Ausgang) Gruss, Thorsten.

Die +/- 15V gehen ja nur an die Operationsverstaerker - ja, das ist erlaubt. Gruss, Thorsten.

Kann man mittlerweile schon nicht mehr ausschliessen. Hast Du das LCD waehrend des Aufbaus mal falsch angeschlossen? Gruss, Thorsten.

Looks correct, I don't know what else could be the problem. W/o the bridge rectifier you have to take care about the polarity, but I guess that you always did this? Best Regards, Thorsten.

No, this isn't normal, since MIOS scans the encoders each mS, which means, it can determine up to 500 pulses (in theory). In practice I never reached such a high pulse rate... This effect can happen when you've connected the pins of the encoders in the wrong order. Just try the other 2 possible combinations to find out if one of them works better Best Regards, Thorsten.

Ok, does the PIC reboot when MIDIO128 is running and you press the buttons (one after another)? I'm asking you all the questions to find a simple solution how we can continue with debugging. If the reset cannot be reproduced with an application like MIDIO128, you will have to modify the code of MIDIbox SID (based on the instructions I will give you) in order to find out the root cause. If you can reproduce the reboot with MIDIO128, everything will be easier for you (not for me...) What you can also do in the meantime: - upload MIOS V1.9c from MIOS Studio with feedback (to ensure that the MIOS is really complete) - install MPLAB, so that you are able to build .hex files Best Regards, Thorsten.

Hi Robin, I'm relieved that this wasn't a conceptional issue (just thought about how many time you've already worked on it) A timeout can happen if the received message from a MIDI device is not complete. The MIDI stream processor always waits for a the end of a MIDI event before it exits and the main task is continued. So long the last byte of a MIDI event haven't been received, it stays in a time out loop, which will be terminated after 2 seconds to notify a malfunction of the MIDI sender So - it makes sense to check the code of your "SysEx core" if it could send incomplete SysEx streams or other events. Unfortunately a MIDI monitor like MIDI-Ox cannot help so much for debugging here, because it has the same "problem" like any other MIDI processor - it waits for complete events before they will be displayed. Therefore it's maybe better to temporary disable parts of the MIDI sending routines until you find out, which one causes the timeout Best Regards, Thorsten.

It's better without the external oscillator, see also http://www.midibox.org/forum/index.php?topic=5748.0 Best Regards, Thorsten.

Hi Alex, check the encoder entries in mios_tables.inc, maybe you've still assigned an encoder to pin 0 and 1 - this overrules the button handler. Best Regards, Thorsten.

In this case you also need a meta event which cycles between the values Best Regards, Thorsten.

Hi Robin, I'm not sure, "2 second delay" sounds like a MPROC timeout. Before we continue the discussion, could you please fill the NotifyTimeout function in this way: void MPROC_NotifyTimeout(void) __wparam { MIOS_LCD_CursorSet(0x00); MIOS_LCD_Clear(); MIOS_LCD_PrintCString("TimeOut!"); MIOS_LCD_MessageStart(255); } [/code] Do you see the Time Out message on the LCD when the delay happens? Best Regards, Thorsten.

It just came in my mind, that I misread your posting (MIOS_SRIO_UpdateFrgSet was missleading - it doesn't help). I think the general problem is the slow transfer speed of MIDI. Each MIDI byte takes 320 uS, 1000 bytes are taking 0.32 mS, and if your program sends multiple dumps with one button push, we have the explanation, why it takes so long. Only the number of bytes beeing sent for the CCs could propably be optimized by using the "running status" feature. Instead of sending "B0 mm nn B0 oo pp B0 qq rr", you can also send "B0 mm nn oo pp qq rr" (the last status byte will stay active) But in general the MIDI interface of your synth is the bottleneck, it's not possible to increase the baudrate here, thats the problem The USB interface cannot be serviced from a PIC, since a "USB host interface" + appr. drivers are required. A general question: do you always send dumps and CCs on button movements, regardless if they already have been sent with the same content/values? Maybe you could optimize here - only send values which have been changed. I don't see much more possibilities for optimisation here w/o using a PC as USB host which works as a bridge between the PIC and the synth, Best Regards, Thorsten.

Hi Robin, is the debouncing activated in your application? This could explain everything. There are two solutions: either set it to 0 (in this case, the buttons are not debounced anymore, but the outputs are also not delayed anymore) - or update to MIOS V1.9c In your case, you have to select the pic18f452/midi/update_with_old_mios.hex file (don't upload any other of the update package!) Best Regards, Thorsten.

Das sieht irgendwie nicht so toll aus! Bei einem falsch angeschlossenen LCD wuerde ich eher zufaellige Zeichen aus dem Zeichensatz erwarten, hier sehe ich jedoch mehr als 8 "Sonderzeichen" (mehr sind nicht moeglich). Ausserdem scheint es so zu sein, dass ein paar Zeilen voellig fehlen. brauchst Du eigentlich nicht, wenn Du den LCD interconnection test richtig anwendest. Hiermit kannst Du ohne Loetarbeit jede einzelne Signalleitung durchchecken (bitte main.asm lesen) Lassen sie sich gezielt ansteuern, misst Du immer 5V? Gruss, Thorsten.

kein Problem :) Gruss, Thorsten.

I will write more about my own experiences once I got a new set of LEDs (green/red duo LEDs - available @Reichelt for 0.15 EUR) Best Regards, Thorsten.