Search the Community

@momelq thanks Robert, that all makes sense - i'll notify you when there is a prerelease version with the temporary piano effect available for testing :). The STM32F4 is a quite powerful MCU and there are still resources left - the sequencer engine eats not up that many cpu cycles, the rest is used as a low-priority background task for the display refreshes. So, if we add a CPU-hungry subroutine on a clip, the worst that would happen first is that the screen refresh rate goes down a bit - but of course, it all depends on how complex the algorithm would be. We've also got a bit of RAM to spare (depends a bit on the resolution of the CC storage). If you want to describe the algorithm (via email is also possible), i'd be all ears, but can't promise anything! :) No temporary sustain FX then, it's probably really not necessary or could even be manually activated with separate sustain pedals of the connected synths. Have a nice evening and best regards! Peter

Hi Florian,, I have now nearly the same project in front of me: Generating -- out of a naked TP40WOOD from Fatar that I got some years ago -- a MIDI Keyboard like the Doepfer LMK4+. Doepfer charges 1500€ for this, and the solution with MIDIbox is much, much cheaper, thanks to Thorsten! I'll use the STM32F4 on a MIDIbox NG baseboard plus DIO_Matrix plus MIDI_IO plus AINSER8 (for the wheels and Pots) plus a 2x40 LCD blue plus a MBHP_DIN for the 24 Keys. So the same functions as the LMK4+ and a very similar control panel. But much cheaper. Will see how it works... Next phase is the Mechanics for the whole thing, and then the Electronics and the SW. May be I'll contact you at a later stage if I have questions. Especially the SW development might be a pitfall... Cheers, Andreas

So I am planning to build a microcontroller as an interface between a Mackie C4 Pro and, theoretically, any kind of Hardware/Software component. The component that is to be controlled will be determined, and the configurations specified, by templates which will be stored on an SD card. To realize this I will be using the STM32F4 module with the SD card interface and a MIDI 2x2 module. Eventually another 2x2 is planned to additionally connect a MIDI keyboard. I am a newbie to the MIDIbox forum so I started researching and decided to take the NG project as a starting point. To me this means that in order to implement this I need to alter the .ngc .ngl and .ngr files to a) have a communication with the Mackie that will, basically, always stay the same and b) generically prepare the other side of the microcontroller so that the user can specify the mappings to his hardware/software himself. RPN, NRPN and SysEx must be possible. This of course means that the chosen parameters and their state will be required to be displayed on the Mackie's displays, which, after reading the NG and STM32F4 specifications, I think is possible. A final requirement is that the configurations will have to be stored into a textfile (I was thinking XML) so that the user won't need to actually open the .ngc files and do his settings there, but rather that on startup the device considers the textfile as belonging to a certain configuration file, checks if something was altered in the textfile, if so applies it to the configuration data and then sets that up as the current configuration state. What do you guys think? Does that sound possible? Did I choose the right components? And has anyone ever done something similar and encountered problems that maybe I could encounter too?

Hi ! im trying to build a cheap cdj-styled usb-mp3-player with a raspberry and i went into trouble with the midi-messages from my STM32F4-Core Midibox. I got some pitchfaders, buttons and encoders which i want to use to test walmartone MIXXX(a DJ-SW)-performance. On my windows-machine everything works like a charm with Traktor. I receive the messages with the amidi -p hw:1,0,0 -d command. hw:1,0,0 is the adress of the midibox. For the pitchfaders (midipitch-message) i receive 3 bytes as desired. I use the SendPitchBend-Command for that. For Buttons (MIOS32_Send_CC) i receive lots of junk with the right message at the end: F0 00 00 7E 32 00 0D 40 42 75 74 74 6F 6E 20 38 20 67 65 64 72 75 65 63 6B 74 00 F7 BE 08 7F It should be (Channel 15 CC 08 Value 0x7F) For encoders (MIOS32_Send_CC too) there are also lots of junk bytes in the message: BE 1E 7F F0 00 00 7E 32 00 0D 40 45 6E 63 6F 64 65 72 20 30 3A 20 31 00 F7 In this case the right Message is at the beginning: (Channel 15 CC 30 Value 0x7F) How to get rid of that junkbytes? MIXXX works fine on the pitchfaders but it cant read the buttons and encoders. I already tried to compile my app without MIOS32_USB_MIDI_USE_AC_INTERFACE 1 as i need that setting for windows but there was still the junkbytes in it. Anyone experiend something like this on Linux? How to get rid of these junkbytes? For me the junkbytes doesnt make any sense. But they are always the same at the specific buttons and encoders....

