Search the Community

Happy New Year to you all... I see you are now confirming build numbers to finishers - out of curiosity, do you know what mine was (completed beginning May 2019)? I was also just doing a new year firmware update on all my hardware - I'm running 097 on the V4+, but the download page stops at 096 (for STM32F4). Am I up-to-date? Cheers, Simon

The LPC17 is not bad and should work for the purpose, but it's outdated and the direct successor is the STM32F4. If you haven't bought anything, then go for the 'newer' board. But I don't have an AINSER 64 and can only say what is generally known about the cores. (PCBs can be purchased from 'modular addict').

wiki well lets try... I saw on the LPC17 shematic: That on J5A - A3 a DAC is aviable @ I assume 0-3.3V? for CV I need a level shifter to get 0-5V (Analog) >>> I assume OP-AMP will do the job I will use some pins from the DIO-MATRIX as GATES, so i need no Logical Level-Shift - (0V and 5V) Most of UI and the GATES is done by DIO-Matrix: Features (very minimalistic) a ADR and a midiclock-synced-LFO mixed to one CV-Output, 5 Real Encoders (4 Menue Encoders, 1 Menue-Encoder to cycle thru the Pages) 4 Virtuel Encoders on 4 Menu-Pages (= 16 V-Encoders), 4 LEDs to indicate Menue-pages, 4 Encoders / 2 Displays SHOW ing / DO ing: Page 0: ENVELOPE ENCODER 0.A / 10 Switch = curve type 1.D / 11 Switch = curve type 2.R / 12 Switch = curve type 3.+-/ 13 Switch = long/short time Display 1: Scope: ADR - Curve Display 2: Scope: Mixed real CV ADR+LFO Page 1: LFO ENCODER 0.Rate / 10 Switch = ... 1.Wave / 11 Switch = ... 2.x/4 / 12 Switch = ... 3.+- / 13 Switch = ... Display 1: Scope: LFO - Curve Display 2: Scope: Mixed real CV ADR+LFO PAGE 2 MOTION SEQUENCER ENCODER 0.LENGTH / 10 Switch = Activate Motionsequencer 1. / 11 Switch = 2.x/4 / 12 Switch = 3.BPM / 13 Switch = Activate internal MidiClock Display 1: MSQ-Length-Progress Bar + Length in Steps Display 2: Tact System BPM and MasterLoop Progress-Bar Page 3: DISK ENCODER 0.Load Preset Nr / 10 Switch = DO 1.Save Preset Nr / 11 Switch = DO 2.Letter / 12 Switch = Small-Big-Letter 3.Cursor-Position/ 13 Switch = clear Name Display 1: Preset NR Display 2: Preset Name Page 4: SYSTEM ENCODER 0.set MidiCH / 10 Switch = single Channel/all Channels 1.set CV-Trigger-Note / 11 Switch = single note/all notes (automatic assigned to Gate 1) 2.set Gate2-Trigger-Note / 12 Switch = single note/all notes 3.set Gate3-Trigger-Note / 13 Switch = single note/all notes Display 1: Midi Monitor - showing Notes-Nr. and MidiChannel Display 2: Midi Monitor - showing Notes-Nr. and MidiChannel Panel-Layout - and in real world: the case is also "very" diy ;) see the thru Welt-point... @ the moment waiting for M1.6 Screws (a wire holds the displays at the moment)... searching for Level-Shifters.... before compiling the first code i have to set my environment variables from STM32F4: PATH="/home/inet-stick/midibox/gcc-arm-none-eabi/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/inet-stick/program:/home/inet-stick/Schreibtisch:/home/inet-stick/Schreibtisch/test:/snap/bin" MIOS32_PATH=~/midibox/mios32 MIOS32_BIN_PATH=$MIOS32_PATH/bin MIOS32_GCC_PREFIX=arm-none-eabi MIOS32_FAMILY=STM32F4xx MIOS32_PROCESSOR=STM32F407VG MIOS32_BOARD=MBHP_CORE_STM32F4 MIOS32_LCD=universal to LPC1769 (linux... sudo nemo.... etc/environment... restart linux... have fun doing coding....) PATH="/home/inet-stick/midibox/gcc-arm-none-eabi/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/inet-stick/program:/home/inet-stick/Schreibtisch:/home/inet-stick/Schreibtisch/test:/snap/bin" MIOS32_PATH=~/midibox/mios32 MIOS32_BIN_PATH=$MIOS32_PATH/bin MIOS32_GCC_PREFIX=arm-none-eabi MIOS32_FAMILY=LPC17xx MIOS32_PROCESSOR=LPC1769 MIOS32_BOARD=MBHP_CORE_LPC17 MIOS32_LCD=universal (the SSD1306 is a "universal") since there was already a mios application in the FLASH, i uplodadet with MiosStudio the actual Bootloader In Mios-Studio - there is the Terminal - where i typed help, and set following: and i noticed that i mounted my G-LCDs 180° wrong... so i choose the ROTATED VARIANT, now its all right... these are all commands: set usb_name CV set lcd_type GLCD_SSD1306_ROTATED set lcd_num_x 2 et lcd_num_y 1 set lcd_width 128 set lcd_height 64 store how ever, num xy and width height will be later overwritten in the app itself....: #define APP_LCD_NUM_Y 1 #define APP_LCD_NUM_X 2 #define APP_LCD_WIDTH 128 #define APP_LCD_HEIGHT 64 #define APP_LCD_LINE_OFFSET 0 #define APP_LCD_COLOUR_DEPTH 1

