TK.

Added enhancement requests to wish list. To the bug report: did you press the "Update" button before loading the file? "Update" ensures that you can see the current SD Card directory content (there is no auto-refresh) Best Regards, Thorsten.

Do you mean the MBHP_MIDI_IO module: http://www.ucapps.de/mbhp_midi_io.html or the MBHP_IIC_MIDI module: http://www.ucapps.de/mbhp_iic_midi.html The IIC MIDI module requires further initialisation in the mios32_config.h file A troubleshooting app can be found under apps/troubleshooting/iic_midi Best Regards, Thorsten.

Hi, yes, this is possible. See this example for Waldorf Blofeld: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftemplates%2Fblofeld.ngl Best Regards, Thorsten.

Meanwhile two LRE8x2 are supported (max!) I changed this spec at the website Best Regards, Thorsten.

A reboot shouldn't be required to get this working. However, good that it's solved now! :) Best Regards, Thorsten.

Great find! DETENTED4/5 will be available with the next release Best Regards, Thorsten.

Evtl. hilft die DETENTED4 oder DETENTED5 option, die mit der naechsten Release zur Verfuegung gestellt wird. Gruss, Thorsten.

You've my respect as well! Best Regards, Thorsten.

Hi, are you using the correct SysEx strings for MBSID V1 (!) as documented here? -> http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v1%2Fdoc%2Fmidibox_sid_sysex_implementation.txt Are you using a 2x20 or 2x16 LCD? The SAVE item is the last one in the menu. If you are using a 2x16 LCD, you won't see it. Best Regards, Thorsten.

Some time ago I also spent some thought on this - at least it's feasible, the topic is on my agenda :) It requires that the .NGR parser transforms the commands into byte code. With this kind of compression huge scripts could be processed with very high speed. Do I understand you correctly that you would like to implement this? :) Best Regards, Thorsten.

:thumbsup: !!! Can't wait to build my MBCV V2 into a case :) Best Regards, Thorsten.

Wow, das sieht wirklich gut aus! Wie kann man sich bei http://selbstklebefolie.com etwas drucken lassen, und wieviel hat das gekostet? Gruss, Thorsten.

No problems at my side, I'm using MacOS 10.10 as well: If MacOS shows the wrong number of MIDI ports, it could be related to your Audio MIDI Setup. See also the bottom of this page how to fix this: http://www.ucapps.de/mios32_bootstrap_newbies.html Best Regards, Thorsten.

added to wish list, but with low prio as long as there a no other people who request the same (or have better ideas) I guess that most people will forget these special button combinations anyhow ;-) Best Regards, Thorsten.

Yes, right I corrected this, and also enabled the same pin configuration for STM31F4 like for STM31F1 But as mentioned before: actually I would like to overwork the configuration... sooner or later... to make it more generic. Best Regards, Thorsten.

The connection diagram is not detailed enough for a confirmation. Here some matrix wiring examples: http://www.ucapps.de/mbhp/mbhp_dio_matrix_8x8buttons.pdf http://www.ucapps.de/mbhp/mbhp_dio_matrix_8x16buttons.pdf http://www.ucapps.de/mbhp/mbhp_dio_matrix_8x8leds.pdf http://www.ucapps.de/mbhp/mbhp_dio_matrix_8x16buttons_8x8leds.pdf http://www.ucapps.de/mbhp/mbhp_dout_8x8leds.pdf http://www.ucapps.de/mbhp/mbhp_dout_8x16leds.pdf http://www.ucapps.de/mbhp/mbhp_din_8x8buttons.pdf http://www.ucapps.de/mbhp/mbhp_din_8x16buttons.pdf Best Regards, Thorsten.

Fein! :thumbsup: Gruss, Thorsten.

The RI_N support for IIC_MIDI is in a bad state - actually I never adapted to LPC17 because the way how the port & pin is specified doesn't work for a LPC17, and I haven't adapted for STM32F4 because I knew that this configuration needs to be changed. I think that some generic MIOS32_* functions are required to configure IO pins, so that the IIC_MIDI driver could just pass the port "number" and pin number The intention was to make this free configurable. It's a very app specific configuration, because there are no dedicated pins for the RI_N signals, so that the app developer has to decide which spare pins could be used for that purpose. Best Regards, Thorsten.

This issue has been fixed meanwhile. Please try the latest pre-release: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre5.zip Best Regards, Thorsten.

