TK.

There is probably a problem with the RC signal between core module and the DIN shift registers. This signal latches the values before shifting, and if it isn't connected you will get random values. Beside of this: are you able to control the LEDs by sending MIDI notes to the core? e.g. with the virtual keyboard of MIOS Studio... ensure that channel 1 is connected. The core will output debug messages whenever a matching event has been received, and the LED state should change. Best Regards, Thorsten.

Mir ist klar was Du meinst, Du hast voellig Recht - ich werde die Verdrahtung entsprechend aendern! :) Gruss, Thorsten.

Yes, J4A is free for IIC accesses. Handling the IIC_MIDI interface requires a bit more code, see this test app: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fmios32_test%2Fiic_midi_check%2F The RI signals if the IIC_MIDI modules have to be connected to J10.D0..3 (see the LPC17 configuration in mios32_config.h) Best Regards, Thorsten.

Yes: meanwhile I added a patch change mechanism which can be synchronized to the MIDI clock (e.g. change before the next 16th note will be played), and which can be controlled from a Lemur Matrix! Very nice in conjunction with Bassline sequences! :) There is still no HW control surface, but I will probably implement another editor with Ctrlr so that MBCV can be configured with a common computer as well. Best Regards, Thorsten.

In the first configuration the LPC17 core isn't recognized because you enabled the MIDI merger of the PIC based core. As recommended at the end of my last post, the MIDI merger should be disabled! It causes a feedback loop (MIOS Studio->LPC17->PIC->LPC17->MIOS Studio) for any SysEx command which is not processed by the PIC itself (and therefore not filtered) In the second configuration the PIC based core isn't recognized because it doesn't receive the Query request. In this configuration it probably doesn't receive any MIDI event (as you haven't configured the MIDI router accordingly), therefore you also don't have a feedback loop here and LPC17 can be addressed. Anyhow, disabling the MIDI merger will do the trick. It was a nice feature for serial MIDI chains, but now you are using a point-to-point connection to your PC through the LPC17 core. In such a configuration the merger causes an unwanted feedback loop. There is no device list, only a list of MIDI IN ports, and another of MIDI OUT ports, which are maintained by your computer. Best Regards, Thorsten.

Hallo Jo, Danke fuer den entscheidenden Hinweis - jetzt weiss ich, was bei Acul schiefgelaufen ist (was ich jetzt nicht als Vorwurf verstanden wissen moechte ;-): in meinem urspruenglichen Schaltplan waren DIN und DOUT, sowie die Polaritaet der Dioden, vertauscht, weil ich ihn von meinem MicroKontrol Keyboard abgeleitet habe. Doch fuer das Fatar-Keyboard war er ungeeignet. Wir haben dann die Polaritaet am DIN Modul (-> PullDown), sowie die Scan-Routine geaendert, doch das war eigentlich die falsche Massnahme. So waere es bspw. nicht mehr moeglich gewesen, die Optimierungsmassnahme durchzufuehren, bei der eine MKx Reihe nicht gescannt wird, wenn die dazugehoerige BKx Reihe nicht aktiv ist. Deshalb habe ich den Schaltplan nun nochmal ueberarbeitet. Ausserdem habe ich noch weitere Schaltplaene erstellt, damit hier nichts durcheinander kommt. Wie bspw. die Verdrahtung von den verschiedenen Fatar-Keyboards. Fuer die 76- und 88-Tasten-Version werden zwei DIO_MATRIX Module notwendig sein (oder ein DINX4 und ein DOUTX4). Die nicht genutzten Ein- und Ausgaenge stehen fuer andere Zwecke zur Verfuegung, bspw. fuer zusaetzliche Tasten, aber auch LEDs Die gesammelten Werke befinden sich hier: http://www.ucapps.de/midibox_kb.html @ADK: "Keyboard Type #3" entspricht Deinem Anwendungsfall! Vorsicht: die Dioden wurden gedreht!!! (Ich hoffe, dass Du noch nicht mit dem Loeten angefangen hast) Gruss, Thorsten.

Here the link to the schematic for the 3rd and 4th MIDI IO: http://www.ucapps.de/mbhp/mbhp_core_lpc17_midi3_midi4_extension.pdf Since you've a programmer status, you should know where to find the source code and how to modify it... ;-) Best Regards, Thorsten.

Of course, you have to select Device ID 1 in MIOS Studio whenever you want to establish the communication with a(ny) core which is assigned to this ID The router just forwards the MIDI stream, no modification of the data takes place, and this for very good reasons. In other words: with the router configuration you are using the MIDIO128 application (running on the LPC17 core) acts like a common MIDI interface, and therefore you also have to setup MIOS Studio like of you would contact the PIC core through your normal MIDI interface. I (wrongly) assumed that this was clear enough... On the other hand I'm surprised that you never tried this during the tests. Could it be that you mixed up the PIC core with device ID 1 and 2 multiple times and always tried the same device ID? However... finally SOLVED! :thumbsup: should be disabled! Best Regards, Thorsten.

Fine! :) As proposed this is the most simple solution. Best Regards, Thorsten.

