TK.

Cheers! :) Best Regards, Thorsten.

Please wait for this until I've checked various RGB LEDs at my side (it's on my Agenda to try this out for upcoming MBCV V2) I've already the RGB LEDs, just need some time for some experiments - and I will try this with a MBNG. It might be that I will add special extensions to minimize wiring effort, but to ensure that we've enough dim levels Best Regards, Thorsten.

This won't work, because this way you will create a non-linear resistor network. There is no solution to turn a 50k fader into lower resistances, the high fader resistance is prone to jitter Best Regards, Thorsten.

Very well done! Value forwarding can be disabled with a conditional event, e.g.: EVENT_CV id=1 if_equal LED:1:0 ...will only change CV:1 if the value of LED:1 is 0 For driving a second DOUT you could forward in a chain: EVENT_BUTTON id=1 fwd_id=LED:1 ... EVENT_LED id=1 fwd_id=LED:2 ... EVENT_LED id=2 ...BUTTON:1 forwards to LED:1, and LED:1 forwards to LED:2 But for the case that you would like to restore the original CV value if LED:2 changes back from any value to 0 (unmute), you finally need a .NGR script which is triggered by an EVENT_SENDER: EVENT_BUTTON id=1 fwd_id=LED:1 ... EVENT_LED id=1 fwd_id=SENDER:1 ... EVENT_SENDER id=1 type=Meta meta=RunSection:1And in the .NGR script something like: if ^section == 1 if BUTTON:1 == 0 # button depressed: unmute set LED:2 0 # copy current AINSER:1 value to CV:1 set CV:1 AINSER:1 else # button pressed: mute set LED:2 127 # mute CV output set CV:1 0 endif endif Best Regards, Thorsten.

Actually I missed to add this to the UTILITY page. Please try this pre-release: http://www.ucapps.de/mios32/midibox_seq_v4_090_pre1.zip It comes with another new feature: the right half of the Fx->Scale screen shows the resulting keys now, which should help to get an overview about the forced notes which will be played. Best Regards, Thorsten.

Ok, I tried following minimized configuration: MAP1 1 2 3 EVENT_BUTTON id=1 fwd_id=SENDER:1 range=map1 button_mode=Toggle EVENT_SENDER id=1 type=NoteOn chn=1 key=0x4b EVENT_BUTTON id=2 fwd_id=SENDER:2 button_mode=OnOnly EVENT_SENDER id=2 fwd_id=BUTTON:1:1and found a way to handle your use case. Please try this version: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre15.zip Best Regards, Thorsten.

Could it be that the other ports send a MIDI clock or something similar? Best Regards, Thorsten.

V4.089 has been released! From the ChangeLog: MIDIboxSEQ V4.089 ~~~~~~~~~~~~~~~~~ o added DIN testmode which can be enabled from the MIOS terminal with the "set din_testmode on" command to display button and encoder movements. o added "Roll Gate" as new optional trigger layer assignment. It gates the Roll or Roll2 value which is configured in a parameter layer. o Euclid Generator: parameter layer into which the pattern will be copied now selectable. Velocity/Accent will only be changed if the first parameter layer is selected. o it's now possible to quickly duplicate the steps of a track: press&hold COPY and press the PASTE button o Groove page: by default, groove configuration changes are applied on all tracks now. It's possible to select a "local groove" by pressing GP7 button in the groove page. o BPM page: it's now possible to configure an output delay for each MIDI port. (positive and negative delays are supported - this is currently an experimental feature!) o fixed NoteOff in Jam Forwarding mode if FTS, Limit or Humanizer is enabled o NOTE: due to a RAM capacity issue, the UNDO function is currently not available for the LPC17 firmware Best Regards, Thorsten.

Signatures are available again, thanks for pointing this out! Peter wanted to say, that I changed from tobacco to e-liquids more than 1 year ago. I should consider to change my signature to "Buy TK a tasty vape liquid" ;-) Best Regards, Thorsten.

I moved the postings about my build to the build guide so that we can collect additional information there: http://midibox.org/forums/topic/19736-blm-16x16x-build-guide/ Unfortunately the URL changed after the merge (I had to learn how to handle the new forum functions... ;-) Best Regards, Thorsten.

It took me around two days (ca. 15 hours) - at the first day I soldered 1N4148 diodes and LEDs, and at the second day the remaining parts. Over time I became faster with SMD soldering, but still ensured that parts are correctly aligned - especially for the LEDs it's important that they sit flat on the PCB, otherwise later they could illuminate in different directions so that you won't see a combined colour through the affected silicon pads later. Therefore the important hint: always solder only 1 pin (tacking), align the part, then solder the remaining pin(s), otherwise you can't fix the position anymore without desoldering the part! This way I tacked one row of LEDs, fixed the positions (when necessary), and then soldered the second pin. The same for any other part - it brings a little bit variety in the boring soldering process ;-) To the colours: In difference to Andys proposal I took blue as "colour 2" (right side of the bottom PCB) and green as "colour 1" for the left side, but this was my personal preference. Don't worry, the firmware allows to swap colors if you are unhappy with your initial decision! :) For the extra row/column and shift button I took red as "colour 1", and blue as "colour 2" again. Therefore (and I only write this as an important reminder for the case that somebody wants to do the same) I had to swap the resistor networks: 220 Ohm for the green/red LEDs (RN3, 7, 11, 15, 19) and 56 Ohm for the blue LEDs (RN4, 8, 12, 16, 20) Best Regards, Thorsten.

