Sauraen

This is MIDIbox FM V2.1, the STM32F4 version of the Gen 2 MBFM. Please note that this is not an official successor to MIDIbox FM V1.4, nor is it a project that is intended to be easily replicated by members of the community, at least not in the forseeable future. For the thread on MIDIbox FM V2.0, the same synth before I upgraded the processor from the LPC17, see here (some build information, more pictures, etc.): I have successfully upgraded my MIDIbox FM from the LPC17 core to the STM32F4 core, both hardware and software, and re-christened it MIDIbox FM V2.1. A stable, decently full-featured (but not 100% complete) build is available. I upgraded mainly due to RAM limitations on the LPC17 core, and now the LPC17 core will no longer be supported, in favor of STM32F4. Working features: MIDIbox NG V1 integration; all synth controls are MBNG parameters, so you can lay out and wire your front panel how you want. Menus are fixed, though, and certain controls (e.g. 18 voice-selection buttons with two-color LEDs, 8 softkeys, 4 mode buttons) are basically mandatory. Other things (e.g. controls for operator parameters) may be done how you like (e.g. MBNG banking). Supports 1 or 2 OPL3s (potentially 4, now that we have more RAM, though performance may become an issue). With 2 OPL3s (as I have), there are no noticeable performance problems, even when playing 30+-voice MIDI files into the synth. Edit all 18 (per OPL3) 2-operator voices independently; set up six pairs (per OPL3) of 2-operator voices independently to be 4-operator voices; set up one set of 3 (per OPL3) 2-operator voices to become a 5-voice percussion system. All OPL3 parameters editable and modulatable (even bit flags and separate audio outputs for two halves of a 4-operator voice). Set voices as polyphonic copies (DUPL) that follow parameters, or LINK them so they play together but have semi-independent parameters. Customize transpose, tuning, portamento, EG retrigger, and delay per voice. Arbitrarily assign two LFOs, one ADLDSR EG, velocity, mod wheel, and CC2 values to modulate voice, operator, or modulator parameters, per voice, up to 16 modulation connections per 2-op voice. Set up a custom temperament system (e.g. just intonation) with independent root note selection and frequency controls. One-touch switch to equal temperament and back. Intelligently assign voices to MIDI channels, the synth does the DUPL work (unless you disable it for custom configurations). Save and load named patch files from SD card in intelligent folder hierarchy and human-readable (editable, hackable) format. About 75% of General MIDI Bank 0 patches are complete. Customize synth's response to incoming MIDI messages: Bank MSB/LSB, Program, Pan, Volume, Expression. Enable/disable automatic patch loading on Program receive. MIDI mixer window with real-time-updating separate Volume and Expression controls per channel. Control MIDI input behavior per port. Not done yet: MIDI output port menu and behavior. The rest of the GM patch bank. There are some bugs with saving/loading 4-op voices, plus some untested (probably broken) corner cases for saving/loading complex LINK-DUPL voice arrays. The "wavetable" modulator (step sequence of pre-programmed values). The drum sequencer. AOUT support (beyond what is offered in MBNG). If anyone would like to build one of these, please let me know! I can send you information personally, or if applicable make a wiki page and/or put up the code somewhere.

You did! It works like a charm now. USB cable plugged or unplugged, one or four USB "devices". Thanks so much for the quick fix! Speaking of updated versions of old MIDIboxes, I see someone has been very active on the MIDIbox SID V3 front... :P You're not running JUCE on the core, are you?!

It appears to be a hardware problem, or else some recently-introduced bug in all of MIOS32. I set it to single_usb, no change in behavior. (I've been testing entirely with Linux now, since that's where I have the toolchain set up.) I uploaded the bootloader update app, and noticed that app behaves the same way. If the USB cable is connected, when the synth powers on, it says "Bootloader Updater / © 2014 T.Klose", and sits there forever until I open MIOS Studio, at which point is checks the bootloader and says "Bootloader is up-to-date! :)". I had compiled it myself, so I thought I might have accidentally changed something in the MIOS32 source, so I downloaded the prebuilt MIDIbox NG, and this gives the same behavior. If the synth starts up with the USB cable unplugged, it says "MIDIbox NG V1 / © 2014 T. Klose" and after a second runs the NGC script and shows other text on the screen as it should. But if the USB cable is plugged in, it stays on the splash screen forever until I open MIOS Studio, at which point it continues. There are a number of jumpers on the STMDISCOVERY module itself, was I supposed to change them? It's being powered by an internal PSU so I removed "USB Power", but other than that I didn't change anything. Could there be a problem with the BSL_Hold jumper/button? When does it check to see if that is set?

