TK.

das war evtl. toetlich fuer das LCD - aber vielleicht hast Du es auch schon beim vorigen Versuch "abgeschossen". :-( Man kann die Leitungen nicht so ohne weiteres durchmessen, man benoetigt das Datenblatt um die Pins auf anhieb so anzuschliessen, dass nichts kaputt geht Gruss, Thorsten.

Generell gilt: Fuer alle assemblerbasierenden Applikationen benoetigt man MPLAB, das leider nur unter Windows laeuft (oder unter Linux via Wine). Doch es gibt eine Bastelloesung, mit der man MPASM Code so zurechtbiegen kann, dass er auch mit GPASM kompilierbar ist, das u.A auch fuer den Mac verfuegbar ist: http://www.midibox.org/dokuwiki/doku.php?id=compiling_the_midibox_source_on_linux&s=mpasm. Die C basierenden Applikationen lassen sich mit SDCC/GPASM kompilieren, beides laeuft auch auf dem Mac. Falls Du mit dieser Info nichts anfangen kann, dann bitte einfach jemanden, der MPLAB unter Windows installiert hat, ob er Dir ein neues .hex File nach Deinen Wuenschen bauen kann. Wenn Du keine Anpassungen am Source Code vornehmen kannst, sind Taster/Encoder/LCD unverzichtbar - es hat noch niemand einen Java (oder aehnlich) basierenden Editor fuer die MIDIbox CV programmiert. Ich habe alles dafuer vorbereitet (die Box ist ueber SysEx konfigurierbar), ich bin jedoch etwas zu bequem, um einen Editor fuer etwas zu programmieren, was ich auch mal auf die Schnelle im On-Screen Menue oder im mbcv_presets.inc File einstellen kann... :-/ Gruss, Thorsten.

Die MIDIO128 kann das AOUT Modul nicht bedienen, es fehlt der entsprechende Treiber. Du koenntest vielleicht einfach mal mit der Analog Toolbox herumexperimentieren Gruss, Thorsten.

it's fine - as you can see, now you should have the possibility to send any MIDI event without asking for code snippets :) Best Regards, Thorsten.

MIDIbox64E can do this since more than 5 years... I don't know for how long those "fancy controllers" exist? Just assign a button to one of the following SFBs: FF 08 40 | Select Parameter with encoder during button is pressed FF 08 41 | Select Group with the first, Bank with the second, Patch with the third | encoder during button is pressed Best Regards, Thorsten.

Hi Xavier, yes, I remember that this was reported by Seppoman (?) some time ago. I still haven't searched for the cause yet, but in general I think that this is a "low priority" issue. You can clear the BankStick with following C program: Init() { unsigned int addr; for(addr=0; addr<32768; ++addr) MIOS_BANKSTICK_Write(addr, 0x00); } [/code] Best Regards, Thorsten.

This resistor is very important, because without T1 would connect it with ground -> short circuit (T1 would be destroyed). Since the impedance of the MCLR# input is much higher than 1k, most voltage will drop over MCLR#->ground and not over the 1k resistor when T1 is open When T1 is closed, nearly the full voltage will drop over the 1k resistor, and MCLR# should be ca. 0.7V Best Regards, Thorsten. Which voltage do you measure without T1?

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.