TK.

I added some enhancements into the firmware to support RGB LED Ring Patterns: http://www.ucapps.de/mios32/midibox_ng_v1_037_pre12.zip Usage example can be found here: https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/rgbled_3.ngc Best Regards, Thorsten.

Problem was, that earlier versions didn't support labels with more than 40 characters, and the corresponding error message caused the crash. The error message is working now, and I've increased the max label size to 128 characters: http://www.ucapps.de/mios32/midibox_ng_v1_037_pre12.zip Best Regards, Thorsten.

This issue should now be fixed in http://www.ucapps.de/mios32/midibox_ng_v1_037_pre12.zip Best Regards, Thorsten.

Unfortunately I can't check this so easily, because I would have to unmount the frontpanel PCB - but I don't think that such a typo would indicate a bootleg. The PCB color looks identical to the original one. Best Regards, Thorsten.

This should work... will check this tomorrow. Best Regards, Thorsten.

It's related to the NRPN optimization which only sends out 99/98 when necessary - the SysEx stream based NRPNs bypasses it, therefore the problem. I will think about a solution which can handle this configuration properly... Best Regards, Thorsten.

@lukas412 I remember that I got increased noise when the module is supplied from MBSEQ, therefore I jumpered it so that it's supplied from the 4ms pod PSU Best Regards, Thorsten.

Hi Pavel, yes, this should be possible. In cs_menu_buttons.inc you've to define a new CS_MENU_BUTTON function, and program what you need. It has to be registered as a DIN_ENTRY in your setup_*.asm file Best Regards, Thorsten.

I got some PCBs - hurray! :-) And while testing them, I found a bug in the WS2812 driver, which falsified the colours, and also influenced the colours of other LEDs - a very stupid one! Here an updated version: http://www.ucapps.de/mios32/midibox_ng_v1_037_pre11.zip Best Regards, Thorsten.

Found the bug - fixed! :) Best Regards, Thorsten.

Here the example: NGC: https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/runscr6.ngc NGR: https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/runscr6.ngr Since in the NGR script the new "range" feature is used, you've to try it with the latest MBNG version Best Regards, Thorsten.

I think that this could be somehow solved by using ^dump in combination with sysex_pos for individual dummy events which collect the characters - the characters then have to be print out conditionally, e.g. based on another dummy event which stores the selected channel. Best Regards, Thorsten.

Hi Chris, you could just define multiple EVENT_RECEIVERs, listening to incoming SysEx, matching on certain bytes which indicate which channel is addressed, and then store the value into ^val E.g.: EVENT_RECEIVER id= 1 type=SysEx stream="0xf0 0x11 0x22 0x33 0x00 ^val" EVENT_RECEIVER id= 2 type=SysEx stream="0xf0 0x11 0x22 0x33 0x01 ^val" EVENT_RECEIVER id= 3 type=SysEx stream="0xf0 0x11 0x22 0x33 0x02 ^val" EVENT_RECEIVER id= 4 type=SysEx stream="0xf0 0x11 0x22 0x33 0x03 ^val" In a NGR script you can access the received values with (id)RECEIVER:1 ... (id)RECEIVER:4 Which means for your NGR script: if you switch to another channel, just take the corresponding value from the receiver and display it. Best Regards, Thorsten.

There is a trick which might help here: a SysEx stream can also send "common" events, which means: we can just put all CCs into a single String. Example: EVENT_ENC id=1 hw_id=1 label="@(2:1:1)Attk " enc_mode=Inc01_Dec7F if_equal=0x01 type=SysEx stream="0xbb 99 0 98 23 96 1" EVENT_ENC id=1 hw_id=1 label="@(2:1:1)Attk " enc_mode=Inc01_Dec7F if_equal=0x7f type=SysEx stream="0xbb 99 0 98 23 97 127" Best Regards, Thorsten.

An example setup for this use case can be found here: https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/conev_1.ngc # send CC#96 if value is incremented EVENT_ENC id=2000 hw_id=2000 enc_mode=Inc01_Dec7F if_equal=0x01 type=CC cc=96 lcd_pos=1:1:2 label="Enc INC" # send CC#97 if value is decremented EVENT_ENC id=2001 hw_id=2000 enc_mode=Inc01_Dec7F if_equal=0x7f type=CC cc=97 lcd_pos=1:1:2 label="Enc DEC" Best Regards, Thorsten.

In MBNG it's a soft-option written into the NGC file: AINSER n=1 enabled=1 cs=0 num_pins=64 resolution=7bit which allows to set the number of pins Best Regards, Thorsten.

Ok, then please try this version: http://www.ucapps.de/mios32/midibox_ng_v1_037_pre10.zip It allows to specify ranges, e.g. with: set_active (id)ENC:1..4095 0 all encoders will be set to non-active state Best Regards, Thorsten.

Hi, linking this information with your proposal for "bulk operations", and it makes sense ;-) Would "combined" set_active help to reduce the number of commands, or are there other commands which are repeating a lot? Best Regards, Thorsten,

Important: when you are experimenting with NRPN, please use the latest version which got a fix for the NRPN numbers: http://www.ucapps.de/mios32/midibox_ng_v1_037_pre9.zip (I will release this soon to make the changes official) Best Regards, Thorsten.

Thanks for the valuable feedback! yes, by intention I wanted to keep the procedure "as is". Best Regards, Thorsten.

@sis.tm concerning MacOS update: I will observe this - once I got more indicators what could go wrong there, I will try to safeguard the upload. There are already some measures (e.g. checksums and handshakes), but it seems that this isn't enough. Otherwise: sometimes patience is a virtue - hopefully Apple will fix this. Concerning CV modules: just tested at my side. No ground hum, and no noticeable noice. Only if I extremely amplify the audio signal in my DAW, I can notice some digital noise (at an ignorable -80 dB level) which disappears if I disconnect CV and Gate, but definitely no hum. The system: MBSEQ is connected via a externally powered USB Hub to a MacMini 2012, a "Kraftzwerk" is connected to the CV interface, and Audio is connected to a Firestudio Mobile. Best Regards, Thorsten.

Hi @sis.tm this is interesting! I noticed a similar effect some weeks ago, first download was incomplete. Since neither the bootloader, nor MIOS Studio have been changed, my conclusion was that it's either related to my USB Hub, or a MacOS update. Are you also using MacOS "Catalina" (10.15)? Best Regards, Thorsten.

I think that you mis-interpreted the LFO function of MBSEQ To the configuration: once you store the "global setup" in the SAVE page, you could also edit the values directly with the edit function of MIOS File Browser (I think the file is called DEFAULT.CV2, search for it) - I'm doing the same, much faster :) Best Regards, Thorsten.

I need more input to help on this. Last time you tried v096_pre9, and this version seem to work at your side, right? Older versions are archived under: http://ucapps.de/mios32/backup/ so, you could try the archived v096_pre9 again - is it crashing as well? And in case it is crashing (maybe because you are using a feature which wasn't tested by myself): which of the pre* versions doesn't cause the problem? Best Regards, Thorsten.

note that this is not really comparable with a real LFO - it's a LFO intended to send out MIDI events, and a typical resolution of MIDI is 1 mS -> means, higher frequency will appear very steppy! I looked into the source code (that I wrote many years ago) - and you are right: Sine is a bipolar triangle, and triangle only used the positive range At the time I implemented this, I found this sufficient Best Regards, Thorsten.