It's also new to me, since I was using (nearly) the same app with the exact same OS on a different core and it worked fine. Maybe I did mess something up? I had to go through and delete all references to the SCS, since the OPL3 module uses J10A/B for a parallel connection, and I know there was a bunch of stuff in app.c that referenced it, I may have commented out some things I shouldn't have. I'll take a look there as well as try single_usb.

Hi TK, No, I'm using Linux (Ubuntu 14.04 64-bit), and I did not have this problem (with the same OS) when using the LPC17 core. In fact I didn't have that problem in Windows either with the LPC17 core, and I've always had the default four USB ports. Now testing the app with Windows 7 64-bit, it behaves almost the same as in Linux, except that the synth un-hangs itself whenever the USB cable is plugged in again, even without connecting it to MIOS Studio. I will try setting the single_usb option tomorrow and see how it reacts in both OSes. Still, it seems strange that the synth should hang if there's something wrong with the OS enumerating the USB device--it might mean USB does not work, but it shouldn't block on a high-priority thread like that. (MIDI receiving, MBNG event handling, and background tasks [updating the OPL3] get interrupted, but scanning DOUT continues to work, since the LED matrices continue to appear correctly.) Thanks, Sauraen

Hi TK, I have migrated MIDIbox FM V2.0 from the LPC17 core to the STM32F4 core and re-christened it "MIDIbox FM V2.1". Everything went more smoothly than I was expecting, but I've run into one strange problem. FYI, MIDIbox FM V2.x is a copy of MIDIbox NG, with an extra module driver for the OPL3 module, a bunch of custom code for the synth engine, and some additions to mbng_file_c and so forth to support the new configuration options. When I ported it, I used the latest version of MIDIbox NG, and copied my edits into that. Everything else seems to work fine, from OPL3 control to loading patches from the SD card. The problem I have is that when the USB cable is connected to my computer, but MIOS Studio isn't running and connected to the synth, the synth hangs whenever there would be a debug message sent to MIOS Studio. If I open MIOS Studio, the debug message gets through and the synth immediately starts working again. If the USB cable was not connected when the synth powers up, the synth works fine forever. Once the USB cable is connected to the computer, on the next debug message the synth hangs again. If the USB cable is disconnected while the synth is on, it also hangs on the next debug message. It seems like the core is dynamically picking which port to send debug messages to, and defaulting to USB (which is good). But it also seems that, only if it's using USB, it blocks until it receives an acknowledgement of its message. I'm not sure if this acknowledgement comes from the OS or MIOS Studio, but I think it's the latter, because if I have another program open that connects to the synth but not MIOS Studio, the synth still hangs. Do you have any idea what could be going on? I haven't messed with any debug port allocation code from MIDIbox NG, so I would imagine that this problem exists there too--however, it might be hard to test, because I'm not sure if the default MIDIbox NG sends any debug messages unless requested to by MIOS Studio, and because MIDIbox NG controllers are intended to be USB powered, so they would never be running while disconnected from USB! Thanks, Sauraen

Hey, this is DIY, I should be able to use resistor values that are off by 1000% with no problem! :smile: Thanks, it works great now.

I have the same problem, except it's a new STM32F4 core, and all the results from testlcdpin are correct, both by its self-test and by my scope measurement. Tried replacing the shift register with one known good, no change. Backlight and Contrast pots perform correctly. On startup the bootloader test app says "Initializing LCD #1" with no "error" message on the next line, so it seems the core can talk to the LCD just fine. But still the bar on the top line. Anyone have any ideas? Is there something in the bootloader configuration I could be missing? This kind of problem even makes us "experienced" folk feel like n00bs sometimes... One thing to mention is that I've always used 10k resistor packs for R33, the LCD line pullups, instead of the listed 1k, because I would have to order extras of those specifically. This has worked fine for two LPC17 cores, with no LCD problems at all. But could it be that with the STM32F4's lower voltage of 2.95V, that's not quite enough current now? I'll take it apart and solder on some 1.5k resistors in parallel if need be, but I'd rather not have to do that.