To be honest: I don't understand the question. Could you please show some .ngc code? Best Regards, Thorsten.

It seems that there is a contradiction: EVENT_BUTTON id=72 type=CC chn=5 cc=7 EVENT_RECEIVER id=8 fwd_id=sender:8 type=CC chn=5 cc=7 BUTTON:72 and RECEIVER:8 listen to the same CC number (cc=7, chn=5) BUTTON:72 will get the received value Thereafter RECEIVER:8 forwards to all (hw_id)SENDER:8 EVENT_SENDER id=13 hw_id=8 if_equal=0 fwd_id=sender:9 type=Meta meta=RunSection:2 EVENT_SENDER id=14 hw_id=8 if_equal=127 fwd_id=sender:10 type=Meta meta=RunSection:3 SENDER:13 forwards to SENDER:9 if the received value was 0 SENDER:14 forwards to SENDER:10 if the received value was 127 EVENT_SENDER id=15 hw_id=9 if_equal=button:72:127 fwd_id=LED:47:127 type=Meta meta=RunSection:1 EVENT_SENDER id=16 hw_id=9 if_equal=button:72:127 fwd_id=LED:48:0 SENDER:15 and SENDER:16 listen to (hw_id)SENDER:9 (which forwarded if the received value was 0) But: they will only react if BUTTON:72 is 127 - but the MIDI event set BUTTON:72 to 0 before Same for SENDER:17 and SENDER:18 EVENT_SENDER id=17 hw_id=10 if_equal=button:72:0 fwd_id=LED:47:0 type=Meta meta=RunSection:1 EVENT_SENDER id=18 hw_id=10 if_equal=button:72:0 fwd_id=LED:48:127 They only react if BUTTON:72 is 0, but it has been set to 127 via MIDI before. Best Regards, Thorsten.

Hi, I strongly recommend you to organize the buttons in a 8x8 DIN matrix, and the LEDs in a 8x16 DOUT matrix (for 128 LEDs) + 8x8 matrix (for the remaining LEDs) This will also solve the current consumption issue, because with 8 rows the current consumption is (appr.) divided by 8 16 rows are not recommended -> LEDs not bright enough The 8x8 DIN matrix will allocate 1 DIN SR and 1 DOUT SR The 8x16 DOUT matrix will allocate 3 DOUT SRs The 8x8 DOUT matrix will allocate 2 DOUT SRs The LED rings will require another 8x16 matrix: +3 DOUT SRs (note: 16 LEDs are max. supported) Encoders require +1 DIN SR Makes: 2 DIN SRs and 9 DOUT SRs, accordingly one MBHP_DINX4 and three MBHP_DOUTX4 yes This is actually a very simple design; of course it's feasible :) Best Regards, Thorsten.

So, with MIOS32_SPI_PRESCALER_32 (slower transfer speed) it doesn't work anymore? Please check the resulting behaviour of the chip, not the received value. Best Regards, Thorsten.

Ok, here the recommended solution: EVENT_RECEIVER id=1 fwd_id=sender:1 type=CC chn=5 cc=1 # run section 1, switch on LED 33, switch off LED 34 EVENT_SENDER id=1 hw_id=1 if_equal=0 fwd_id=LED:33:127 type=Meta meta=RunSection:1 EVENT_SENDER id=2 hw_id=1 if_equal=0 fwd_id=LED:34:0 # run section 2, switch off LED 33, switch on LED 34 EVENT_SENDER id=3 hw_id=1 if_equal=127 fwd_id=LED:34:127 type=Meta meta=RunSection:2 EVENT_SENDER id=4 hw_id=1 if_equal=127 fwd_id=LED:33:0 the receiver forwards the received values to all senders which are matching with hw_id=1 The senders only react on a matching value (if_equal=<value>) The value forwarding to a non-existing event (LED:33:x and LED:34:x) will only work with this new pre-release: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre5.zip I also fixed the DELAY_MS parameter, delay should be handled properly now (it was running twice the speed before if MBNG was showing the main screen on LCD) Best Regards, Thorsten.

That's a clever solution! :) Unfortunately EVENT_RECEIVER doesn't filter based on the specified range, which means that forwarding will always take place. I'm currently working on a better solution for you (it might require a firmware change) Please wait some minutes... Best Regards, Thorsten.