TK.

yes, up to 2 keyboards can be scanned separately. Alternatively - since no velocity is involved - you could also scan the keyboards as a DOUT_MATRIX. Up to 16 matrices are supported. Best Regards, Thorsten.

Hi, the best choice is a MBHP_CORE_STM32F4 core, running with the MIDIbox NG firmware: http://www.ucapps.de/midibox_ng.html Because this firmware supports CV outputs and it can scan a keyboard on a similar way like MIDIbox KB: http://www.ucapps.de/midibox_kb.html Best Regards, Thorsten.

Thanks for the hints! I added them to the wish list so that they won't get lost. I will probably check this by end of this month. Best Regards, Thorsten.

Yes, by telling the MBNG that a 8x8 DIN matrix is connected, it will scan the inputs and provide them for further event processing. In the cfg/tests directory you will find a lot of additional programming examples which might help: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2F E.g. this example shows the most simple way to send Note Events from a DIN matrix: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fblm8x8.ngc And when you compare this configuration with the detailed description under http://www.ucapps.de/midibox_ng_manual_ngc.html you will notice that there are much more possibilities - the example only gives you a starting point. Best Regards, Thorsten.

The BLM_X is the right choice (and not the KEYBOARD driver) Programming Example: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fexamples%2Fblm_x%2F Following configuration is required in mios32_config.h: // configure BLM_X driver #define BLM_X_NUM_ROWS 8 #define BLM_X_BTN_NUM_COLS 8 #define BLM_X_LED_NUM_COLS 8 #define BLM_X_LED_NUM_COLORS 1 #define BLM_X_ROWSEL_DOUT_SR 1 #define BLM_X_LED_FIRST_DOUT_SR 2 #define BLM_X_BTN_FIRST_DIN_SR 2 #define BLM_X_ROWSEL_INV_MASK 0x00 #define BLM_X_DEBOUNCE_MODE 1 Schematic which shows the DIN/DOUT mapping: http://www.ucapps.de/midibox_seq/mbseq_v4_dio_wilba_layout.pdf Best Regards, Thorsten.

Yes, they have to change the octave, since the semitone transpose range only goes from -8..+7 Therefore I added a tricky part which automatically changes the octave and uses a negative semitone value. The result should be the same, please check this! Best Regards, Thorsten.