The STM32F4 module finally arrived, and within the next couple weeks I will be swapping it in for the LPC17 core and porting the code. The only code that will have to change is the OPL3 driver, but it'll be even faster thanks to TK's J10A/B pinout! Then I can just start allocating more memory for the arrays... *drools* Point is, I should have working code soon, so if anyone wants to build a MIDIbox FM, this will be the way to go!

Using all 36 voices like this pushes the LPC17 a bit, I'm looking forward to upgrading to the STM32F4!

Once I modify the metal covers that were over the switch assemblies, I'm going to put those on, to keep dust and stuff out. I'm not exactly sure where I'll put the core (LPC17 from my MIDIbox FM V2.0 that I'm replacing with the STM32F4 core) or DIN/DOUTs... Eventually there will be more pedals on top, so I'm not going to close it up with a case. However, this won't fit under my current keyboard stand, so I want to build a wooden stand that has these pedals integrated and will hold up the synths above it.

I found two 12-note pedalboards on eBay for $30 and $40 (including shipping!) respectively. After a little drilling and sawing, they're now one: The original contact assembly was actually a 12-bit mechanical memory, with latches that kept the contact for the last-pressed key open, plus one switch for "any key pressed now". Basically a CV+Gate setup! I scrapped all that, but because there was an extra copper contact for each key that was part of the latch mechanism, I was able to add those as "make" contacts to get a velocity-sensitive setup: It will be MIDIfied once my next order from SmashTV comes in! (I'm going to add some other buttons later, so it has to be MBNG instead of MBKB. But latency is less of a problem for pedals anyway.)

Sorry for not seeing this for a month. As far as I can tell from the documentation, there isn't an easy way to do this, since even if you inverted the signal from the "break" contacts, they would be wired on alternating rows of the matrix. (Maybe a feature request would be in order?) I don't think MBNG would help you, the keyboard driver is the same as in MBKB. If you got one of those monster 8PDT switches (number of poles dependent on number of rows to switch), you might be able to switch the row select wires in such a way that would put all the break contacts next to each other in the matrix. But then you'd also have to switch the configuration when you did that.

Does anyone know what SD Card socket works with the board? I've looked on Mouser and they all seem to be SMT...

Started working with it yesterday, and I have to say already: it's so strange working with a library that not only compiles out-of-the-box, without me having to fight with ./configure and manually install other things first (and that on an old version of Linux), but compiles without a single compiler warning! Looking forward to working with it. Edit: It's working very well, but it's forcing me to really get up to speed on my C++... Working in pure C in MIOS32 spoiled me!

I have some ideas for a real-time MIDI processing engine that I'd like to start working on. It will require too much CPU and RAM to implement in MIOS32, and I want to have data displayed on a screen, so I'm planning to run an old laptop with Linux (a distro with the real-time-audio kernel version), use a MIDIbox NG for the controls and MIDI to other devices, and finally have a high-speed connection (OSC?) from the laptop to my desktop running virtual instruments. So I'm looking for a library that can do MIDI I/O in realtime (~1ms latency) over USB and Ethernet, multithreaded support so I can have analysis running in the background with some thread-safety system for data, and an easy-to-program GUI system. I see Juce has been used for MIDIbox-related projects in the past, can anyone recommend it? Or another library?

And what velocity would the synth "fire" that note with? ;) If you're happy with it always being 127, you can hook up the keyboard as a single-contact, non-velocity-sensitive keyboard by just using the first switch and ignoring the second. There may be a way to do this in software as well, I'm not familiar with the MIDIbox KB configuration options. But I've never before heard of someone wanting to turn off velocity sensitivity just to save 2 ms. Are you sure you'll never want to play sounds with a velocity layer?