Hello all, After a long time with practically no time to continue my project I have decided to downscale my project. That's why I'm selling a lot of stuff: 1x STM32F4 Core Module Board+ STM32F407G-DISC Assambled, tested and working (no sd card), use at own risk 1x MF_NG Module + PIC Assembled, tested and working, use at own risk 3x MF_NG Module + PIC Assembled (1 board missing 1 IC), not tested 1x Custom MF_NG Module (no PIC) Partly assembled, not tested 1x Custom MF_NG Module (no PIC) Not assembled 1x DOUT Module Assembled, tested and working, use at own risk 1x MIDI IO Not assembled 26x 100mm Alps Motor N fader (some o-lead, some normal lead) Unused, only mounted, no caps 2x 19 inch frontfpanel from dibond (aluminium, plastic, aluminium) 1 with cutouts for 16 faders, OLEDs and led VU meters 1 with cutouts for 8 faders, OLEDs and led VU meters and 2 Steinberg CMC cutouts Preferably selling it as one lot, but I might consider selling individual items. (I might keep de STM32F4, but not sure, defends on the offer) Make me an offer. Shipping costs for buyer.

Seq V4 for sale $600 usd. Midibox SeqV4. in great condition. STM32F4 core. It has 2 IN, 6 midi OUT and 4 midi IN & OUT on the USB (when used on a Mac). It has the OTG mod, a USB type A port to hook up controllers in host mode. Updating can still be done by switching to device mode. Modified power section to accomodate the updated core. Ultimate dawless!.

Hi, I im trying to run simple character lcd, without core module, but keep getting some random chars, or even just blocks, but it keeps blinking. I followed schematic from uCApps page for STM32F4, but the part to set Luminance i dropped and simply connected it to ground, Could be this a problem ? Tried to connect from scratch everything a few times, but still getting the same error... Please, if anyone has a tip what could be the problem, mine is that as i am lame at electronics, somewhere is connection problem maybe, im bit confused about the resistor array. Here is a video showing the behavior of LCD https://drive.google.com/open?id=1CPgCp6t-rewshbGq7Yprdonu_htadADo Thanks, Martin

Hi Karg, I tried switching the voltage toggle to all positions on the STM32F4 but it doesn't resolve the problem. It is on 5v in. Followed the video tutorial to prepare the core. The displays appear to be 3,3v on the Midiphy shop. How can I proceed further? Thanks!

Can anyone confirm that this simple code Work/not Work? j5pinget.zipj5pinget.zipj5pinget.zip anyone with a STM32F4 can test this.... the code should not hang your device since it is only call every second. thx 4 help. #include <mios32.h> #include <FreeRTOS.h> #include <task.h> #include "app.h" // Init J5A+B Pin 0 as ANalog Input void APP_Init(void){ MIOS32_BOARD_J5_PinInit(0, MIOS32_BOARD_PIN_MODE_ANALOG); MIOS32_BOARD_J5_PinInit(4, MIOS32_BOARD_PIN_MODE_ANALOG); } void APP_Background(void) {} // Get J5A-B Pin 0 every second void APP_Tick(void){ static int seccount = 0; // init counter seccount++; if (seccount > 1000) { seccount = 0; // reset counter static s16 state = 0; // Get J5A0 state = MIOS32_BOARD_J5_PinGet (0); MIOS32_MIDI_SendDebugMessage("J5A-Pin0: %d ", state ) ; // Get J5b0 state = MIOS32_BOARD_J5_PinGet (4); MIOS32_MIDI_SendDebugMessage("J5B-Pin0: %d ", state ) ; } } void APP_MIDI_NotifyPackage(mios32_midi_port_t port, mios32_midi_package_t midi_package){} void APP_SRIO_ServicePrepare(void){} void APP_SRIO_ServiceFinish(void){} void APP_DIN_NotifyToggle(u32 pin, u32 pin_value) {} void APP_ENC_NotifyChange(u32 encoder, s32 incrementer){} j5pinget.zip

