TK.

Hi Julian, button ids are normally mapped to digital inputs of MBHP_DIN modules connected to the SRIO chain via J8/9 If you want to trigger button events with J10A:D0..D7, you could use the button emulation function of the SCS (because the SCS is normally connected to J10A) So, please try: RESET_HW # the SCS should emulate button/enc functions in main page SCS soft1_button_emu_id=2000 \ soft2_button_emu_id=2001 \ soft3_button_emu_id=2002 \ soft4_button_emu_id=2003 \ shift_button_emu_id=2004 \ enc_emu_id=2000 EVENT_BUTTON id=2000 type=CC chn=1 cc=16 range=0:127 ports=1111000000000000 EVENT_BUTTON id=2001 type=CC chn=1 cc=17 range=0:127 ports=1111000000000000 EVENT_BUTTON id=2002 type=CC chn=1 cc=18 range=0:127 ports=1111000000000000 EVENT_BUTTON id=2003 type=CC chn=1 cc=19 range=0:127 ports=1111000000000000 EVENT_BUTTON id=2004 type=CC chn=1 cc=20 range=0:127 ports=1111000000000000 Best Regards, Thorsten.

Yes, now your MBSEQ V4L turned into a MIDI FX machine. Cheers! Best Regards, Thorsten.

Alright. Note that the new bootloader won't change the LCD behaviour at your side. I'm sure that this is a HW issue, because I've checked the SW drivers with various CLCDs and GLCDs some time ago, and you are the first guy who reported such an effect. Best Regards, Thorsten.

Ok, please try this version: http://www.ucapps.de/mios32/midibox_seq_v4l_085_pre1.zip The clock divider should be taken over for all tracks now (not only the note tracks) I wasn't able to reproduce the PitchBend issue, but this might be related to a handling error. E.g. the CLEAR function will only clear the note tracks if you push GP button #1 resp. #9 In order to clear the PitchBend track, push CLEAR+GP button #4 resp. #12 The LED above these buttons should flicker if PitchBend events are sent Does this help? Best Regards, Thorsten.

Ok, understood. I spend some time in order to make this possible - the configuration isn't straightforward, but I hope that this will meet your expectations: upload this firmware to the core: http://www.ucapps.de/mios32/midibox_seq_v4l_085_pre1.zip enter the "store" command after upload. This will ensure that the latest parameters are visible in the file (that's the reason why LiveForceToScale wasn't visible previously - last time you stored this file was with a version which didn't provide this parameter) edit the MBSEQ_C.V4 file: Change MIDI_BUS_Channel 0 ... to MIDI_BUS_Channel 0 17 (bus will listen to all channels) Change the MIDI channel of MIDI_BUS_Channel 1 ... and MIDI_BUS_Channel 2 and MIDI_BUS_Channel 3 ... to 0 (bus won't listen to channels) Change LiveKeepChannel to 1 Parameters should be taken over automatically once you save the file (terminal will show "AUTOLOAD 'MBSEQ_C.V4'") Best Regards, Thorsten.

Yes, there is a hidden feature in MBSEQ V4L which allows you to enable force-to-scale for the In->Out option! :) Connect to MIOS Studio, open the MIOS32 File browser, edit the SESSIONS/DEF_V4L/MBSEQ_C.V4 file. Search for "LiveForceToScale" and set it to 1 Thereafter save the change, and then enter "reset" in MIOS Terminal in order to reboot the device. Best Regards, Thorsten.

Hi Benoit, there is a workaround for this in following (unreleased) version: http://www.ucapps.de/mios32/mios32_bootloader_v1_016.zip (store command will be retried if flash operation failed - I guess that this is related to flash protection, but haven't debugged this further. With the retry the store command will work reliable) LCD: it's very likely a hardware issue. LCD isn't correctly initialized after power-on, and in your pictures it looks like the second line will never be written. This indicates, that the D6 pin is always 0 Check it with the scope. If it doesn't toggle than my assumption is correct and you know where to continue with debugging. Best Regards, Thorsten.

Hi, you could switch between the modes with the Ctrlr based editor: It makes sense to explore the capabilities of MBSID with this editor anyhow before you start editing with the CS :) Best Regards, Thorsten.

Ok, you already found out the required calculation by yourself! :) For the case that it helps: in mf.inc you will find following lines MF_Tick_TraceFader movff ADRESL, MF_TRACE_VALUE_L ; take original value from ADC so that AIN deadband doesn't matter! movff ADRESH, MF_TRACE_VALUE_H You could replace them by: MF_Tick_TraceFader movff MF_VALUE_L, MF_TRACE_VALUE_L ; take original value from ADC so that AIN deadband doesn't matter! movff MF_VALUE_H, MF_TRACE_VALUE_H in order to display the translated response in MIOS Studio There is no alternative way how I can help you to visualize the changes. I know that the task to find a satisfying calibration table w/o further analysis is a challenge - but providing more sophisticated debugging helps would result into much more effort at my side. Best Regards, Thorsten.

Please follow this guide: -> http://www.ucapps.de/midibox_seq_manual_tut5.html It should answer both questions. If not, please let me know what is unclear, I will improve the page! :smile: It's possible to route the transposers & arpeggiators to different busses in order to handle up to 4 independent note entries (regardless if from external keyboards or loopback tracks) Best Regards, Thorsten.

Hi, yes, you can use the same board, but since LPC17 Tx pins are working at 3.3V level (and not in push-pull mode), you've to change some resistor values: R3, R5, R8 and R10 have to be 47 Ohm. And J1:Vd has to be connected to 3.3V Best Regards, Thorsten.