That's all right - for the software it is a SEQ v4+, if it has a STM32F4 with 1MB of flash memory - it just can't use the extended UI features of the midiphy SEQ v4+, primarily the secondary selection row and the TPD/Activity Matrix - using the Wilba hardware config file should work fine.

Selling due to being too lazy to ever actually do any projects anymore... I have basically all the actual parts needed to build a MIDIbox Quad Genesis - barring all the generic parts like resistors/capacitors/ICs you'd need to add. That is: these boards and associated kits, including MIDI DIN sockets, included resistors, etc. - as originally bought from the MIDIbox Shop - so please see the links below for the full specs of what you'll be getting. 1 x Core STM32F4 kit + board = RRP $34 2 x MIDI I/O module kit + board = RRP $27 x 2 = $54 4 x MIDIbox Genesis Board (for YM2612) = RRP $5 x 4 = $20 1 x front panel PCB - this is a rare one, bought from Sauraen! = RRP $50 -- These are in brand new condition - I'd never even opened the parcels until recently... - and ready to go. Original prices are in the list above. That totals $158 USD, which is about £120 right now, but I'd definitely take £100 all in. I'm open to sensible offers. They need a home that'll use them, not just to lie in my next cupboard! Shipping will be from the UK. If you're in the UK, I'll ship for free. As for elsewhere, I've had a lot of experience of shipping cheaply worldwide lately, so it should be quite cheap, but message me first for a quote to confirm. -- Pictures of the items and original invoices showing the quoted RRPs are on imgur, since I get errors when trying to upload here: https://imgur.com/a/MNv5hE0 For more detail, I have uploaded front/rear pics of the front panel PCB, as well as front/rear photos of the 3 sets of kits: see them here: https://imgur.com/a/RY1RtLO The board in the photos captioned "OPN2 boards" are still shrink-wrapped, and I didn't disturb them by unwrapping. However, you can see they are more than just the OPN2 boards! We have 4 of the Genesis/OPN2 boards that were sold at the Shop (link), i.e. the green ones other, black PCBs: 2 shown on the top, which based on the IN/OUT connectors are definitely the MIDI PCBs another black PBC in between the above 2 sets, which must be that for the Core CPU kit. As for buying YM2612/YM3438/PSG chips, it looks like there are still plenty for sale on eBay, and probably elsewhere too. I might have some in storage that I could sell, but need to check.

Hi, All pin of the STM32F4 are General purpose I/O(GPIO) but they have limited alternative functions. The pins for this SD Card are used for other ports/peripherals. PC10 is used for the onboard DAC(Disco) PC11 is the LCD Read/Write PD2 is the UART5 RX(MIDI) PC12 is the UART5 TX(MIDI) Etc... So you will have to remap more than this pins, cause the functions you remove has to move on an other pins, to get all MIOS32 ports available and avoid conflict. I strongly suggest to follow the regular pinout and add an external SD Card Socket ...Or you can download the datasheet, open a blank excel sheet and start a long adventure... ;) Note: your CPU must be a STM32F407xx for MIOS32 to work properly. Best regards Bruno