Do you mean the original STM32F1 based core: http://ucapps.de/mbhp_core_stm32.html or the more recent STM32F4 based core? Compare: http://ucapps.de/mbhp_core_stm32f4.html I maybe have one of the STM32F1 boards, not stuffed, available. I can only confirm on Friday this week as I'm travelling....

i try now to mod it this way... going directly with analog signals to STM32F4:

How about https://www.midiphy.com/en/shop-details/138/2/wcore-pcb-and-usb-pcb-midibox-diy-do-it-yourself-solder-midi-microcontroller-stm32f4 ?

TK about mixed CLCD/GLCD: maybe it is already implemented, the actual bootloader says: [2781.832] help [2781.832] Welcome to Bootloader 1.018! [2781.832] Following commands are available: [2781.832] set fastboot <1 or 0>: if 1, the initial bootloader wait phase will be skipped (current: 1) [2781.832] set single_usb <1 or 0>: if 1, USB will only be initialized for a single port (current: 1) [2781.832] set spi_midi <1 or 0>: if 1, SPI MIDI interface will be enabled (current: 0) [2781.833] set enforce_usb_device <1 or 0>: if 1, USB device mode will be enforced (current: 0) [2781.833] set device_id <value>: sets MIOS32 Device ID to given value (current: 0 resp. 0x00) [2781.833] set usb_name <name>: sets USB device name (current: 'Proton') [2781.833] set lcd_type <value>: sets LCD type ID (current: 0x00 - CLCD) [2781.833] set lcd_num_x <value>: sets number of LCD devices (X direction, current: 2) [2781.834] set lcd_num_y <value>: sets number of LCD devices (Y direction, current: 1) [2781.835] set lcd_width <value>: sets width of a single LCD (current: 128) [2781.835] set lcd_height <value>: sets height of a single LCD (current: 64) [2781.835] lcd_types: lists all known LCD types [2781.835] testlcdpin: type this command to get further informations about this testmode. [2781.835] store: stores the changed settings in flash (and updates all LCDs) [2781.835] restore: restores previous settings from flash [2781.835] reset: resets the MIDIbox (!) [2781.835] help: this page [2823.093] lcd_types [2823.094] List of known LCD types: [2823.094] 0x00: CLCD [2823.094] 0x01: CLCD_DOG [2823.094] 0x80: GLCD_CUSTOM [2823.094] 0x81: GLCD_KS0108 [2823.094] 0x82: GLCD_KS0108_INVCS [2823.094] 0x83: GLCD_DOG [2823.094] 0x84: GLCD_SSD1306 [2823.094] 0x85: GLCD_SSD1306_ROTATED [2823.095] 0x86: GLCD_SED1520 [2823.095] You can change a LCD type with 'set lcd_type <value>' [2823.095] Please note that newer types could have been integrated after this application has been released! lcd_type will set all Displays to the same Type (i think) i want to mix one 2x40 CLCD with 2 GLCD (SSD1206) on a STM32F4 core where to start? i bet i have to use "GLCD_CUSTOM", and have to write a custom driver - which i actually dont know how to. but maybe someone has already. thx 4 help

Hello, Did you ever manage to resolve your sd card issue? I'm have the exact issue on the same hardware. I tried building the additional cable as well, and even tried removing the pcb and connecting the "simple SD card cable" directly to the STM32F4, and still getting SD card not found issue. MIOS studio connects to the STM32F4 without any problems, but the SD card doesn't seem to work. Anyone have any suggestions? Thanks!

