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.

Finally!!! :) I will look into the velocity issue soon The board that I built some years ago is still functional and I typically show it to MIDIbox HQ visitors as one of the unknown projects that the community started but never released :) Best Regards, Thorsten.

@Rio: please try this version: http://www.ucapps.de/mios32/midibox_seq_v4_095_pre12.zip o OPTIONS page: new option "Print Notes with transposed value". Enabled by default (due to change in V4.093), can be optionally disabled now. @goyousalukis works fine for me. Could you please check if TrgA is disabled? Use GP9 to scroll the page until TrgA get's visible. Then turn off the value to -- Best Regards, Thorsten.

This was a translation error in the code, it's fixed now (and enhanced by a new feature! :) http://www.ucapps.de/mios32/midibox_seq_v4_095_pre12.zip o AOUT: Channel 9..12/13..15 now set the gate pins #1/3/5/7 as documented (previously it was #1/2/3/4 due to a code translation error) New: gate pins #2/4/6/8 are now set whenever the velocity is >100. This way the pins can be used as an accent trigger Best Regards, Thorsten.

This is a very clever idea, thanks for this!! For those who want to try it out - it's now available in following preliminary release: http://www.ucapps.de/mios32/midibox_seq_v4_095_pre12.zip o AOUT: Channel 9..12/13..15 now set the gate pins #1/3/5/7 as documented (previously it was #1/2/3/4 due to a code translation error) New: gate pins #2/4/6/8 are now set whenever the velocity is >100. This way the pins can be used as an accent trigger Best Regards, Thorsten.

Well done! Nice entry project for people who want to check their SMD soldering skills before trying the new MBSEQ frontpanel. Best Regards, Thorsten.

Will add an option for transpose value display and check the reported issue soon Best Regards, Thorsten.

Hi, concerning the displays: I remember that I added an option for 4 LCDs to the firmware for somebody who had 2x20 LCD modules which were bigger than the common ones: Picture was created 2010, not sure if such displays still exist Best Regards, Thorsten.

To 1) yes, you've to add a SD Card. If you haven't purchased the SD Card socket yet, you could also use a common Mini SD Card adapter as available in super markets. See also the bottom of this page ("Alternative Adapter for MBHP_CORE_STM32F4 module): http://www.ucapps.de/mbhp_sdcard.html 2) programming is similar, but parameters have to be entered into the .NGC file. See also following page: http://ucapps.de/midibox_ng_manual_ngc.html Search for "he keyboard command" 3) see kb_2.ngc and kb_6.ngc/kb_6.ngr example configurations Best Regards, Thorsten.

Hi Frank, no, fortunately these mistakes won't damage the ICs. and yes, each keyboard has a dedicated din_inverted flag :) Best Regards, Thorsten.

I noticed that the last release was done 2 years ago, although many preliminary versions have been created meanwhile. Therefore it's now officially available. From the ChangeLog: MIDIbox NG V1.036 ~~~~~~~~~~~~~~~~~ o new .NGR script command: send_seq (see cfg/test/seq* examples) o added new MIDI event types: Clock, Start, Stop, Cont o added new meta events to control a MIDI clock divider: MClkSetDivider, MClkDecDivider, MClkIncDivider o added new .NGC file configuration parameters: MidiClkOutPorts and MidiClkInPorts o new LCD format character '%L' allows to display logic control digits (MTC and status digits) o added new .NGR commands SET_KB_TRANSPOSE and SET_KB_VELOCITY_MAP. The configuration example can be found under cfg/tests/kb_6.ng* o encoder absolute mode: negative ranges are now handled correctly o .NGR LCD command: %d outputs the ^value Best Regards, Thorsten.

You are right, it makes much more sense if program change steps are disabled. Change is already done in the repository and will be available with the next (pre-)release. Best Regards, Thorsten.