TK.

Hi Alex, I've no experiences with this. If you've luck you will find special fader knobs with some kind of extension yes, please start it simple and extend over time before building a case. Motorfaders can first be tested standalone by connecting the MBHP_MF_NG module directly to the PC. Once they are working, continue with the STM32F4 based core module, try to get the communication between this core and MBHP_MF_NG working. Continue with bank buttons, add encoders, etc. step by step Best Regards, Thorsten.

Hi Robin, how did you set the environment variables exactly? Here a prebuilt file to doublecheck if it's working better with correctly set variables: http://www.ucapps.de/tmp/005_polling_j5_pins.zip Best Regards, Thorsten.

This case really puzzles me! The MIOS Studio based MIDI IN/OUT monitor log was actually the most useful input, because it shows me that during the query STM32F4 responses with a delay of more than 1 second, which means that something really strange is going on in the application; actually the response should happen within 1..2 mS Let's continue to check different applications, here some prebuilt ones: http://www.ucapps.de/tmp/stm32f4_usb_test_files.zip Please report your observations on all three .hex files. (you can upload a .hex file in bootloader hold mode via MIOS Studio). app_skeleton_r2023.hex: minimal application with the old USB MIDI driver app_skeleton_unmodified.hex: minimal application with the new USB MIDI driver, USB Host and Device mode enabled app_skeleton_without_usb_host.hex: minimal application with the new USB MIDI driver, only Device mode enabled After the app has been started, just check the response by pusing the Query button, that's sufficient. (the MIOS terminal won't work since it isn't supported by the application) Best Regards, Thorsten.

Hi Robin, are they even 0.3V if the inputs are not connected to ground? (they should be around 3V instead since an internal pull-up is activated) Maybe you are checking the wrong pins of the J5* sockets? 5 pins of the "inner" side are Vd + 4 inputs, 5 pins of the "outer" side are ground. Best Regards, Thorsten.

Al Spitzley created a compact PCB for this purpose, here a picture of the prototype: It provides 16 gate triggers and even 10 CV outputs for velocity sensitive drums. I'm not sure if and when he would like to run a batch order, you could ask him nicely. Best Regards, Thorsten.

The mixer map association is fixed with the pattern, not with a track. The program change parameter layer type is not intended for your use case, it was a special request from a user who wanted to switch patches for each step. Actually you are asking for a program change value which should be configured somewhere in the track configuration, and sent whenever you are changing a pattern, right? Best Regards, Thorsten.

Thanks for the compliments! :) Yes, a TTL based connection without optocoupler between PIC and STM32F4 is possible. Beside of the PA3 connection, you also need to connect the grounds together. Best Regards, Thorsten.

Hi Robin, sometimes the LED flashes three times, that's normal and no problem. Since the LED is flashing, it's ensured that the bootloader is installed properly. No need to work with the ST Utility anymore. Connect a button and toggle it, or just disconnect/connect the cable. Whenever you are doing this a Note Event should be sent. very unrelated to the Bootloader. I guess that you are able to select the MIDI IN/OUT port of your core module in MIOS Studio, right? And the Query button returns some board informations, right? This would mean that the application is running successfully. Did you already try out other tutorial applications? Best Regards, Thorsten.

Hi, It seems that even with the old driver USB communication is failing, which indicates that something is wrong with the hardware. E.g. the message which is sent by the core contains the "MIOS32" string as expected. MIOS Studio would thereafter request the board string, but it seems that the core doesn't respond anymore. I never heard about a similar case in the past. Next experiments: 3) keep the bootloader mode (don't depress the blue button after the reset has been triggered with the black button), restart MIOS Studio and select the USB MIDI interface of the bootloader. Then press Query again, does it work? 4) I also need to learn more about how you've built the core module. Are you using the MBHP_CORE_STM32F4 PCB, or a selfbuilt version? Experiment: unplug the STM32F4DISCOVERY board and connect the PA9 pin to the 5V input with a short cable like shown here: Try the Query with the MBSEQ application - result? Best Regards, Thorsten.

It's normal that the size has changed, because you've flashed a different (especially larger) .hex file. Next steps under MacOS: 1) download the "USB Prober" app: http://www.ucapps.de/tmp/USB_Prober.zip It will display the USB devices, the list will be automatically refreshed whenever something changed in the system. Check if you can find the MIOS32 device in "normal mode", and when the bootloader is selected. If the device is displayed in "normal" mode, but not recognized by MIOS Studio (means: no MIDI available), we will continue debugging with this tool. 2) try a MBSEQ release which is using an older USB device driver in MIOS32: http://www.ucapps.de/mios32/backup/midibox_seq_v4_083.zip If this one is working, we've to continue debugging by setting certain options in MIOS32 Best Regards, Thorsten.