Hi here, I try to modify the pin definition mapping between MIOS and hardware because I use a STM32F4VGT alternative board with a sd card directly implemented and the pins are differents for the midibox standard pins. I need to swap this standart Midibox Ports to this new ones : Midi box | Alternatie board From : To : How can I do that ? Thanks a lot by advance !

This feature was requested from a user who just wanted to forward MIDI messages to the preconfigured MIDI port/channels of the tracks without further processing, and this is how it's working. Your request goes into a different direction, it's more like a multi channel live/recording function - currently we can only record or play live (+ FX) on a single (selected) track. Allowing more channels would lead to higher RAM consumption, but it could be provided as a MIDIbox SEQ V4+ option, only working on a STM32F4. I'm unsure how Mutes should be handled in this case. I would expect that independent Mute control would be preferable, e.g. to mute the sequence played on a track when the instrument should be played live, but this contradicts with your request. On the other hand: if separate mutes for this forwarding function are provided, where/how should they be controlled? Best Regards, Thorsten.

@latigid on some history on this: while previous boards had a pull-up device for this pin, the STM32F4 Discovery Board had a pull-down, therefore I did'n activate an internal pull device to avoid cross-currents. Good that you didn't completely remove the option for an external resistor! :) @Hawkeyegreat demo, I like it! :) With the step sequencer features the LoopA even becomes interesting for me as a guy who unlearned live playing (too much automation - I was better >20 years ago ;-) The graphics are epic! :) Best Regards, Thorsten.

Well, there's nothing in the doc about using ASCII code with MidiBox NG, so i'm not sure you can do that. Unfortunately my STM32F4 board fried last time i plugged it (messy wiring) so i can't try anything right now. Sorry I couldn't help, Thomas

Hi Forum, i have built an old Wilba CS pcb. After finishing i connected it to the wrong port on the stm32f4 core pcb (J4A) instead of J10A. Then, after recognizing my error, the Seq wont start up - showing flickering (very dim) displays. Disconnecting the CS pcb was needed for the Seq app to start. As soon as i reconnected the CS, the app crashed again, with dimly lit flickering displays. I then (one after another) changed !all ICs and, after the error was still there, !all resistor networks. Now the error is still there. It feels like there could be some shortcut somewhere. But i triple triple triple checked everything. That could not be the issue, really. Now i suspect, connecting to the wrong port, i may have fried an IC cap somewhere. But i really want to hear some expert opinion on this, before i begin changing them as well. Hope you can spend a bit of your time and give some thoughts. Below are some pcb pics as well. Thank you very much for looking at it. Best, FFW

Hi...I'm am also in need of the STM32F4 CORE board and am upset modular addict is down. Located in states I am...anyone know where or how to acquire??? Thanx Danka,

Hi Everyone, Could anyone say me what are the things to do to port actually midibox stm32f4 on those board ? Is it only a question of PIN definition ? Do we have to modify cristal frequency ? Is it a long work to do ?

@Phatline now, that's a mystery - we'll find the culprit. As a bit of hopeful relief - during the dev time, i tested the LoopA on around 30 synths over here (MIDI OUT function) -> no problems with any of them. Let's narrow it down - a few ideas, in no particular order, just brainstorming: * do you have a USB power meter available? It shows the voltage of the USB bus and the power consumption of the connected device. You should measure quite close to 5.00V and a consumption of 0.50 amps, if the matias keys are illuminated. If the voltage is significantly lower or the current is higher, then something is wrong. When the case top is off, you could also measure 5V with a multimeter and check if it is significantly below 5V. * could you double check if you used 220R resistors near the OUT1-3 ports? * could you try to swap your USB cable? I've had bad cables causing strange problems, basically as the LoopA draws 500mA, you should also be able to detect this kind of problem with a drop on the 5V rail (first test) * could you remove the LoopA from its metal case and see if the problem persists (a long/uncut pin on the Core PCB could theoretically touch the case bottom and might cause a short?) * is the problem only occuring with any MIDI OUT connected to cc-looper/NordRack III or could you reproduce the problem happening also with other synths? * related: is the problem only occuring when the connected cc-looper/NordRack III devices are powered, or also when they are powered off? Is it also happening when they are powered off and not connected with their power cable to AC mains? * is the problem also occuring, if you power the LoopA via a USB power bank (no connection of the LoopA to AC mains supply)? * is the problem also occuring, if you remove the SD card from the LoopA and it enters testmode? * is the problem also occuring, if you flash the LoopA e.g. with MIDIbox MBNG (STM32F4 variant?) Just saw that Andy was quicker and posted a few other ideas - i think we should be able to figure this out. Many greets and have a good evening! Peter