Hi Andy, Thank you very much, for the moment, my aim is to roll my own pcbs, so i can keep things tidy in a quite small enclosure. But first, i'll try to breadboard something in the next few days. (unfortunately a miswiring seems to have killed my STM32F4-DISCO right now) Cheers, Thomas

Hi Thomas Let me know if you want a PCB to drive multiple displays: http://wiki.midibox.org/doku.php?id=display_driver current version at least fixed the mirrored J15 connector. The connector for shift registers is J10B for STM32F4 Cores. Best, Andy

It's available now. Works only with STM32F4 - in the SCS AOUT page, scroll a bit right so that you see the "Cali Offs Disp" items. Display should be set to "Bip." Change "Cali" to -5V, an offset will appear. This one can be increased up to 4095 Following "Cali" points are -4V, -3V, -2V, .. 5V - offsets can be changed between -2048 and 2047 While changing the offsets, use a multimeter to check the result until value is matching. Best Regards, Thorsten.

Great work Thorsten !! Side question, is it possible to hook ESP32 and STM32F4 cores with direct midi/UART connection (high speed without opto like I do between 3 STM core here) And use it as a RTPM wifi bridge ? Best Zam

Here's my complete test configuration, with only the STM32F4 + display + SD card as hardware. RESET_HW EVENT_RECEIVER id= 1 type=SysEx stream="0xf0 0x41 0x10 0x00 0x10 ^ignore ^ignore ^ignore ^ignore ^ignore ^dump ^ignore 0xf7" EVENT_ENC id=1 hw_id=1 lcd_pos=1:1:1 fwd_to_lcd=1 label="FtT1%B" range=0:127 type=SysEx stream="0xf0 0x41 0x10 0x00 0x10 0x12 ^chk_start 0x1f 0x00 0x20 0x55 ^val ^chk_roland 0xf7" syxdump_pos=1:0 EVENT_ENC id=2 hw_id=2 lcd_pos=1:6:1 fwd_to_lcd=1 label="FtT2%B" range=0:127 type=SysEx stream="0xf0 0x41 0x10 0x00 0x10 0x12 ^chk_start 0x1f 0x00 0x20 0x56 ^val ^chk_roland 0xf7" syxdump_pos=1:1 I already figured out that somehow the combination of the encoder event receiving the sysex dumpi (via syxdump_pos), on the one hand, and the sysex the same encoder event is sending, on the other, cause the problem. See the byte highlighted in red above. If the data received and dumped by EVENT_RECEIVER contains that byte (whether it's ^ignored or not), the screen freezes. But if I change the highlighted byte to something else, EVENT_RECEIVER can receive and dump 0x12 as the 6th byte without problems. If I changed the highlighted byte to 0x11, for example, now the EVENT_RECEIVER receiving and dumping 0x11 will freeze the screen. (And of course, removing the stream element from the EVENT_ENC completely has the same effect.)

Hey all! A little late to the party, but I'm considering upgrading my stm32F4 Seq 4 to a 4+. I've found what I think is the new hardware config for the frontpannel on this repo https://github.com/midibox/mios32/tree/master/apps/sequencers/midibox_seq_v4/hwcfg Probably a dumb question, but Is there anywhere that just has documentation for the new frontpannel? Like a manual, or something similar? I think I understand how all the labeled functions work, just not 100% sure about the new contextual GP buttons and encoder switches. The whole new thing is really cool! I appreciate all the work yall put into it. thanks, -hal

So its not the wiper, but that is indeed a clever possibility! And exactly why I love this forum. You guys always have ideas I'd never think of. Unfortunately, I've got 3 seperate control banks (8 pots each), and they each work fine on the other two MUXes and also exhibit the same weird behavior on the first MUX. Good thinking on the tutorial Antichambre - had forgotten all about the initial AINSER testing I had to do. Ended up just loading the MB128 Controller because it was handy and already has debug messages. Works fine... Each pot has its own pin and its own unique value. Albeit this is all when plugged into J19. My Goom implementation has AINSER running on J8/9 and its associated SPI. Goom uses the onboard DAC of the STM32F4 which uses the same SPI as J19. So I'm thinking the problem must lie in modifications I've made to the AINSER software module... Not sure off the top of my head, what could be causing this rather unique issue, but I'm going to start over again with the original AINSER code and slowly remodify it again. What's strange is that I could swear I had it all working. Then this problem popped up after setting it all aside to work on other projects. Of course that also means there are some major lapses in my memory, so who knows what I did to the code... Again, many thanks for the help - always good to have a few fresh eyes and brains to help regain perspective on this stuff. You all rock! Will report back shortly!

