TK.

I guess that you only tried the long cable, but not the short cable to J15, right? Anyhow, although the actual issue isn't clarified (I hoped that we are able to achieve this), we should go for Plan B: connecting the 16 CS lines to two DOUT SRs which are connected to J28. Unfortunately I can't give you new code till next week (Merry Christmas! :smile:) Best Regards, Thorsten.

Thanks! :) Best Regards, Thorsten.

Hi, yes! See also http://www.ucapps.de/midibox_sid/mbsid_v2_communication.pdf It will display a boot screen, thereafter the MBSID main screen when the connections are ok this doesn't matter no Best Regards, Thorsten.

Ok, it's probably related to OSC. I will check this in ca. 1 week. no, as long as the port and IP address settings are correctly configured, it should work. (I will check this...) Best Regards, Thorsten.

Yes, this should work as well! :) But please take AND gates, otherwise the LED would be active if either key1 OR key5 is pressed. Best Regards, Thorsten. Clever! But CycleBank is not the right meta event, because it could get out of sync with the key5 activation. SetBank would be better Best Regards, Thorsten.

Could it be, that the BSL Hold Jumper (J27) is stuffed? Please remove it, because it prevents that the application will be started. Best Regards, Thorsten.

(Yes, you can contract a builder) Best Regards, Thorsten.

:thumbsup:

Sorry, I don't see a solution for this. It would require logic combinations in the EVENT conditions, and recalculations on each incoming event. Such a customization would require a dedicated firmware enhancement, or (what I would prefer) direct control of the LEDs from the host side. Best Regards, Thorsten.

I like the circuit! :smile: Could you please change J1 to the new recommended 2x5 header layout + a jumper which selects between RC1/RC2? See also: http://www.ucapps.de/mbhp/mbhp_aout_mcp4822.pdf no, this shouldn't be required It's supported by the MIOS32 AOUT driver, but not used by any application yet. However, but this also means that it isn't unlikely that somebody would use such an option for his project. No, please don't terminate the signals. Best Regards, Thorsten.

The problem is, that events are never received at the same time. There is always a sequential order which is controlled by the MIDI device which sends the events, and this has to be considered when working with conditions. If the order is randomly (e.g. because the keys are played by a human ;-)), then I don't see a proper way with the existing MBNG functions. Therefore the question: is the order - and maybe also the events which are sent - under your control? Resp. what is your exact use case? Best Regards, Thorsten.

Thanks for the hint! This was a stupid copy&paste error Best Regards, Thorsten.

I've another idea (and will explain the reasons if my assumption is true): Could you please try this version: http://www.ucapps.de/tmp/mios32_test_app_lcd_ssd1306_LPC1769__20131221.zip Required hardware change: connect the D1 lines (SDA) to J15B:E2 instead of J15A:RW J15A:E1 will output SCLK (D0 lines) as before. Best Regards, Thorsten.

I started with a webpage which documents the facts: http://www.ucapps.de/midibox_cv_v2.html Best Regards, Thorsten.

it's strange, but it's already integrated into the application! (seems that I forgot to remove it from a basis template, but now where it's in... :smile: Best Regards, Thorsten.

The question was directed to Novski, but KUI: since you've an unstuffed module, pictures would be interesting as well! This would allow me to check the traces at the top (because I guess that on Novski's PCB they will be hidden by the 74HC595 and some sockets) Best Regards, Thorsten.

Very interesting! No, I don't have a green colored PCB Before sending me the hardware, first let's try to analyze this remotely. Could you please create high-resolution pictures from the top and bottom side of the LCD (J15) related circuitry? I need pictures from the "good" and from the "bad" PCB. Best Regards, Thorsten.

I can't remember this - please keep me updated if you find the posting! Best Regards, Thorsten.

@Chriss: thanks for the valuable input! I'm planning to setup a new webpage for the project which summarizes the facts and wishes, so that we know where we are :smile: it should update automatically on CV channel changes. Are you using the MIDI or OSC option? Could you please try the latest .jzml file in the SVN repository? I adapted it to the latest Lemur version, the old one wasn't 100% compatible. There are several mini-router available at Reichelt for around 25..30 EUR To people who want to use the (preferred) MBHP_CORE_STM32F4: it won't provide an ethernet port anymore. @Sneakthief Yes, correct, it's ca. 15 mm measured from PCB bottom to OLED top I would calculate 30 mm For STM32F4 I can't confirm yet, but it will be ca. 30 mm as well Here btw. a preview of the PCBs - they have a different format compared to MBHP_CORE_LPC17! MBHP_CORE_STM32F4: 120x88 mm MBHP_MIDI_IO: 103x44 mm (two MBHP_MIDI_IO boards can be chained for 4 MIDI INs and 4 MIDI OUTs) Best Regards, Thorsten. I bought it from Ebay for 5 EUR But the height is very similar to all 2x20 CLCDs that I know. You can calculate the same height like for the OLEDs Of course, no problem for me if you adjust the alignments. Best Regards, Thorsten.