The default configuration is working perfectly with ALPS RSAON11M9 when the motors are supplied at 5V I'm using exactly this configuration for my MBLC. Heat: maybe the input voltage is too high. The voltage difference between J1 and J2, multiplied with the current, will be translated into heat! Does this happen with the default configuration? If this isn't related to the configuration, it sounds a bit like if you would use faders with logarithmic scale (do you know how to determine this?) -> won't work, linear faders are required! Best Regards, Thorsten.

got the reminder! ;) Best Regards, Thorsten.

Adding PitchBender and the possibility to play the scaled note on another MIDI channel can be added without much effort, I will add this to my TODO list. Generating multiple notes is possible of course, but how would you like to control the different modes? Best Regards, Thorsten.

Today, with the MBHP_CORE_LPC17 core, it's probably better to create a MIDI merger based on MIOS32, especially since you will get USB-MIDI (and even OSC via Ethernet for wireless transfers) for free! E.g. have a look into the MIDI 4x4 application: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fmisc%2Fusb_midi_4x4%2F The APP_MIDI_NotifyPackage() function in app.c routes the MIDI events, even for a SQL guy it should be obvious what has to be changed to route all inputs to a single output, no? ;-) Best Regards, Thorsten.

Seems to be related to a short circuit in the LCD circuit, this especially explains the higher LF33 temperature -> see also this schematic to locate the affected components which are supplied by the middle pin of J15_S: http://www.ucapps.de/mbhp/mbhp_core_lpc17.pdf This is the location where you have to search for bad solder joints and/or bridging junctions. Best Regards, Thorsten.

Du hast Recht, dass man mit den Wechselkontakten jeweils eine Diode pro Taste einsparen kann, da ausgeschlossen ist, dass beide Kontakte gleichzeitig schliessen. Doch es bleibt bei einer Diode pro Taste. Siehe auch folgenden Schaltplan als Referenz: http://www.ucapps.de/midibox_kb/midibox_kb_scanmatrix_vel_default.pdf und denke Dir jede zweite Diode weg. Die Break-Kontakte liegen bei Dir dann auf einem Oeffner, dessen Signallevel software-maessig invertiert werden muss (kein Problem, kann ich als Option einbauen) -> passt! Doch ich sehe keinen Weg, noch mehr Dioden einzusparen. Angenommen, die Dioden wuerden sich direkt an DOUT D0..D7 befinden, und nicht an den einzelnen Tasten, und angenommen die erste und neunte Taste wird gleichzeitig gedrueckt: dann entsteht bspw. zwischen DIN D1->DIN D3 ein (ungefaehrlicher) Kurzschluss (es fliesst kein nennenswerter Strom). Wenn nun aber die zweite Taste noch zusaetzlich gedrueckt wird (also: Taste 1, 2 und 9 gleichzeitig), dann entsteht auch eine Verbindung zur 10. Taste -> und das willst Du nicht, dann dieser Akkord hoert sich schrecklich an ;-) Zum E510 "Wunderchip": kann es sein, dass fuer jede 8er-Gruppe ein 74HC138 notwendig war? Gruss, Thorsten. Ja, Lieferung in ca. zwei Wochen! :) Super! Mittlerweile habe ich uebrigens auch herausgefunden, warum die Rows verschoben waren... war ein Programmierfehler, jetzt passt alles so wie geplant. Und btw.: die MBSEQ V4L stuerzt nun auch nicht mehr ab, wenn sie mit Pianist Pro (iPad) Kontakt aufnimmt; Ursache war eine Feedback-Loop die quasi zu einem Buffer Overflow fuehrte (Firmware-Update ist noch nicht released, da sich ja bisher noch niemand darueber beschwert hat ;-) Gruss, Thorsten.