@tago fully agreed! Looked into it a bit more, I think it is probably a simple linker config setting that is different between Mac/Linux/Windows - e.g. the newest LoopA version accesses a 64KB RAM block of core-coupled memory available on the STM32F4. When building on Linux, the extra RAM usage is put into the "data" segment, which is wrong: arm-none-eabi-size project_build/project.elf text data bss dec hex filename 220080 59040 123592 402712 62518 project_build/project.elf 20000000 D __ram_start 2002c968 B __ram_end This will crash the app, but it can be recovered from bootloader hold. On a Mac build, the extra RAM used properly goes into the bss segment and a ram_start_ccm linker memory region appears that is used: arm-none-eabi-size project_build/project.elf text data bss dec hex filename 220112 1440 181192 402744 62538 project_build/project.elf 10000000 B __ram_start_ccm 1000e100 B __ram_end_ccm 20000000 D __ram_start 2001e868 B __ram_end This then executes fine on the STM32F4 - if anyone (e.g. @TK. ?) knows what's the culprit, please shout - i'd otherwise investigate when there is a bit more time. Many greets, Peter

I was wondering about if/how it is possible to access different .ngc files on an SD card without using the MIOS Studio "detour". My setup consists of the STM32F4 and two external, bidirectionally connected, MIDI hardware elements, one of which is supposed to be used to control the other. The configuration of this setup is obviously defined by NGC/NGR/NGL files. I use a bunch of different ones (can be called from an omni-accessible "main"-screen) for the same setup, but if I want to choose an entirely different configuration setup I would do so by entering "load xy" in the MIOS Studio terminal. I would like to avoid that and set up a kind of "configuration" menu from which I can somehow choose between different .ngc files which I can load to the core the same way I would do by typing in "load xy" in the MIOS terminal. The goal here is to load different control files to control various hardware devices. If anyone has ever done anything like that I would love to hear how you guys accomplished that!

@tago as far as i understood, more RAM was required to drive new WS2812 LEDs, e.g. for LED-ring applications with hundreds of LEDs. As NG already requires some RAM, this then required access to the "high memory" part of the STM32F4 - its main memory is segmented in a 128kb main memory and a 64kb ("high mem") block. I guess your old NG apps that still work well don't have this addition (number of supported LEDs increased). Our toolchains in Linux and Windows seem to have trouble building an app like that - i'd guess it must be something simple like a compiler flag or such. As a solution for you and if your app does not depend on these LEDs, you could look for the git commit raising the number of these LEDs and reverting it back (just for your own app, of course). It would then require less RAM and should work again when built on Windows/Linux. Not guaranteed though, but maybe worth a try :). But this is of course no good solution - so, if someone is able to find out why it won't work under Windows/Linux (e.g. by looking at the differences to the Mac toolchain), this bit of insight would also be highly welcome from my side, as i currently need two machines for building apps that require more than 128kb of RAM :). Many greets, Peter

Hi, i compiled an unaltered NG app and uploaded it to the core ( STM32F4). MIOS Studio told me it was uploaded successfully. During upload i could see 'bootloader mode' on the display. But now the core is unresponsive and MIOS Studio doesn't find it anymore. One red led is blinking the other is permanently on. A green led near the micro USB port is on as well. The Display which is connected to the core shows nothing. How can i check what's wrong? Thank you

Hi Here, I would like to know if it is possible to flash the mios Bootloader and mios applications on other cards than STM32F4-DISCO, for exemple on this boards : https://github.com/mcauser/MCUDEV_DEVEBOX_F407VGT6 I would like to know how it would be difficult to make Mios studio working with newer stm32 board like Teensy 4.0 or Stm32H743 board like https://github.com/mcauser/MCUDEV_DEVEBOX_H7XX_M Thanks for all, Best