Ja, ich habe zumindest keinen Widerspruch gesehen, und bin deshalb nicht naeher darauf eingegangen. Gruss, Thorsten.

Thanks for the hint! I like the shape of this button, but Digikey is no option for me :-/ We should open a separate button decision thread, because the choice will affect many projects which get use of the SCS (Standard Control Surface with CLCD, encoder and 6 buttons) Background: In Germany we usually prefer to purchase components from Reichelt. Prices are cheap and delivery is superfast. Therefore I've preferences which might look strange to you US guys. On the other hand, Mouser enhanced their business in Europe, so that it's much easier to order parts from this distributor. This has to be considered. I tend to propose Mouser as the preferred supplier in future... but this is another topic ;) News from the frontpanel side: the experiment to control OLEDs from J5 & J28 pins in parallel to a CLCD connected to J15 was successful: Next step: a proper integration into MIOS32 to make the GLCD type configurable and not application dependent (this will be a challenge!), because I'm sure that MIDIbox NG users will be interested on this option as well! Best Regards, Thorsten.

The main.hex file is only intended for PIC programmers, not for MIOS Studio! But since you got the PIC from Mike, the IDs should already be programmed correctly. Aha, now it also sends other events... was this also the case before the soldering fixes? When do you get this output: once after power-on, or continuously? And do you always get the same events after power-on, or are they changing? Best Regards, Thorsten.

Some progress: I mounted the frontpanel components on veroboard to check dimensions, the surface feel, and of course to prepare the firmware. First issue that I noticed: unfortunately the ITT Shadow buttons are not the perfect choice, since the button cap height doesn't fit with the LCDs (considered, that a 3mm acryl panel will be on top of the LCD/OLEDs): Therefore we've to decide for other buttons (I'm using mini buttons for the prototype just to keep it cheap) On the picture above, you will also notice the second issue: between each OLED there has to be a 100 mil gap, otherwise they won't fit side by side. Next picture shows OLED and SCS PCB together: OLEDs and CLCD are aligned! This is the most important message! :smile: But: due to the wider OLED part of the panel, the CLCD won't be centered anymore: Therefore the big question: does it make sense to move the SCS to the right side? Advantage: this could speed up the menu handling. E.g. choose a menu page with the left hand, while tweaking parameters with the right hand! Some additional words to the button array PCB: I'm using 3x4 buttons now, there will be enough DIN inputs free Some words to the OLEDs: in order to use them in parallel to a CLCD, they can't be connected to J15 anymore. Not only because of the different interface, but also because they have to be supplied at 3.3V, but the CLCD has to be supplied at 5V I spent some thoughts about this IO conflict, and finally came to following conclusion: 1) OLEDs will be connected to J5A and J28 2) the gates will only be available at DOUT shift registers, and not at J5/J28 anymore This might sound like a big drawback (additional hardware required for the gates) -> wrong! Because gate outputs have to be buffered and protected with 220 Ohm resistors anyhow, see also this circuit from MBSEQ: http://www.ucapps.de/mbhp/mbhp_core_lpc17_output_buffers.pdf So: instead of taking a 74HCT541 for buffering parallel outputs, a 74HC595 can be used for exactly the same purpose with the only difference, that it's loaded from a serial chain -> J8/J9 Therefore I think that this will be an acceptable solution. It also prevents, that somebody is trying to connect his synths directly to J5/J28 without protection, e.g. because he missed to read an important detail in the documentation, or just isn't aware about the dangers. Best Regards, Thorsten.

Ok, then it's clearly a soldering issue. Check the whole +5V supply track and all solder joints related to this. We had a very similar case in the german section of this forum just 4 days ago: And again... it was just a cold joint. Best Regards, Thorsten.

Did you flash the bootloader into the PIC with your own programmer? Probably it hasn't written all-zero into the ID field. This can be fixed with TEST_SW2 http://www.ucapps.de/howto_debug_midi.html Best Regards, Thorsten.