DINs connected to LPC17 will send MIDI events to the MIDI port which has been configured in the DIN page - the output port(s) can be configured for each pin individually. Could you please explain, why you expect that a DIN pin handled by the LPC17 core sends to OUT2? Did you configure the pin accordingly? Anyhow, I don't think that this detail is really relevant to debug SysEx communication. As following snapshot is showing, your PIC base core sends "F0 00 00 7E 40 02 01 F7" when powered on. http://midibox.org/forums/index.php?app=core&module=attach&section=attach&attach_rel_module=post&attach_id=9686 This means, that the core is configured for Device ID 2, and not 1 Could it be, that you used two different PIC cores during debugging without mentioning it? Please do the tests again with a single PIC based core, otherwise it's impossible for me to clarify (remotely) that all data paths are working. And please also add another test: Loopback OUT2->IN2 with a MIDI cable. MIOS Studio device ID should be configured with 0 for this test. Enable the LPC17 based MIDI monitor ("set midimon on") Show me a log where you are sending some MIDI Notes with the virtual keyboard, and where you are pressing the Query button. I would like to see the MIOS Terminal output as well as the MIDI IN/OUT monitor output of MIOS Studio. Best Regards, Thorsten.

Your question isn't detailed enough to answer it correctly, but your observations are correct and I don't really see a problem here. I think that I found the error (at your side): the PIC based core is configured for device ID 2 Accordingly you've to select this device ID to query this core - it seems that you are using device ID 0 instead! Best Regards, Thorsten.

Sorry! Ich habe die Frage erst jetzt gesehen: Stimmt nicht ganz - fuer jeden Kontakt ist eine Diode notwendig, d.h. bei einem Keyboard mit Velocity (= 2 Kontakte) zwei Dioden pro Taste, und ohne Velocity eine Diode pro Taste. Mit der Diode wird verhindert, dass DINs ueberbrueckt werden, wenn mehrere Tasten gleichzeitig gedrueckt werden (-> "Geisternoten") So, es gibt noch etwas neues. Nachdem ich mit Acul letztens das Fatar-Keyboard ans Laufen gebracht habe, ist mir bewusst geworden, wie umstaendlich und fehlertraechtig die Verdrahtung ist, vor allem dann, wenn auch noch die Pull-Polaritaet geaendert werden muss. Das will ich Euch (und mir) nicht antun - deshalb habe ich ein spezielles Layout erstellt, dass zwei DIN und zwei DOUT Register vereint: Features: J1 und J2 sind kompatibel zum DIN/DOUT Modul, es lassen sich sowohl mehrere "MBHP_DIO_MATRIX" Module, als auch mehrere DIN/DOUT Module kaskadieren. die Pinbelegung von J3 und J4 ist 1:1 kompatibel zum Fatar Keyboard! die 220 Ohm Widerstaende an den DOUTs entfallen, da sie fuer die Matrix-Verschaltung nicht notwendig sind 10k Pull-Devices sind ueber J6 konfigurierbar (Pull-Up oder Pull-Down) das Board ist auch fuer andere Anwendungsfaelle geeignet, man kann bspw. auch LEDs anschliessen, entweder in Matrix oder Direkt-Verschaltung (die Widerstaende muessen dann extern verloetet werden) mit J5 ist +5V und GND direkt verfuegbar, bspw. fuer Direktverschaltung von LEDs und Buttons (ohne Matrix) Das Board ist 8x4 cm gross, somit passen 5 davon auf das Europlatinenmass (4, falls Olimex wirklich auf 16x10 besteht und 5, wenn Olimex es nicht so genau nimmt ;-)) Die Prototypen werde ich diesmal bei Olimex (sitzt in Bulgarien) bestellen. Der Preis wird zusammen mit den Versandkosten ca. 40 EUR betragen, also 8 EUR pro PCB - akzeptabel! :) Die ersten 5 PCBs sind uebrigens schon vergeben, doch wer moechte kann sich ja dann spaeter auch mit anderen Leuten zusammentun und direkt bei Olimex bestellen. Gruss, Thorsten.