@latigid on thanks for the trace picture - and good idea about inspecting the waveshare! Good point to mention the crystal and cap removal and the necessary changes to the top headers there! @Altitude I'd also recommend checking, if the connection from PA11/PA12 to the STM32F4 MCU on the waveshare board itself might be interrupted for some reason, e.g. some dodgy soldering on the daughterboard header top on the PA11/PA12 pins by Waveshare :). To check with a DMM, you could visually trace these two pins back to the STM32F4 and measure directly from the MCU pin to R30/R31 on the LoopA Core, to see if there is connectivity. Just tried this, the traces are nicely visible on the Waveshare PCB and with a loupe/magnifier you can relatively easily see where PA11/12 go to the STM32F4, then you'd just need a fine multimeter probe tip to check where those two USB signal lines are interrupted on their way to R30/R31 on the core. If there is MCU connectivity to R30/R31, a last check would be to test the USB socket itself, i've never had a fault there, but there's always Murphy's Law :). I've also just compared pictures of your soldering with high-res video tutorial images of the board - can't really see a difference - i think it looks all good. Many greets, Peter

>..Before you desoldered the Waveshare daughterboard, i would have guessed the STM32F4 might have been a dud, maybe bad flash memory... But if it starts up and boots the app when powered by mini USB, that's clearly working. And as you said, it must be some connection to the USB port... I thought that too so I swapped the STM chips and it behaved the same way so it wasnt the chip. That was further proven when I took the core off and that worked by iteself. Its something on the mainboard thats hanging it up.. >did you have the onboard Waveshare power switch moved from "USB" to "5V In", when it was installed in the LoopA core? yes. now that the core is off I'll trace back to the USB socket when I get some time. Either its something stupid that I missed (likely) or some weird edge case issue (unlikely)

@Altitude Thanks for the good quality pictures - soldering really is super clean! Will compare your pictures this evening with a working core PCB and report back if i see some differences. Before you desoldered the Waveshare daughterboard, i would have guessed the STM32F4 might have been a dud, maybe bad flash memory... But if it starts up and boots the app when powered by mini USB, that's clearly working. And as you said, it must be some connection to the USB port... Question that was probably asked before: did you have the onboard Waveshare power switch moved from "USB" to "5V In", when it was installed in the LoopA core? That's the only thing that could explain it, i think - if that switch was not moved to 5V, the Waveshare board wouldn't get proper power and would not start up when powered by external LoopA Core USB. Two red small power LEDs should be lit on the Waveshare board when all is well. You made sure of that probably, but to be sure just wanted to mention it anyways :). If it's a hardware defect on the LoopA core or the Waveshare, we're glad to send you replacements of course, but it would be great to trace it and find the problem - thanks again for the tests and your patience! @latigid on: could we try to trace the USB signal pins from the STM32F4 microprocessor right to the USB port on the LoopA core? Which connections would need to be tested? Best regards, Peter

So at one point during my development of an app on NG basis on a STM32F4 core, my SesEx tool stopped working. I used it to send messages to both a Mackie C4 and a Korg M3R, which both responded in the beginning. The confusing thing is, that I can still communicate with both via my .ngc and .ngl scripts. I address them both by their ports (Macke on MIDI port 1 = 1000100000001000; M3R on MIDI port 2 = 0100010000000000) and there it works! Still something must have been misconfigured on the way and I can't imagine what, because I'm still pretty much in the beginning. I also used to get SysEx dumps form the M3R on request, which also stopped working..

Hi Florian, this sounds very good for me and meets exactly my original imagination! It fully fits to my plan and you mentioned one thing that is important: you used the same board STM32F4 for both -- the NG as well as the KB software. Out of the KB threads I assumed for a long time that it can only be realized with the LPC17 board and somehow there were some inconistencies in Thorsten's documentation that confused me. I also had a look on your github page that finally convinced me that I'm on the right track! Now I can sleep much better again and proceed with the mechanical work... Thanks & and best regards to Toulouse (I was there last time 20 years ago for business -- you have nice restaurants over there, for instance the Caves de la Marechale ), Andreas

Hi Famtom, thanks for the feedback! I was not aware of it. I have the STM32F4 Board already in place, so I guess the only chance to change to more than 16 velocity values is to change it somewhere in the NG software. Or is there any physical limitation for the 16 values instead of the 128 that can't be changed in the software? I didn't dig deep into the software yet... Right now I'm taking care about the mechanics, and as soon as this is done I'll take care about the software and electronics. My original goal was just to use what I have in place, and this is the TP/40WOOD and the STM32F407 board. Both I already got years ago, but didn't have the time to build a real master keyboard out of it. And now I have the time to build -- since my retirement approaches... Or do I really need the LPC17 core for the KB instead of the STM32F4? Thanks, Andreas