Hi Philip, It depends on whether you want to have two cores or one. The best approach as FantomXR said would be to have one core running MIDIbox KB just scanning the keyboards (true 128 velocities, ~5kHz) and another running MIDIbox NG doing all the other controls. You could have the MIDIbox KB core connected to the MIDIbox NG core via MIDI and set up all the handling in your MIDIbox NG config file. STM32F4 should be pretty well supported by now--it's the new big thing--and it has very nice performance. However, if you don't want to have two cores, you can have one MIDIbox NG core, but the keyboard action will be lower resolution. In either case, definitely doable with MIDIbox; MIDIbox NG plays nicely with DAWs and its behavior is very well customizable. Of course none of this will produce sounds, just MIDI data, so you need some VSTi to run in your DAW to emulate the tonewheels.

I apologize for not being more active here, I've been busy (and I'm currently studying abroad in France, so I don't have my equipment). Depending on my workload in the fall, I am seriously considering upgrading the CPU in my MIDIbox FM V2.0 to the STM32F4 module. This will make things so much easier, as I was really running out of RAM in developing the synth engine while keeping all MIDIbox NG functionality. The only code I will have to rewrite is the low-level stuff from the OPL3 driver, but even that should be pretty simple. After this change, it is very possible that it will support up to four OPL3s! (no code changes, just #define OPL3_COUNT 4)

I figured this was appropos... Enjoy!

Here's a new (classic) demosong, showing off patch loading/saving, optional automatic CC control, the mixer menu, and a few of my patches:

Just a quick progress update. The main thing I've been working on, while implementing smaller features and fixing bugs, is creating a full 2-op General MIDI patch bank, all 128 standard instrument sounds each only using one 2-op voice (currently about half done, I'm doing the most-used patches first, and some of them are surprisingly realistic). This is stored in Bank MSB 0 LSB 0, but you can move them in bulk to a different bank if you want just by changing the folder name on the uSD card (in a computer). I've also implemented [optional] autoload mode (when the patch changes, the new one is loaded from the uSD card), and you can [individuall] set whether the synth will ignore BMSB, BLSB, Program, Volume, Pan, and Other messages. It's playing MIDI files very well and with increasing ease of configuration. The very next thing to do is full CC control--which CCs change which parameters will be in your mios32_config.h file, so if you don't like the defaults for some reason you can change them easily and recompile. (There is still the Vari modulator of course which can be assigned to a CC within your MBNG configuration file.) These CCs will allow you to edit/modulate all the parameters of a standard voice (including all OPL3 parameters), but they will not work with LINKed (multi-voice) sounds--there's just too many parameters and CCs don't support an easy way of accessing all of them. I could make some RPN/NRPN scheme, but it would still be a pain to program changes into your DAW. Once I finish that, the only other major additions are the wavetable and the sequencer, both of which have some skeleton support already in place. Others may be able to build faster than me, but it took me about two months to make the hardware you see above; so I would say that if there is anyone who is interested in a MIDIbox FM V2.0, that they could start building it anytime now. I can provide you with my code when you get to that point. It will also be useful for debugging and testing, both hardware and software, to have more than one in existence--and it will force me to document any unclear features. What you need: Fully-stuffed LPC17 core with uSD card One or two OPL3 modules--if you use two, connect all the corresponding pins on the two boards except the OPL3's #CS pin, and there's a couple modifications to the resistor values on the output stage, plus you have to make a small mixer board with a couple op-amps on veroboard, but trust me, 36 voices is worth it! +/-12V power supply () If you want to do a front panel, the front panel is a modified (more features) version of MIDIbox NG. You can build whatever layout you want and wire it in accordance with the MBNG spec, and you will be able to map it properly in your config file to the MBFMV2 commands. It should have the 18 voice buttons with 2 color lights each, 4 mode buttons with light, 8 softkeys without light, menu, select; datawheel; DUPL, LINK, 4-op (each with lights); a value display; some way to switch which OPL3 (doesn't have to be a toggle switch, it can be two lighted buttons or one toggle button); basically it should look like mine, except you can use bank switching to reduce it to 2 or only 1 row of operator controls, and you can use banking to put some of the software modulator controls (on the right) on the same controls.