TK.

OSC for synching devices doesn't work robust enough, especially since the ethernet interface is handled with a lower priority than other MIDI tasks. Therefore I haven't implemented such a possibility, and I can't change this since with a higher priority the network traffic could influence the performance of the sequencer too much. Best Regards, Thorsten.

Yes, you have to enable the AINSER module (especially you've to specify the CS pin number). Here a configuration example for two AINSER modules (you only need the first one): http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fainser64.ngc Best Regards, Thorsten.

Sorry, my fault. It should be: DOUT_MATRIX n=1 rows=4 sr_dout_sel1=4 sr_dout_r1=3 DOUT_MATRIX n=2 rows=4 sr_dout_sel1=4 sr_dout_r1=5 DOUT_MATRIX n=3 rows=4 sr_dout_sel1=7 sr_dout_r1=6 DOUT_MATRIX n=4 rows=4 sr_dout_sel1=7 sr_dout_r1=8 Does this make more sense? ;) no, I mean that EVENT_LED_MATRIX id=1..16 are assigned to DOUT_MATRIX id=1 EVENT_LED_MATRIX id=17..32 are assigned to DOUT_MATRIX id=2 EVENT_LED_MATRIX id=33..48 are assigned to DOUT_MATRIX id=3 EVENT_LED_MATRIX id=49..64 are assigned to DOUT_MATRIX id=4 each id controls a column (LED bar) You've only 4 LED bars per DOUT_MATRIX, accordingly only id=1..4, id=17..20, id=33=36, id=49..52 are relevant, the others can be ignored. Best Regards, Thorsten.

I will share it in the Wiki once I got the panels from Formulor. Best Regards, Thorsten.

This is relieving! :) Could you please check, if display 16 is working correctly with this app: http://www.ucapps.de/tmp/mios32_test_app_lcd_ssd1306_LPC1769_131201_1.zip It has been compiled with new gcc and "relaxed SER streams" - same infrastructure that I used for the MBNG build before. Yes! Best Regards, Thorsten.

Got it, cheers!

This topic hasn't been forgotten: I've increased the OSC stack size, so that received OSC messages don't lead to a crash anymore. -> http://www.ucapps.de/mios32/midibox_ng_v1_027_pre6.zip A template for bidirectional transfers (for CC#16..CC#31) can now be found under touchosc/bidirectional_cc_via_osc.touchosc Best Regards, Thorsten.

@KUI: here a new version for testing: http://www.ucapps.de/mios32/midibox_ng_v1_027_pre6.zip It has been compiled with the new GCC compile. I gave the serial shift at J15 and J28 a little bit more time in the hope that this helps. In addion, the SCLK will now be available at J15A:E and J15B:E Means: you get an additional clock driver "for free" which could be used instead of a buffer (if really necessary) If this still doesn't help, please also try out what happens if the core is powered off for at least 5 seconds, and then powered again. Best Regards, Thorsten.

Fine! :) It makes sense to set back the device id to 0 with the bootloader update application, because for USB MIDI a different ID isn't really required. Best Regards, Thorsten.

Ah! Sorry, I picked up the wrong example. This is a better one: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Ftpd.ngc (it tests the TPD, which consists of two 8x8 duo-LED matrices, driven by DOUT_MATRIX n=2 and n=3) As you can see, each DOUT_MATRIX has 16 EVENT_LED_MATRIX entries, regardless of the number of rows. In order to ensure individual access, I would propose to define 4 DOUT_MATRIX items: /edit: corrected DOUT_MATRIX assignments. DOUT_MATRIX n=1 rows=4 sr_dout_sel1=4 sr_dout_r1=3 DOUT_MATRIX n=2 rows=4 sr_dout_sel1=4 sr_dout_r1=5 DOUT_MATRIX n=3 rows=4 sr_dout_sel1=7 sr_dout_r1=6 DOUT_MATRIX n=4 rows=4 sr_dout_sel1=7 sr_dout_r1=8 you should be able to control the LED bars with: EVENT_LED_MATRIX id= 1 type=CC chn= 1 cc= 16 led_matrix_pattern=1 EVENT_LED_MATRIX id= 2 type=CC chn= 1 cc= 17 led_matrix_pattern=1 EVENT_LED_MATRIX id= 3 type=CC chn= 1 cc= 18 led_matrix_pattern=1 EVENT_LED_MATRIX id= 4 type=CC chn= 1 cc= 19 led_matrix_pattern=1 EVENT_LED_MATRIX id=17 type=CC chn= 1 cc= 20 led_matrix_pattern=1 EVENT_LED_MATRIX id=18 type=CC chn= 1 cc= 21 led_matrix_pattern=1 EVENT_LED_MATRIX id=19 type=CC chn= 1 cc= 22 led_matrix_pattern=1 EVENT_LED_MATRIX id=20 type=CC chn= 1 cc= 23 led_matrix_pattern=1 EVENT_LED_MATRIX id=33 type=CC chn= 1 cc= 24 led_matrix_pattern=1 EVENT_LED_MATRIX id=34 type=CC chn= 1 cc= 25 led_matrix_pattern=1 EVENT_LED_MATRIX id=35 type=CC chn= 1 cc= 26 led_matrix_pattern=1 EVENT_LED_MATRIX id=36 type=CC chn= 1 cc= 27 led_matrix_pattern=1 EVENT_LED_MATRIX id=49 type=CC chn= 1 cc= 28 led_matrix_pattern=1 EVENT_LED_MATRIX id=50 type=CC chn= 1 cc= 29 led_matrix_pattern=1 EVENT_LED_MATRIX id=51 type=CC chn= 1 cc= 30 led_matrix_pattern=1 EVENT_LED_MATRIX id=52 type=CC chn= 1 cc= 31 led_matrix_pattern=1 Best Regards, Thorsten.