should work now (link to pre8 below( issue is understood, but change isn't so easy, and will lead to incompatibilities. The background: the guide track defines the measure length in 16th notes unrelated to the track divider settings Maybe a proper documentation of this imperfection would help instead of an implementation change? Noticed in the wish list, but a change won't be so easy... did you already try the new BUTTON_RECORD behaviour which has been introduced in pre7? For me it sounds that it's doing what you've requested Could you please try following pre-release? -> http://www.ucapps.de/mios32/midibox_seq_v4_091_pre8.zip The transpose page got a new function >SCALE< which is active when you enter the page. Octave is controlled with GP2..8, and the semitone (based on the scale) is selected with GP9..16 Best Regards, Thorsten.

Cooler Button! Haette der eine 3-Wire LED eingebaut, haette ich wirklich einen Verwendungszweck dafuer :) ja Gruss, Thorsten.

Hi, thanks for the information! I'm not planning to move to another core this year, but it's good to follow the progress on the market. Best Regards, Thorsten.

Hallo, Du koenntest die LED zwischen zwei DOUT Pins anschliessen. Ein DOUT Pin sollte auf 1, der andere auf 0 stehen. So kontrollierst Du die Farbe. Es waere jedoch besser, wenn Du eine 3-Pin LED nimmst. So koenntest Du die LED auch noch in einer dritten Farbe (Rot+Gruen = Gelb) aufleuchten lassen Gruss, Thorsten.

yes, the probability is 50:50 it will only randomize the note value between -12/12 semitones Yes, in ascending order yes Best Regards, Thorsten.

Alright, fine! DIN/DOUT functions can be alternatively mapped to the IO pins at J10, search for the "J10" keyword in the tutorial Best Regards, Thorsten.

Thanks, this helped! TRACK1 LED is working again when you add following definitions to your MBSEQ_HW.V4 file: LED_JAM_LIVE 0 0 LED_JAM_STEP 0 0 With the next version it will also work w/o these extra definitions (LED_JAM_LIVE/STEP will default to 0) Best Regards, Thorsten.

No issues at my side, regardless if I try it with the Wilba or Legacy Frontpanel. Could you please attach your MBSEQ_HW.V4 file? (or are you using a file which is released with the installation package?) Best Regards, Thorsten.

This page refers to a feature which was introduced with the MIDIbox NG version V1.019 (I added this detail to make it clear) commands have to be entered into the special text box under the terminal window Best Regards, Thorsten.

Thanks! Finally the detail that I missed. Should work with this version: -> http://www.ucapps.de/mios32/midibox_seq_v4_091_pre7.zip Best Regards, Thorsten.

Hi, Bootloader V1.018 is fine, where did you find the hint that V1.019 should be used? No, a MIOS32 application doesn't replace the bootloader, this part resists in a protected range. You could upload the application .hex file directly with ST Link, in this case the flash gets the bootloader + application binary In both cases MIDI upload should work No, the ignorable error really can be ignored, no reason to be worried about that Questions to you: - which Windows version are you using? - some Windows versions require the "single_usb" option, see also: http://www.ucapps.de/mios32_bootstrap_newbies.html - note that the single_usb option will be overwritten to the default (0) whenever you are overwriting the flash contents with the ST link programmer. Proposal for further troubleshooting: - flash the MIOS32 bootloader update application again with ST Link - activate the single_usb option via MIOS Studio terminal as described in the "newbies" page (search for "single_usb") - after "store", reconnect the USB cable - wait until Windows found the device - re-open MIOS Studio - upload the application Best Regards, Thorsten.

I checked this at my side, the restart option works as expected. False Restart triggering might occur if multiple sources control the arpeggiator. It's important, that either your external keyboard, or a loopback track controls the T&A bus. They shouldn't control the bus at the same time The delay is due to the step synchronisation. Best Regards, Thorsten.

Could it be, that no session has been created yet? Now also updated in the pre-release below please try the pre-release below (but I haven't changed anything for the drum triggers...) I can't reproduce this, the first steps are played when MIDI delay is used. Is this somehow related to the issue that you reported on the 17th march? I can't reproduce this, the first steps of all other tracks are played in step and live recording mode should work in the pre-release below Thanks for pointing this out! The schematic has been fixed. I changed the Fx assignments again: o hwcfg/wilba*/MBSEQ_HW.V4: default F1-F4 assignments changed to: F1: Track Select, F2: Live Forwarding, F3: Recording, F4: Save All Here a link to the pre-release: -> (removed obsolete link) -> please find pre7 in one of the next postings Best Regards, Thorsten.

before we drift into an academical discussion: Sauraean, I added the hooks into the MIOS32_SDCARD driver for you, so that you can experiment at application level w/o touching MIOS32 code. The change is available in the SVN repository, please update. MIOS32_SDCARD_SectorRead (and SectorWrite) now contain: // read 512 bytes via DMA #ifdef MIOS32_SDCARD_TASK_SUSPEND_HOOK MIOS32_SPI_TransferBlock(MIOS32_SDCARD_SPI, NULL, buffer, 512, MIOS32_SDCARD_TASK_RESUME_HOOK); MIOS32_SDCARD_TASK_SUSPEND_HOOK(); #else MIOS32_SPI_TransferBlock(MIOS32_SDCARD_SPI, NULL, buffer, 512, NULL); #endif so, once a function for MIOS32_SDCARD_TASK_SUSPEND_HOOK has been assigned, it will be called after MIOS32_SPI_TransferBlock. In addition, MIOS32_SDCARD_TASK_RESUME_HOOK will be called by the DMA callback In your mios32_config.h file, add following code: extern void APP_SDCARD_TaskSuspend(void); extern void APP_SDCARD_TaskResume(void); #define MIOS32_SDCARD_TASK_SUSPEND_HOOK APP_SDCARD_TaskSuspend #define MIOS32_SDCARD_TASK_RESUME_HOOK APP_SDCARD_TaskResume And somewhere in your app.c file: void APP_SDCARD_TaskSuspend(void) { // suspend task here } void APP_SDCARD_TaskResume(void) { // resume task here (will be called from DMA callback, it's an ISR) } Best Regards, Thorsten.

No problem at my side, something is probably wrong in your MBSEQ_HW.V4 file Try the original hwcfg/wilba/MBSEQ_HW.V4 file, if you notice the same, then maybe related to a connection issue? In this case, I would expect that the same issue happens with older versions Best Regards, Thorsten.

No problem at my side, something is probably wrong in your MBSEQ_HW.V4 file Try the original hwcfg/wilba/MBSEQ_HW.V4 file, if you notice the same, then maybe related to a connection issue? In this case, I would expect that the same issue happens with older versions Best Regards, Thorsten.

I assume that only a minority of applications need this. During SD Card transfers FreeRTOS will switch to other higher prio tasks automatically within 1 mS (preemptive multitasking is enabled). If you organize the task priorities accordingly, there isn't a problem with the blocking behaviour. E.g. I don't see a need for MBSEQ, MBNG, MBCV Best Regards, Thorsten.

Alright, so could you please try following pre-release at your side? -> http://www.ucapps.de/mios32/midibox_seq_v4_091_pre5.zip Changes: o Jam page: AStart now starts to record into first step in live recording mode (as intended), it starts on the selected step in step recording mode o Purpose of Record and Live Button & LED change: they switch between record (and live) mode w/o changing to the Jam page o new button/LED combo: JAM_LIVE and JAM_STEP: they switch to the JAM page and select Live resp. Step recording mode o removed obsolete (non-working) pattern based scale control as you can see, the Auto-start doesn't change the selected step in step recording mode anymore, because this causes more issues than it's worth to add workarounds into the code. I guess that you are sending CC#03 from a CC layer of a Note track. In this case, each step will send a CC independent from the gate, which means that you've to configure the correct scale value for each step of the CC layer, otherwise steps with value 0 will change back to 0:Major. If you are using a CC track instead, the value will only be sent if the gate is enabled. Best Regards, Thorsten.