TK.

@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.

MIDIbox SEQ V4.096 has been officially released under http://www.ucapps.de/mios32_download.html ChangeLog: MIDIboxSEQ V4.096 ~~~~~~~~~~~~~~~~~ o Only for MBSEQV4+: support for up to 32 CV outputs (and corresponding gates). Means: up to 4 AOUT modules can be chained. Tested with MAX525 (and midiphy Eurorack Expander), but should also work with TLV5630 based AOUT_NG The additional CV outputs can be accessed with MIDI port CV2..4. o AOUT port has been renamed to CV1..CV4 o Utility Page, GP Button #11 now changes to the CV Configuration Page o DOUT_1MS_TRIGGER in the MBSEQ_HW.V4 file has been replaced by a configurable trigger width which can be adjusted in the CV Configuration Page with GP13 now o Improved selection handling for midiphy frontpanel: - if you press&hold the Bookm/Step/Track/Param/Trigger/Instr/Mute or Phrase button, and then make a selection with SEL or GP buttons, the selection button will jump back to the previous function - if you press&release these buttons without a selection, the function stays active. Example: let's say the track selection is active. Press&Hold Param button, change to a new parameter layer, then release the Param button -> the selection buttons will jump back to track selection. If it's desired to permanently control the parameter layer with the selection buttons, just press&release the Param button. o It's now possible to customize the list of labels which are used during track/pattern name and category and drum selection. After booting the new firmware, following files will be created in the /PRESETS folder: TRKLABEL.V4P, TRKCATS.V4P and TRKDRUMS.V4P Edit these files with the MIOS File browser. Uploaded changes are immediately taken over. - TRKLABEL and TRKCATS: are used in MENU->EVNT, "Trk Inst.", "Edit Name" page (Use GP15 to select the Preset) - TRKDRUMS is used on the same page when a drum track is edited (instead of a track name we configure instrument names) Special treatment: TRKDRUMS.V4P also maps MIDI notes to the drum labels. Whenever a new preset drum is selected, the drum note will be changed accordingly. This allows you to fully customize drum maps. The first 16 drums are taken by default whenever a drum track is initialized, and the remaining drums in the list can be optionally selected to replace on of the 16 drum instruments. - TRKLABEL and TRKCATS are also used when a pattern is saved o New option 9/33 allows to unmute tracks on pattern changes o New option 14/33 allows to change the steps of the current selected view only o the MIDI mixer can now send CC values to a bus. This especially allows to record CC changes (configure MENU->MIDI->Port accordingly so that it listens to the bus in Jam mode) o New parameter layer "Ctrl" allows to change track parameters as documented in the doc/mbseqv4_cc_implementation.txt table (previously this was only possible from a dedicated loopback track). o Recording function considers "Ctrl" layers as well if the assigned parameters are changed on the UI o CV Calibration in CV page: special handling for Hz/V curve o CV Calibration in CV page: press GP7 button to switch between bipolar/unipolar display o fixed "lost button mapping" issue if SD Card is removed o MBSEQV4+: fixed MIDI export crash Best Regards, Thorsten.

Actually I wanted to provide SPI slave (see some postings above), so that the module can be connected to J28 instead of ENC28J60 But a UART connection is available as well - and the baudrate is configurable by default. As long as you only need a point-to-point connection, UART is a good choice. But for accessing multiple ports (e.g. BLE and Apple MIDI) SPI would be better, because it considers multiple "cables". Best Regards, Thorsten. P.S.: in context of MBHP_MF_NG: only UART option will work, because SPI is already used for other purposes.

Cheers! My answer was based on the context, but not on your actual use case ;-) Best Regards, Thorsten.

It's available now. Works only with STM32F4 - in the SCS AOUT page, scroll a bit right so that you see the "Cali Offs Disp" items. Display should be set to "Bip." Change "Cali" to -5V, an offset will appear. This one can be increased up to 4095 Following "Cali" points are -4V, -3V, -2V, .. 5V - offsets can be changed between -2048 and 2047 While changing the offsets, use a multimeter to check the result until value is matching. Best Regards, Thorsten.

Ok, I will look into this later today (good to know that I'm not the only one who finds this useful :) Best Regards, Thorsten.

But it should work with EVENT_RECEIVER When we take following configuration: RESET_HW EVENT_RECEIVER id=1 type=SysEx stream="0xf0 0x41 0x10 0x00 0x10 0x12 ^ignore ^ignore ^ignore ^ignore ^dump 0xf7" EVENT_ENC id=1 hw_id=1 label="@(1:1:1)Prm1 @(1:1:2)%03d" range=0:127 fwd_to_lcd=1 type=SysEx stream="0xf0 0x41 0x10 0x00 0x10 0x12 ^chk_start 0x1f 0x00 0x20 0x55 ^val ^chk_roland 0xf7" syxdump_pos=1:0 EVENT_ENC id=2 hw_id=2 label="@(1:6:1)Prm2 @(1:6:2)%03d" range=0:127 fwd_to_lcd=1 type=SysEx stream="0xf0 0x41 0x10 0x00 0x10 0x12 ^chk_start 0x1f 0x00 0x20 0x56 ^val ^chk_roland 0xf7" syxdump_pos=1:1 EVENT_ENC id=3 hw_id=3 label="@(1:11:1)Prm3 @(1:11:2)%03d" range=0:127 fwd_to_lcd=1 type=SysEx stream="0xf0 0x41 0x10 0x00 0x10 0x12 ^chk_start 0x1f 0x00 0x20 0x57 ^val ^chk_roland 0xf7" syxdump_pos=1:2 EVENT_ENC id=4 hw_id=4 label="@(1:16:1)Prm4 @(1:16:2)%03d" range=0:127 fwd_to_lcd=1 type=SysEx stream="0xf0 0x41 0x10 0x00 0x10 0x12 ^chk_start 0x1f 0x00 0x20 0x58 ^val ^chk_roland 0xf7" syxdump_pos=1:3 and send (e.g. via the MIOS Studio SysEx window): f0 41 10 00 10 12 00 00 00 00 10 20 30 40 f7 the LCD will show the expected values 016, 032, 048, 064 It's important that the ^ignore statements in the receivers SysEx string will be replaced by concrete values, otherwise the receiver will respond on any matching SysEx strings which don't transfer the intended information. So, after 0x12, what is normally sent back by your synth if these 4 parameters are requested? Note also, that checksums are not relevant for receivers, therefore I just wrote 0xf7 after the ^dump Best Regards, Thorsten.