TK.

Update to the 1ms delay: I could "pipeline" the triggers, this way we could get a cheap pulse stretcher. Is there the need for more than 4 mS (= 3 pipeline stages)? Best Regards, Thorsten.

New version can now be found here: http://www.ucapps.de/mios32/midibox_ng_v1_037_pre4.zip It's now possible to mix input and outputs on a single port as shown in this example: https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/diocfg_3.ngc And J5 is supported as well (called J5AB) - it's even possible to mix digital with analog functions -> https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/diocfg_4.ngc In your case, please keep the analog pins disabled Best Regards, Thorsten.

The data update rate is only 35 uS for all 4 modules, so no need to make it more complicated :) That's also the reason why I enabled all 32 channels by default, it doesn't make a big difference. Using a second CS line wouldn't help, because SPI transfer time would have to be consumed anyhow. With channel 9-13 you can route note and velocity value to two CV outs - in this case you need all 32 outputs. But you can also route CCs of a track to the CV outs (starting at CC#16 as far as I remember...) Actually I looked into this, but there is a technical problem. The 64 drum triggers are currently cleared with each SRIO update cycle, this was very pragmatic and effective and especially doesn't consume resources (counters) and CPU time (processing the counters) For individual delays I would have to implement counters for each trigger, and this is very costly. And for a single delay we would potentially run into the problem, that each mS a new trigger could reset the counter, leading to "stretched signals" for all triggers for which the configured time already passed... Best Regards, Thorsten.

New major enhancement available for MBSEQ V4+ users - up to 32 CV channels and gates! :-) -> http://www.ucapps.de/mios32/midibox_seq_v4_096_pre6.zip 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 Best Regards, Thorsten.

still relevant or just a quick idea? Will lead to some effort at my side... therefore I would only add this if other people find it useful as well Best Regards, Thorsten.

I guess that you mean MIDI clock/start/stop (MMC isn't supported) They can already be enabled/disabled for each MIDI port in the BPM menu Best Regards, Thorsten.

Fixed in v4_096_pre6

Yes, this will be possible - it's exactly the intention behind NGR to allow users such customizations without touching the application code. Best Regards, Thorsten.

Yes, for me it will be straightforward - I'm just a bit worried that than more options I'm adding, than more complicated for others to understand the configuration... ;-) Tomorrow I'm planning a change for CV handling anyhow, if nothing else happens, I will add J5 IOs as well Best Regards, Thorsten.

IO Pins are not initialized in your pseudo code. But regardless of this, it will result into the problem that the MBNG application will overwrite IO configurations from different places - and even if we find quick&dirty hacks which avoid such overwrites, you would have to re-do the changes whenever a new firmware version is released. Therefore I recommend to go the common way and to use the existing app like it was intended. Alternatively I could consider to natively support J5 as digital IO in a proper way (which will require changes at many places that I've to work out by myself...) Best Regards, Thorsten.

This example should also work with tact switches. For LEDs you could just use J10B Best Regards, Thorsten.

This should be possible, just configure the analog inputs and trigger the NGR function via an EVENT_AIN You could change the value range and enable the filter function to avoid unintended triggers, a demo can be found here: https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/ain_fsr.ngc Best Regards, Thorsten.

Thanks a lot Andy and Peter for this great work! Based on this video tutorial I built up my modules yesterday, all are working fine, almost no troubleshooting was required. :) Now I need a case (I ordered a 4ms Pod40X in the hope that the modules will fit into this case without special measures) Best Regards, Thorsten.

Hi Mentat, Which frontpanel are you using? The function still exists, just the button has been renamed to Parameter Layer C. If you are using a MIDIphy frontpanel, drums can be directly selected with the 16 additional "select" buttons in "instrument" mode. Best Regards, Thorsten.

I think that this question is obsolete: Best Regards, Thorsten.

Hi, you don't need to change the existing code to do this, just use the "set_kb_transpose" command in a NGR script. Following example demonstrates this: https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/kb_6.ngr And here the corresponding events which trigger the ^sections: https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/kb_6.ngc Best Regards, Thorsten.

Additional notes: could be that you rely on 5V output - in this case change MIOS32_BOARD_PIN_MODE_OUTPUT_PP to MIOS32_BOARD_PIN_MODE_OUTPUT_OD, and add a 1k pull-up to 5V to this pin. And if J10A is already used for SCS inputs (standard), just take J10B.D0 (pin index #8) Best Regards, Thorsten.

Another modification in mbng_file_c.c is required where the number of CS lines is hardcoded (actually you should have seen the error message...) I put an example which works at my side into the demo/mbng_ainser_with_3_cs branch, see: https://github.com/midibox/mios32/commit/ac6151ea7012e2b3e5e6a15575b4c4f92c8ffe2f Best Regards, Thorsten.

You don't need to enhance mios32_spi, just control the additional pin directly from AINSER_SetCs E.g. let's assume that J10.D0 is unused so far, then add to AINSER_Init(): MIOS32_BOARD_J10A_PinInit(0, MIOS32_BOARD_PIN_MODE_OUTPUT_PP); and to AINSER_SetCs: case 2: return MIOS32_BOARD_J10_PinSet(0, value); Best Regards, Thorsten.

Unfortunately there is currently no way without a duplicated track. Background: the sequencer engine handles tracks which are sending to an internal bus (so called "loopback tracks") differently compared to common tracks: they are processed before MIDI events of "common tracks" are scheduled to ensure that transposers/arpeggiators get updated before they play the next note independent from the track order they have no timing information - MIDI notes directly processed without delay, note off, echo, etc that's also the reason why the "Duplicate" Fx doesn't allow to route MIDI events to Bus1..4 This approach solved many problems that we noticed in earlier MBSEQ versions (V1..V3), but it has the drawback that loopback tracks can't be used for sending "common MIDI events" anymore. Best Regards, Thorsten.

Hi Bruno, yes, just try it and commit your change in a special branch (from master) - we can merge once we both are satisfied. By searching for defines like MIOS32_SYS_ADDR_SPI_MIDI (e.g. via "grep --rec") you can find the places which need to be modified. Best Regards, Thorsten.

I unplugged the fan power cable at the same day I got my MB6582 from Wilba, and this never caused a problem ;-) Best Regards, Thorsten.

Which values would you like to permanently store & change in the bootloader. I need names + sizes I will define those values in mios32_sys.h within the MIOS32_SYS_ADDR_BSL_INFO_BEGIN section -> https://github.com/midibox/mios32/blob/master/include/mios32/mios32_sys.h As you can see, we can either define a block + confirmation value, or individual values + confirm. If you could predict today how many bytes need to be allocated, we could use a single confirmation which saves space for other future extensions (used for other purposes) Best Regards, Thorsten.

Hi Peter, I'm resistent on this feature, because it will dramatically increase the CPU time and RAM consumption. We've up to 256 layers which could send CCs, and we would have to determine the target value when the start CC is played - means, we've to walk the steps until the next CC is found for each layer, this will consume some uS for each layer! The next CC could change while the sequencer is playing, this leads to special treatments at some places... In RAM we've to store the current, target and sent values for each layer, resulting into 3 * 256 bytes Best Regards, Thorsten.

We could reserve a bootloader location to make this basic_node number configurable without touching the source code. Similar the way I did for other "permanent" flags & values. Best Regards, Thorsten.