In pre7 I added a bugfix for MAPs with duplicated values to cover Bartosz' use case; see also http://midibox.org/forums/topic/19535-encoder-and-maps-problem-bug and http://svnmios.midibox.org/comp.php?repname=svn.mios32&compare[]=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2F%402174&compare[]=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2F%402153 Could you please give me a downstripped .NGC file (and/or .NGR in addition) which demonstrates your intention? It could be that due to the changes a new way has to be found. Best Regards, Thorsten.

Could you please send me a (downstripped) .NGC file which allows to reproduce the problem at my side? Best Regards, Thorsten.

Seems to be related to a bad solder joint? I guess that you can measure the right voltage at IC3, pin 12, right? Now follow the track with your multimeter to pin 11 and 32 of the PIC, and check where the voltage isn't available anymore. Best Regards, Thorsten.

A new BLM has been born Very nice to build, no big troubleshooting required if you are careful enough and don't forget a solder joint or create an unintended short. Andy deserves great respect for his sophisticated design, this is really professional work and sets a new DIY standard! Although the BLM16x16+X project is 5 years old meanwhile, you still can't buy a device with 290 buttons and duo-colour LEDs - you can only build it by yourself - and it has never been easier! Best Regards, Thorsten.

no, IF/ELSE is the wrong approach for this purpose, and the RAM is limited to 16k ;-) But in future I could provide a special command which allows to scale during runtime based on an interpolated curve with n number of nodes. This would consume some additional execution time, but it should be fast enough on a STM32F4 - the memory consumption is then dramatically reduced. In general it's an advantage of the .NGR approach that special commands and mechanisms could be provided in future. Sooner or later I will clean-up the source code to simplify the integration of new commands (I've to improve it anyhow, because currently we've too much quick&dirty spaghetti code) Best Regards, Thorsten.

And I got the mouser parts today & I'm ready for a nice soldering challenge! :) Best Regards, Thorsten.

Yes, it's the MCLR# pin. I improved the documentation Best Regards, Thorsten.

could you please determine with the "show id DOUT:1" command the values between the different states? I could imagine, that this is a side effect caused by the snapshot function Meanwhile I know the reason: after reset the MBNG firmware will wait for 2 seconds until controllers will be enabled. This is to ensure that SD Card content has been read, and voltages are settled. Could you please increase the delay to 2500 mS? if ^section == 0 # wait until all values have been scanned (consider 2 seconds startup delay + a little bit margin) delay_ms 2500 # now capture the AINSER values exec_meta RetrieveAinserValues endifBest Regards, Thorsten.

Potential use cases which didn't work properly in the past, but should be possible now: flexible MIDI event converter/router: reacting on incoming MIDI events, e.g. with SEND commands selected via IF/ELSE conditionsfully customized bank handling via SET_ACTIVE command, interactively switched from a fast turned rotary encoderfast keypad entry (you know the example: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Frunscr5.ngrAlso this issue should be solved now: http://midibox.org/forums/topic/19477-problem-with-keys-and-runsection-command/ Best Regards, Thorsten.

To all fans of .NGR files: please join the beta testing for execution from RAM: http://midibox.org/forums/topic/19728-request-for-beta-testers-ngr-script-execution-from-ram/ Best Regards, Thorsten.

Today I also noticed the case that the file won't be stored if the core generates a lot of MIDI traffic via the same USB channel. The connection wasn't failing though, but I think it's a problem with the communication scheme used by the file browser, it isn't robust against "foreign MIDI traffic". Needs some time to work this out! Best Regards, Thorsten.

Hi, in the last months multiple users requested faster execution of .NGR run scripts to cover their use cases. The only way to achieve this is the execution from RAM, and in order to ensure that even the execution of long and complex scripts is possible, the NGR commands have to be compressed (resp. I call it "tokenized") In the last two days I developed a solution for this request - it was a nice programming challenge (although I hate the immense amount of required spaghetti code to cover all options - next time I will use a code generator... ;-) Typically scripts are now executed in much less than 1 mS, which means that it's finally possible to use them for timing critical operations! Only drawback: this feature is only supported for MBHP_CORE_STM32F4, because the other cores don't have enough RAM available - they are executing the script directly from SD Card like before. Here the current version: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre14.zip It would be helpful if users could help me with the testing by running their existing .NGR files, and maybe also enhancing the files for realtime processing. Any feedback is welcome! :) Best Regards, Thorsten.

Great that we finally solved this mysterious issue! :) you mean, that you attach the keyboard during runtime, or is it already connected while the .NGC script is loaded? You've to capture the AINSER values once they have been scanned. This can be done from the .NGR file: if ^section == 0 # wait until all values have been scanned (should be after >= 50 mS) delay_ms 50 # now capture the AINSER values exec_meta RetrieveAinserValues endif Best Regards, Thorsten.

Thanks for testing! This one should work better: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre13.zip I noticed that I'm able to test the forwarding by myself from the terminal w/o special hardware by entering "ngr trigger AINSER:1" I knew that sooner or later this command could become useful Best Regards, Thorsten.