No spam, keep up the great work - I enjoy each new video! :smile: Best Regards, Thorsten.

This is strange indeed! I will check this tomorrow - if I haven't success, I will add a debug mode which will give you some logs for further debugging. yes, very likely. This isn't intended, I will change this. You can never have enough diodes for the next projects! However, fixed ;) Best Regards, Thorsten.

Yes, I second Pete's hint: the cursor addresses are different compared to "common" LCD sizes. But the cursor mapping has to be done at the application side, e.g. via MIOS32_LCD_CursorMapSet See also: http://www.midibox.org/mios32/manual/group___m_i_o_s32___l_c_d.html#g1d34ecba2a96a80c9bb8b1ee757b4fdf So: if your application doesn't use $MIOS32_PATH/modules/scs, the proposed define won't help. In your application you can either do this statically by calling MIOS32_LCD_CursorMapSet w/o conditions, or you could request the configured LCD dimensions from the bootloader section. Use this MIOS32_LCD_ParametersGet function for this purpose: http://www.midibox.org/mios32/manual/group___m_i_o_s32___l_c_d.html#gd2ee61cebc910769c800afe4c6e281bd This will return following parameters: http://www.midibox.org/mios32/manual/structmios32__lcd__parameters__t.html Best Regards, Thorsten.

Ok, please try this firmware: http://www.ucapps.de/mbhp/mbhp_mf_ng_v1_005.zip Once installed, follow the instructions of this README.txt: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmbhp_mf_ng%2Ftools%2FREADME.txt I will officially release this version if you can confirm that it's working at your side. Best Regards, Thorsten.

Ok, this obsoletes all other questions and now I understand what you did. This of course reduces the scan frequency by x * 1 mS, results into 32 mS (as you've mentioned) and if you are saying that there is a HUGE improvement then let it like it is, everything else will overcomplicate the project. I've to add that this was a clever idea! I haven't expected that the pulse is weak enough so that it will be filtered out on lower frequencies! :) This hasn't been forgotten... but please be a little bit more patient. Before giving you any code I've to test it, because everything which hasn't been tested typically doesn't work due to unexpected reasons, especially when I'm doing changes in code that I wrote many years ago! You can try this in the terminal: perl -version perl isn't installed if this command won't be found. There is no limitation, because the perl script will do the calculation work, the PIC will only process pre-made tables. Best Regards, Thorsten.

No, totally wrong... Without going into too much detail: this would work in MIOS32 projects where the SRIO is scanned via SPI, but it doesn't work on a PIC where the SRIO is scanned directly from the PIC via bit-bangning. This is done each mS, the number of SRIOs doesn't change this. And if somebody would try to reduce the timer period for the bit-banging routine, the PIC would be busy with scanning the SRIO, but wouldn't be able to do anything else (-> no motor control). So, forget this change please, embedded programming is sometimes not straightforward, you've to consider many limitations to come to a compromise which works in reality. I think that on a PIC the touch sensor handling can't be optimized anymore. MIOS_SRIO_NumberSet doesn't set the scan frequency, it sets the number of SRIO components modulo 16 Which means: 32 % 16 = 0 -> no SRIO is scanned anymore, no noise... but also no touchsensor scans, right? but you can compile in the terminal, right? (I don't use Xcode by myself, too complicated ;-)) Best Regards, Thorsten.

Juce ist the best choice for cross-platform; it's freely available, but meanwhile also used in commercial products. Best Regards, Thorsten.

Thanks! I removed this artifact - the file selection & program/verify is explained two pictures above. Best Regards, Thorsten.

Wow, der Sound ist wirklich super! Best Regards, Thorsten.

Implemented in V4.084 (select current track with NRPN MSB=127) Best Regards, Thorsten.

Implemented in V4.084 Best Regards, Thorsten.

V4.084 is now available for download: http://www.ucapps.de/mios32_download.html Changes: MIDIboxSEQ V4.084 ~~~~~~~~~~~~~~~~~ o the STM32F4 variant of the firmware supports USB Host mode! See also o If Force-to-Scale is enabled, the edit screen shows the forced keys at the lower line. The original value is still displayed at the upper right line. o Live Page: FTS (Force-To-Scale) not applied on drum tracks anymore o Options Page: added new option which enforces Force-To-Scale for BLM16x16+X Grid Edit mode o Euclid Generator Page: velocities are re-generated automatically whenever VelN or VelA value is changed o the optional RECORD button now toggles between RECORD and EDIT page (previously it only switched to the RECORD page) o Song page: new action "Unmute all" will unmute all tracks and parameter layers o Mixer: in the UTIL->Options page it's now possible to define if CC1, CC2, CC3, CC4 should be sent after or before the Program Change event. o NRPN MSB=127 allows to modify parameters of the currently selected track Best Regards, Thorsten.

The operation via USB is working fine, but I never tried it via the camera connection kit. Are you able to send & receive MIDI events from other iPad apps? If not: there is a general problem with the camera connection kit. Best Regards, Thorsten.

No changes are required in any config file. IIC1*...IIC4* (the Asterisk) indicates, that the communication with the appr. IIC MIDI chips was failing. Please use the iic_midi diagnosis app for further debugging at the hardware side (connections, soldering joints, etc...) It can be found at the bottom of this page: http://www.ucapps.de/mios32_download.html Test procedure: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftroubleshooting%2Fiic_midi%2FREADME.txt Best Regards, Thorsten.