Thanks for your work! :) Hope that I will find the time to test this and to give some proposals sooner or later... Best Regards, Thorsten.

Yes, you can connect both modules with your PC during this test, the power consumption is low and shouldn't cause a problem. Best Regards, Thorsten.

Hi, if the LED flashes 3 times it means that the MIOS32 bootloader is up&running! :) (after the 3rd flash it will start the application - you can disable this via "fastboot option") It means that you can now upload an application via MIOS Studio - you don't need the LPC Link anymore! Probably you connected the LPC Link port with the MBHP_CORE_LPC17 module. This option is only intended if an external JTAG debugger should be connected via J3. If you still want to use LPC Link for whatever reason (but I don't see a need for this, as the application has to be uploaded via MIOS Studio, not via LPC Link!), you either have to solder the LPC Link socket the other way around: Best Regards, Thorsten.

Thanks! I'm glad that you got it working! :) Note that the error isn't really at Tim's side, it's a more a conversion or documentation problem. Probably you specified the device ID in hexadecimal format (0x12), which is 18 in decimal format (as selectable in MIOS Studio) Best Regards, Thorsten.

Hi, on MB64E you won't notice such latency issues, since pots/encoders/buttons are scanned faster than a MIDI message could be transmitted -> full bandwidth! :) But the resolution is limited to 7bit to avoid jittering pot values. For higher resolutions an AINSER64 module will be required, a LPC17 core module and a MIOS32 based application which converts them into MIDI events which are understood by your synth. Unfortunately you haven't mentioned if and how your synth understands higher resolutions (which MIDI events have to be sent?) Best Regards, Thorsten.

The status LED will start to flash once the application has been uploaded. Here the link to the troubleshooting guide, which is also valid for the MBHP_MF_NG module: http://www.ucapps.de/howto_debug_midi.html Btw.: which MIDI interface are you using exactly? Some cheapo interfaces (like this one) won't work, because they can't handle SysEx properly. Best Regards, Thorsten.

Hi, thanks for the compliments! :) The AOUT_NG module can be selected in config files which is stored on SD Card: MBSEQ_GC.V4: open this file with a common text editor (e.g. wordpad will do), search for "CV_AOUT_Type" and set it to 3 for AOUT_NG SESSIONS/DEF_V4L/MBSEQ_C.V4: search for MIDI_DefaultPort and change it to 128, so that MIDI events will be forwarded to the AOUT interface. The MIDI channel selects the CV output (1..8). But only two gates are available; since J5 is allocated for connections to the frontpanel, they are at J28: Gate #1: J28.WS Gate #2: J28.MCLK Best Regards, Thorsten.