Thanks for the files! This was a simple bug: the MIDI clock was output at 384 ppqn (inherited from the original MIDIbox SEQ V4 code), but a .mid file can have it's own ppqn rate which was ignored. It's fixed now, please try this version: http://www.ucapps.de/mios32/midio128_v3_017_pre1.zip Please note that the REC1.MID file won't output a proper clock whenever the song is looped, because re-loading from SD Card takes some time at which no MIDI clock event is sent. Best Regards, Thorsten.

Could it be, that your core is assigned to a different device ID? This would explain, why it won't be found via Query. It's also a plausible reason, because the storage file of the device ID number has been changed between MIOS Studio 2.2 and later versions. So: try different IDs, push the Query button after each change to check if the core will be found. Best Regards, Thorsten.

Ok, then let's try to continue the debugging remotely with KUIs setup. I will come back to this topic soon. Best Regards, Thorsten.

Maybe the bootloader update left some artifacts in the MacOS setup. What happens if you: remove the J27 jumper (don't use bootloader mode, so that the MIDIbox NG application with it's 4 USB-MIDI ports is active) start the Audio-MIDI-Setup of MacOS (e.g. search for "audio-midi" with Spotlight) disconnect the core module from USB delete the interface in the Audio-MIDI-Setup connect the core module to USB again Thereafter re-start MIOS Studio and select the first MIDI IN/OUT of your MIDIbox NG Is the Query working thereafter? Best Regards, Thorsten.

Hi Robin, there is no special configuration required in the application, but you have to configure the dedicated DOG CLCD mode in the bootloader set lcd_type CLCD_DOGIf this doesn't help, then try out a different cursor map.Because the cursor position handling is different from common CLCDs. E.g. what happens with: u8 cursor_map[] = {0x00, 0x40, 0x14, 0x54}; // offset line 0/1/2/3 MIOS32_LCD_CursorMapSet(cursor_map); And what happens with: u8 cursor_map[] = {0x00, 0x10, 0x20, 0x30}; // offset line 0/1/2/3 MIOS32_LCD_CursorMapSet(cursor_map); Best Regards, Thorsten.

Finally I got it working and ordered the panels :) Solution: - I'm using Inkscape under Linux (running in a virtual box) - Ilmentator sent me a .svg file - this file has to be modified with a text editor, otherwise Inkscape can't load it: remove xmlns="&ns_svg;" - do the required modifications (frame around the elements & create a bottom panel) - upload the new .svg to Formulor Best Regards, Thorsten.

Hi Klaus, thanks for the offer, but I fear that this won't bring new insights. There seems to be something special if connections are directly routed on a PCB (e.g. w/o J15 & J28 sockets between OLEDs and LPCXPRESSO module). It's maybe possible to compensated this via software, but I've to analyze this on my bench. Best Regards, Thorsten.

This is really strange, especially since I'm using Mavericks as well. Could you please try to contact the core in Bootloader Hold Mode? Just connect jumper J27, power-cycle the core and try to query with MIOS Studio again. If this works, upload the MIDIbox NG application again. Thereafter remove the J27 jumper. Maybe this helps. Best Regards, Thorsten.

Ok, understood the problem: the .NGC file parser was too restrictive - I released a mbng_file_c.c change in the repository which allows swapped pins, and which should raise an error message on unsupported pin combinations. Please help to test this (critical) change - we've to avoid that valid pin combinations are refused by the parser due to a potential programming error! Best Regards, Thorsten.

Yes, I changed it in MIOS32, and I guess that the MIDIbox NG application doesn't take care about the pin alignment, so that the configuration value will be directly passed to MIOS32 Best Regards, Thorsten.

Indeed, it's winter time! Hope that this build goes well! :) Best Regards, Thorsten.

This example shows how to control several LED digit clusters via CC: -> http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fleddig1.ngc Does this help? Best Regards, Thorsten.

Yes, the voltage reference is the key, otherwise I would have already supported the MCP devices! Best Regards, Thorsten.

Thanks for the contribution! Still love your patches, very inspirational - you are a real FM expert! Hope that other users will recognize this as well :smile: Best Regards, Thorsten.

I could easily add a key combination which allows to do this. The copy function would have to store the layer was active during the capturing. The paste function would have to be combined with another key to transfer the previously selected layer only - maybe SELECT+PASTE? Best Regards, Thorsten.