TK.

Probably can be controlled with Roll and Roll2 layer: http://www.ucapps.de/mp3/midibox_seq/mbseqv3_gl_multi.mp3 Best Regards, Thorsten.

Hi, could you please zip your session directory and attach it to this thread? Maybe next week I will have some time to look into this. Best Regards, Thorsten.

You are right, it would be better to make this function optional. Please try this version: http://www.ucapps.de/mios32/midibox_seq_v4_095_pre14.zip It's switch #9/29 in the options page Best Regards, Thorsten.

Wow!  Best Regards, Thorsten.

Wow! I'm impressed!!! :) Best Regards, Thorsten.

Development Queue overflow... %-) Your input won't get lost, but I think that I've to consolidate the ideas and request if still valid based on my proposals once I find the time to think about the implementation... @Rio: thanks! :) @beautyofdecay_ I added an experimental AOUT calibration feature:   o V4+ AOUT: support for AOUT channel calibration. In the CV configuration menu, turn GP ENC #7 until 0V/1V/2V/.../Max will be visible. Calibrate the offset of the target value with ENC #8. Each V has a dedicated calibration value which can be configured this way, the output will be interpolated accordingly. Note that with exiting the CV configuration menu the calibration values are stored on SD Card in the MBSEQ_GC.V4 file (-> CV_Cali <cv-counting-from-0>). You could backup/set/restore the values from there if required. To reset all calibration values: delete all CV_Cali items in MBSEQ_GC.V4, store the file and enter "reset" in MIOS terminal. Please try this version: http://www.ucapps.de/mios32/midibox_seq_v4_095_pre13.zip Does it work at your side? Best Regards, Thorsten.

The MIDIbox NG application has such an interpolation routine which could be re-used for calibration purposes in MBSEQ. However, I'm a bit surprised that a SW based calibration is required. Which AOUT module are you using? And how big is the deviation compared to the ideal curve within the 1V segments? Best Regards, Thorsten.

The octave enumeration isn't standardized. E.g. in Logic Studio 0x18 is C0, and as far as I remember, you can configure MIDI-Ox to print the same. No need to change (or to add an option) at my side. Best Regards, Thorsten.

Really well done Peter and Andy! For me it's always a great honor when people pick up the MIOS32 code basis, and make something new out of it. Especially when it's useful for myself - I definitely need one! :) Best Regards, Thorsten.

A solution will be available with v4.095 (changes are already in the repository): o OPTIONS page: new option "Print and Modify Steps w/o changing Gate". If enabled: note values will always be print regardless if they are played or not. Changing a note value won't automatically enable the gate Best Regards, Thorsten.

Just got a flashback: this is actually a known issue and I thought that I fixed this some years ago... somehow the change didn't find it's way into the repository. I updated mios32/LPC17xx/mios32_board.c, please update your repository Best Regards, Thorsten.

I uploaded some bassline patches of "TK2 soundbank" that I created the last years, but never released (want to archive them :) http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fpresets%2F Some demos (6 of 28 basslines): http://www.ucapps.de/mp3/midibox_sid/mbsid_v2_tk2_soundbank_demo_part2.mp3 Best Regards, Thorsten.

Interesting! If there is really a file limit, it could make sense to change the application so that it uses a dedicated directory for each bank Best Regards, Thorsten.

There are good reasons why I decided to use an UART based MIDI interface for interconnections: universal approach, easy to setup from a (PC) and easy to connect to other cores MIDI messages are buffered via FIFOs, this relaxes the MIOS32 application requirement. E.g. it could prioritize the handling of other tasks and doesn't need to frequently poll for incoming messages to avoid information loss. By default the FIFOs are dimensioned with 64bytes, which means that we can bridge up to 20 mS no need to program special interface communication handlers -> less troublesome & no special knowledge required MIDI cable can be up to 10m optocouplers decouple the noisy MF voltage from the MIOS32 core, this improves EMC level-shifting 3.3V to 5V part of the physical MIDI interface So, if you are searching for alternative interfaces, they all have cons you have to learn how to program such interfaces. I won't have so much time to help you on this... you've to find your own way the MBNB_MF_NG firmware is programmed in assembly language which is difficult to enhance for people who never did this before all IO pins of the MBHP_MF_NG module are allocated, for a different interface you've not only program a new firmware, you also have to change the circuit Possible interfaces: SPI Cons: no programming example available for MIOS8 requires 4 IO pins (RC3, RC4, RC5, RA5) MBHP_MF_NG circuit has to be modified. But especially RA5 does hurt, since this is an analog input (actually a killer argument) no programming via MIDI possible anymore, you've to use a PIC programmer instead actually more valuable than MIDI ports, since only 3 SPI interface ports exist on a typical MIOS32 core. One (J8/9) is allocated for SRIO, another one (J16) for SD Card and Ethernet at 3.3V level, another one (J19) is free, but typically used for AOUT/AINSER, etc... However, if SPI, than you would either have to sacrifice J8/9 (-> no SRIO), or J19 (-> probably unusued in your application? But couldn't be used for all applications, so: only a dedicated solution for your purposes) MIOS32 core has to frequently service the SPI to avoid message loss programming will be much more complicated I2C Cons:  requires 2 IO pins (RC3, RC4) MBHP_MF_NG circuit has to be modified no programming via MIDI possible anymore, you've to use a PIC programmer instead MIOS32 core has to frequently service the I2C I2C overhead higher than for other interfaces, will slow down your application and/or result into message loss programming will be much more complicated CAN Cons: requires different PIC chip (e.g. PIC18F4685) requires 2 IO pins (RB2, RB3) MBHP_MF_NG circuit has to be modified MIOS32 core has to frequently service the CAN interface. Similar to I2C and SPI there is a high risk for message loss if this isn't done frequently programming will be most complicated compared to other interfaces Best Regards, Thorsten.