New release: Best Regards, Thorsten.

I don't think that you need a new STM32F4. It would be interesting if you still notice the same issue under MacOS. Please use one of my latest prebuilt binaries for reference, e.g. this one: http://www.ucapps.de/mios32/midibox_ng_v1_032_pre4.zip You can upload the .hex file directly with the ST Link tool (under Windows) - it contains the bootloader + the MIDIbox NG application. If no success: we should continue the troubleshooting under MacOS (I will give you further instructions in this case) If success: try also under Windows. If the USB device is not recognized, you could uninstall the MIDI driver assigned to the USB port somewhere in the system settings, and re-connect the USB cable. This enforces a driver re-installation which might help. Btw.: did you already try another USB cable? I remember that there a Micro-USB cables which are only intended to supply power, e.g. for recharging mobile phones. They can't be used for the USB connection itself! Best Regards, Thorsten.

Welcome on board & have a lot of DIY fun! :) Best Regards, Thorsten.

Hi David, yes, the second AOUT based gate should work (but I haven't tested it yet - I only use DOUT pins in conjunction with a AOUT_NG board). However, I just checked the MIDI channel selection with the Lemur patch and noticed that the value display wasn't accurate. In a certain range Channel 2 was displayed, but actually Channel 1 was still selected. I fixed this (for all dials) by surrounding the calculated value with floor() - this seems to work now The updated Lemur template can be found in the repository (I hope that I haven't damaged something because I manually edited the .jzml file instead of doing the changes in the editor) DOUT pins: there is no interconnection test available for MIOS32, but maybe the Lemur update will already help to clarify this. Note that the first gate is available at D7, the second at D6, etc... Best Regards, Thorsten.

Hi Robin, I'm not sure why the wget command itn't working. Could you please try to download the file from your webbrowser? (just click on the link) Best Regards, Thorsten.

Hi, it seems that you are trying to upload SysEx with a bad MIDI interface. Please check the blacklist: http://www.midibox.org/dokuwiki/doku.php?id=midi_interface_blacklist&s[]=whitelist There is also a whitelist: http://www.midibox.org/dokuwiki/doku.php?id=midi_interface_whitelist The recommended "least cost" interface is Neusonik uMIDI/O22, available for 15 EUR e.g. from Thomann: http://www.thomann.de/de/neusonik_umidi_o22.htm Best Regards, Thorsten.

Hi Bartosz, this is a quite old posting, did you solve this meanwhile? I'm a bit unsure if a SD Card will be required for these tests - it shouldn't, but to be honest: I never tried out a keyboard without writing the definitions into a .NGC file. It might be required to enter "RESET_HW" before these commands to ensure that no other configuration overlays the keyboard functions. Best Regards, Thorsten.

:flowers: Best Regards, Thorsten.

The default settings are available in the hwcfg directory of the release package. You can also access it from the web: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Fhwcfg%2F Best Regards, Thorsten.

Added to the wishlist, setting will be stored in one of the next releases. Best Regards, Thorsten.

I guess that this issue has been solved meanwhile, right? Best Regards, Thorsten.

Hi, you can configure this in the MENU->MIDI "Ext. Ctrl" page. With GP Button 12 select the "PrgChange" function, and set the mode to "Pattern". In the same page you can define the MIDI IN port and Channel over which the Program Change event should be received. Best Regards, Thorsten.

Meanwhile this configuration can be done in the Util->Options page, Option 5/13 called "Dump a predefined Mixer Map on Pattern Changes: disabled/enabled". You've to enable this function. Does this help? Best Regards, Thorsten.

Hi, unfortunately you can't simply add this chip to the SRIO chain because of a dedicated protocol which has to be used. It requires some programming knowledge to support it MIDIbox NG, I can't help you on this topic in the next weeks... It will be easier if you would just use a PIC based MIDIO128 V2 and connect it to your MIDIbox NG via MIDI. Especially since MIDIO128 V2 supports up to 128 touch sensors, not only 8! Best Regards, Thorsten.

Hi Robin, please use a qualified MIOS32 toolchain release, and not anything else found somewhere in the internet. The packages for Windows, Linux and MacOS can be downloaded from: http://www.midibox.org/mios32_toolchain/ Best Regards, Thorsten.