I've been implementing analog controls in the GOOM distribution for STM32F4, and thought I had conquered all of my issues with AINSER with much help from the forums. Got all my controls on panels now and wired everything up and have a whole new problem. Only one control on the first MUX chip works. I'm only using 3 chips and the other two work perfectly. I am almost positive that I tested the first MUX chip, but perhaps not... It's acting like the MUX isn't getting the ABC bits to advance through each channel, it just stays on the first channel and AINSER assigns that pot's value to all of the pins on that chip. But ABC on MUX 1 are receiving the same pattern as MUX 2 and 3. Tried swapping MUX chips around with no change. Same with ribbon cables. Really seems like it's a hardware issue, but I can't for the life of me find it. I'm out of time for the day, but plan to rebuild it on the breadboard and see if the problem persists. Could this be caused by software? I can't see anywhere in AINSER that would cause this kind of an issue. To be clear, there are 8 knobs (parameters 0-7). Only one knob generates values and it assigns that value to all parameters (0-7). I built my module with a bit of a weird pin mapping, so the working knob is number 6, but this is the one connected to X0 on the MUX. Which really makes it seem like the MUX just isn't advancing. I can change pin mapping and it still only reads that one knob, thought it does change the order in which it assigns pin values (matching the pin mapping). Any thoughts as to where to look for further testing? Thanks! Jeff

One alternative, Will the mackie control, logic control be ported to use on the stm32f4? My daw supports this so I could go that way instead if needed.

Winter time is DIY time - and this year I decided to explore the capabilities of the ESP32 platform. There might be synergies with MIOS32, but I'm very sure that I won't fully integrate this Microcontroller into the MIOS32 ecosystem --- this hasn't been considered 10 years ago when I started with the 32bit platform, and it would take too much time to make everything compatible (with many compromises - e.g. no native USB support, and we know that this is important for best performance!) However, I think that ESP32 is a pretty good companion device to a STM32F4, hence potential candidate for future MIDIbox enhancements. E.g. the NodeMCU ESP32 available at Reichelt for 10 EUR supports Dual-Core (!) @240 MHz with WiFi and Bluetooth, 512k RAM, 4MB external Flash, incl. USB programmer on PCB - compare this with a PIC18F*! ;-) I started with Bluetooth, and the result can be found here: https://github.com/midibox/esp32-idf-blemidi This so called "BLE MIDI" service should work with any OS which supports this protocol. So far only tested on MacOS and iOS... but it should also work with Linux and Win10. This will be the basis for further experiments at my side - I'm able to communicate with the device via MIOS Studio. :-) (however, application download has to be done with the ESP32 ecosystem - means: the appr. esptool.py based bootloader) In future also a WiFi connections as demonstrated in Pedalino might be possible, but I'm not there yet - focus is on the application itself, knowing that the MIDI interface options won't be so fast like known from the STM32F4 based platform. E.g. how accurate can we control a Motorfader with the PWM LED outputs of a ESP32? If it works, it could be connected like a MBHP_MF_NG module via traditional UART based MIDI to a MIDIbox NG. And will it be possible to control a SRIO chain? Might be interesting for a future BLM16x16+X with (only) optional WiFi and Bluetooth connects. Best Regards, Thorsten.

My ssd displays turned up today. Looks like I got messed with. These are not the ssd1306 glcds I needed. These have only 4 pins on, I'm guessing they are not compatible with the stm32f4. Anyone know if these will work or if I need to try and get the 16 pin parallel ssd displays?