Search the Community

Hi all, i would like to know more about OLED displays and how to connect and use them. It looks like you can connect say 8 OLEDs via J15A on CORE_STM32F4. I assume these wirings are ok for STM32F4. http://www.ucapps.de/mbhp/mbhp_lcd_ssd1306_single_mios32.pdf http://www.ucapps.de/mbhp/mbhp_lcd_ssd1306_multiple_mios32.pdf Every OLED gets it's own CS-Line (CS0-CS7 on J15A) and all other pins are connected in parallel. What does the X = 0..127 or X = 128..255 values mean? Edit: here it is better pictured, should work http://wiki.midibox.org/doku.php?id=oled

Hi! First, let me introduce myself. I'm Thomas, sound engineer, I'm working mostly in audio post but have a small home studio where i record small bands. It's been a long time since i started thinking about making a midibox NG, but other projects kept me busy (I built a few preamps for my home studio as well as other audio gears) But now, i finally have time and hopefully make it a reality. I will try to keep this thread updated with my progress and experiments. So first, i'll expose what i'm aiming for: My goal is to build myself a Midi controller that is basically a Mackie Control with a few more features to control Nuendo. I really want it to be as ergonomic as possible, and today, no controller on the market would fit my needs completely. (maybe Nuage systems, but that's a bit expensive) Midi-wise, i will use 3 ports as Mackie Control and one as a Generic midi. (feature that you can set as you wish in Nuendo) I want: -25 faders: 24 using MAckie Control and MC expanders + one using Generic Midi to control selected channel in DAW -Each fader will have 4 buttons, an encoder with led ring and an oled display on top (just as any MCU) -transport buttons -various array of buttons with MC features as well as window management, automation features, some edit functions... -a Jog wheel -a surround panner -one bank of encoders to control selected channel EQ -another bank of encoders to control Selected channel Dynamics -Control-room commands. I think that's it for wanted features. Now for things i will need: As i understand i'll need: -2 STM32F4 Core module (1 main and 1 for MF_NG modules) -4 MF_NG modules -a bunch of DIO matrices for buttons and LEDs. -and probably an AINSER8 module. I already own a STM32F4disco and i made my own version of the core module. I went through the tutorials, and i've been playing a bit with a beaboarded Din / Dout. Joined is a block diagram of the way i think My different modules will fit together. Hopefully i got this right... I still have alot to do / learn, but feeling really excited about it right now! And i'd like to thank Thorsten and everybody involved in the midibox project for all they have accomplished. This is great! Cheers, Thomas Block diagram.pdf

I had been getting the following error from the terminal when trying to access the sdcard on my STM32F4 core: [[35355.231] SD Card Informations [35355.231] ==================== [35355.231] ERROR: Reading CID failed with status -256! [35355.231] ERROR: Reading CSD failed with status -256! [35355.231] [35355.231] Reading Root Directory [35355.231] ====================== [35355.231] SD Card: not connected [35355.232] Failed to open root directory - error status: 12 [35355.232] [35355.232] Checking SD Card at application layer [35355.232] ===================================== [35355.232] Current session: /SESSIONS/DEF_V4L [35355.232] File /SESSIONS/DEF_V4L/MBSEQ_B1.V4: doesn't exist [35355.232] File /SESSIONS/DEF_V4L/MBSEQ_B2.V4: doesn't exist [35355.232] File /SESSIONS/DEF_V4L/MBSEQ_B3.V4: doesn't exist [35355.232] File /SESSIONS/DEF_V4L/MBSEQ_B4.V4: doesn't exist [35355.232] File /SESSIONS/DEF_V4L/MBSEQ_M.V4: doesn't exist [35355.232] File /SESSIONS/DEF_V4L/MBSEQ_S.V4: doesn't exist [35355.232] File /SESSIONS/DEF_V4L/MBSEQ_G.V4: doesn't exist [35355.233] File /SESSIONS/DEF_V4L/MBSEQ_BM.V4: doesn't exist [35355.233] File /SESSIONS/DEF_V4L/MBSEQ_C.V4: doesn't exist [35355.233] File /MBSEQ_C.V4: doesn't exist [35355.233] File /MBSEQ_BM.V4: doesn't exist [35355.233] File /MBSEQ_HW.V4L: doesn't exist or hasn't been re-loaded [35355.233] done. I checked around on the forum and had seen a lot of people having issues with wiring , the card slots and the format on the cards. Mine turned out to be bridged pins under the LQFP100 on the STM32F4 board. Here are the relevant pins if you are having issues as well: LQFP100 P1 PA5 30 15 PA6 31 18 PA7 32 17 PB2 37 24 Here is J16 looking down on it _________ | VS --- VS | -------> to ground | VD --- VD | -------> 3.3V (the STM32 actually only puts out about 3 volts) SI SO | SI ----> PA6 SO ---> PA7 | SC --- SC | --------> PA5 | RC2 RC1 | RC2 --> PD11 RC1-->PB2 (RC1 goes to the onboard SDCard reader or a card on J16 if there is no card in the reader ---------------- RC2 is for a second Card and not needed for most testing. I figured the board was already messed up so I decided to try fixing it. Those pins are super small and hard to work with. There was a dead short between PA6 and PA7 I was able to lift pin PA6 and cut the trace with a razor blade and solder a jumper directly from the pin to PA6. I would think this error would more likely happen from a solder bridge elsewhere and the STM should pass QC. The pins are pretty easy to test as they go straight to the ARM Processor. The also nicely went in order down the side. PA5 was pin 5 on that side of the chip. The white silkscreen on the board makes it a lot easier to keep track of the pins they are marked every 5 pins. The jumper might look a like it is crossing things in the photo but the pin is bent up and out so there is plenty of clearance. I tried solder wik, reflowing the pins, my hot air rework iron, cleaning between the shorted pins with a razor blade, and even removed the header pins hoping the short was there before lifting the pin but nothing else worked for me.

Hi all, Thank you for all your advice and input... this was one of those times where doing the same thing multiple times yielded different results , and I still don't really know why, but I will explain the steps I took below just for anyone else's future reference...( Its worth noting that I had a couple of days when the forum was down, so I was kind of scrambling around outside of the steps recommended here ) I got to thinking maybe my USB drivers were causing the connection issues between my midibox and the MIOS Studio ...so I downloaded and attepmted to install the drivers (however I note that they say they are NOT related to the F4 board that I seem to have... and they didnt seem to like to install on my Windows 10 PC ( install ended in an error) BUT I do wonder if this action may have caused the native drivers to refresh somehow... as the next time that I plugged in I did it in this exact order 1. laptop on 2. hold down blue bootloader button on the board ( I had to physically continue to hold this blue button throughout ALL steps below...maybe get someone else to do this ) 3. insert USB form Midibox to laptop (get the ding dong noise on the laptop) 4. select MIOS32 Bootloader on MIDI in and MIDI out dropdowns within Mios Studio 5. This finally showed up the bootloaders details vrsion, board etc in theLEFT hand box below the input dropdown.. 6. clicked on browse and located the unzipped midibox_seq_v4_096. folder and found the stm32f4 sub folder inside it...and the project.hex file inside THAT 7. clicked start and let it upload ( this took a bit of time and to be honest I get it a bit longer at the end just cos I was worried about unplugging early 8. I then released the blue button, unplugged the usb to my midi box and closed mios studio 9. plugged the Midibox back into the USB 10. restarted Mios studio ( squeal with delight that the default hardware config file is now showing and I am finally passed the bootloader screen ) at this point I was back to the Midibox starting up but pressing my onmidi box save button was still coming up with the SD card Error... 11. I then typed 'help' into the terminal on MIOS STUDIO to get a list of command, I spotted that you can create a new session with the words new 'namehere' 12. I then created a brang new Session via the MIOS terminal ..this took quite an unexpected long while....all the time I had two progress bars on the screen of my midi box, it may have taken around five minutes to complete...I just let it run 13. I powered off the midibox once completed and changed to powering it via the wall plug rather than my laptop and lo my new session (named "apple") was now the active session upon startup and it SOULD be read to / saved to etc. after that it was just a matter of putting all the midi channels , ports, bookmarks etc back to how I like them and saving as I go ... and since then I have taken the unit out and performed last night and it was back to working perfectly ( except the screens turn off when bumped..but I am sure thats a physical issue with a cable somewhere that Ican fix) thank you all for all your support and help , I know I am thick as two short planks when it comes to diagnosis and repair , but you where all very helpful. Phill

I never said it shouldn’t be a hardware link. Maybe the right term is „debug Interface“, … …but I don’t have STM32F4 in use for my mbseq.

In the beginning of this year I decided I was going to finally build The Sequencer. I built my first MIDIbox project 4 years ago, a stereo MB SID, and have been hooked since. Next to my kids, this is the greatest thing in my life, I love it. There's so many great tutorials and tips on the forum about building the SEQ V4, so there's not really a need for another one, but I thought I'd share a few things I did in my build. I used the STM32F4 based Core, with the now available PCB. To save some space in the case, I moved and removed some parts. Removed the jack and the button caps. Cut the buttons and some pins. Moved some pins to the underside. I used the Kyocera LCD's, and read a tip by Altitude about the back light. I omitted the transistor and the resistors, put in a bridge and a multiturn trim pot. Like sometimes at Mouser, the part doesn't look like the picture, but it sort of fits ;) I wanted the max MIDI OUT's, so I used 2xMIDI I/O and 2xQuad IIC boards for 12 OUT and 4 IN The PICs on the second Quad IIC board needs a modified firmware. Tim AKA "Not Mike" AKA SmashTV has it now, but if you want to burn it yourself, it's downloadable further down. The rest of the build is pretty standard. Wilba PCB, Schaeffer front panel and common parts. The case is laser cut acrylic done locally. With the mods on the Core, it's only 4 cm. high :smile: While I was at it, I built the BLM 16x4 and TPD as well (FPD file further down) The last piece was the tinted windows on the TPD, and they really look great I think I am very happy with it, and it's so much fun to play. Thank you TK for everything. Thank you Wilba for the PCB ++ Thank you SmashTV for your shop and service ++ Thank you ilmenator for the BLM and TPD, and the "bling" and of course thanks to the rest of you for all the help, support and inspiration. Beers all around edit: I thought I could buy you all beers, but it's only TK that has a working link Wilbas redirects to a Rick Astley video :), and the others don't have one oh well Cheers Hal iic_hack.hex TPD+BLM_19.fpd

Heeft iemand een idee waar je deze in Nederland kan krijgen? Via Distrilec en Mouser betaal je een tientje verzending, en dat vind ik nogal veel voor een onderdeel van 3 euro. Of wellicht heeft iemand er nog eentje liggen die kan overnemen?

Hi Latigid and others, It's really been a long time since anyone mentioned something about MBCV V2, but I'm really curious if there was some progress in your alternative version. Your build looks really good but we never saw the finished project, like with all MBCV V2's........ Last month I powered on my own build and I was again really impressed by all possibilities. It took a while to connect it to my Ipad/lemur but I succeeded and I compiled new MBCV V2 project.h files from the mios32 github for LPC1769 and STM32F4. My own test version is on a LPC1769 but I want to make a new one on a STM32F4 core. But I can't get my ethernet module and SC card to work simultaneously. I red that Rowan and Sneakthief had the same problems , see here When I upload midibox NG to my core the ethernet card and Sd card do work simultaneously. You are also using a STM32F4 for your mbcv v2.01, did you get it to work with ethernet and SD card at the same time? Hope to get some answers after all these years....cheers, Roel

I received my first F4 Discovery board from an Chinese ebay seller along with some excellent value LEDs and an LCD display this week. The F4 was able to be flashed with it's booloader through the ST link as per TK's instructions. It was when I attached the target USB connection that didn't work, that I spent quite a few hours to sort things out. I found: various short circuits under CN5 (the target USB port) USB data line short circuited by a solder bridge. SMD capacitor open circuit (not properly seated) Worst of all(!): CN5 was the wrong kind of connector for this PCB. It was a micro USB receptacle, sure, but one designed for a PCB such that in this case the logo on the cable plug faces down. The result is that all the terminations are made in reversed order(!!!) It took me by surprise after many confused hours. For example why was the Vbus sitting at -0.7V rather than +5V? (Because with power attached backwards the 5V rail was being clamped by the diode action of a nearby logic chip, which was getting warm, btw) Happily, and perhaps miraculously the board is now working (at least the functions that I will be using). I removed the CN5 connector with a hot air gun (after carefully wrapping the PCB in foil to protect the rest of the board from the heat). I soldered 4 wires onto the PCB for the USB connector mounted on the baseboard.

tirol... oberösterreich - ok englisch ist nicht dein ding - guad ich will doch nur die Anschlussblende sehen aka Backpanel diese Rückansicht z.B. ist für ein core stm32F4... und ist offensichtlich für 2x Midi IO Module geschaffen für diese ausführung hätte ich alles daheim, bis auf das zweite MIDI IO...

nope that is a plastic case made by ponoko... so why you dont post the panel - else i am out! why you want to use the midiphy core? use the orginal core? I ask because i have booth at home the lpc17 core (need different packbanel) the stm32F4 core '(need different backpanel)... the orginal stm32F4 core use the same microcontroller on a different developement board - like the waveshare from midiphy... ... i too have the linedriver pcb... i have a whole midibox labor with assembled modules at home - but if you wont show the backpanel - i cant help you anyway...

Hi All, I hope this is considered the correct part of the forum for this. I am a novice midi to MIDI and a general tinkerer. Not much of a musician either.... I saw the Goom Synth build on the STM32F4 and thought it looked like good cheap fun. I have managed to procure the board, install MIOS32 and upload the synth "project.hex" without too much stress. I don't have a good way of playing the synth (no keyboard ATM) so long term I wanted to try using an old Motorola Xoom as a touch interface, similar to "ttfshtt" or "AVLG". Currently I have managed to connect to the tablet using the Cntrlr interface created by "Synthy" (for which I am very grateful) on both Win7 & Ubuntu Studio. All the above was done with two USB cables attached which is a bit of a pain, so I tried the PA9 to 5V trick. Although the board appears to power up, I don't get the pulsing LED LD4, and LD1 (Com) flashes instead of being solid red. By accident I have just discovered that if I plug in CN1 temporarily whilst CN5 and the jumper are in place, I can get the board to boot. Interestingly, it is more complex than just getting power on the CN1. If I plug the board into USB power block whilst connected to my laptop on CN5, it won't boot. I needs a laptop USB to trigger the board (hope that makes sense). Has anyone experienced this and have a cure? it is a pain at the moment, and I would like to try playing with MIDI commander on either my Samsung Galaxy, or Motorola Xoom as a control interface. (currently I have managed to at least see the Goom in MIDI commander with my Galaxy and a USB OTG cable). The board I bought from Farnell is the "STM32F407G-DISC1" which seems to be an updated (but I can't tell how) version of the STM32F407. Any thoughts appreciated.

Hi TK, as stated in another thread, the STM32F4 used on the latest core seems to be an "end of life" product. Is there any replacement you plan? Thanks, Chris

Sehr geehrter Herr Klose, geehrte Damen und Herren, im Zuge einer Midibox-NG- Applikation arbeite ich seit längerem an der Midifizierung einer alten Digitalorgel. 1. Digitalorgel: 2 Manuale (61 Tasten), das Pedal (30 Tasten) und Koppelschalter liefern seitens der Orgel -12V bei gedrückter Taste. Die Taster sind im geöffneten Zustand über 2 k Widerstände seitens der Orgel geerdet. 25 Registerschalter liefern 5 V Schaltspannung, im Ruhezustand beträgt diese Spannung -5 V. Das Pedal hat Reed- Kontakte. Damit die Orgel jederzeit wie zuvor gespielt werden kann, habe ich die DIN- Module mittels einer Pegelwandlung über Optokoppler angehängt, was den Vorteil hat, dass sich keine direkte Spannungskopplung ergibt. 2. Computer: Der Orgelcomputer ist ein Windows8.1- PC, verfügt über 12 GB Ram und 2 x 4- Kern Prozessoren (Intel Server- Board). Als Orgel- Software setze ich GRANORGUE (GO) ein. Als USB- Treiber verwende ich den GM5- Treiber. Die Midibox-NG-Applikation ist über eine 10m lange aktibe USB20- Verlängerung angeschlossen. Als Testcomputer verwende ich daneben einen PC mit Windows- XP SP2 (2GB Ram, Dual Core) und ebenfalls den GM5 Treiber. 3. Midibox-NG- Applikation (Basisboard plus STM 32F4- Kontroller): Daten laut MIOS Studio: OS: MIOS32 BOARD: MBHP_CORE_STM32F4 App.: Midibox NG V1.032 Flash-Mem.: 1048576 Bytes Ram: 196608 Bytes LCD-Type: 0x83 - GLCD_DOG 8x1 bzw. 128x64 Es ist eine SD-Card über einen micro- SD- Adapter angeschlossen Es werden folgende Anschlüsse des Basisboards verwendet: 3.1. DIN / OUT: DIN 1: 24 Taster im Controller (kurze interne Verbindungsleitung) 1 Encoder Wheel DIN 2: Pedal (ca. 50 cm Verbindungsleitung vom DIN1) DIN 3, 5, 6, 7: Manuale, Koppler (jeweils ca 10 cm zwischen den DIN- Modulen) DIN 4: Registerschalter DOUT1 24 LED im Controller (als Rückmeldung / Statusanzeige der DIN1- Taster) 3.2. Analogeingänge: 3 x Potentiometer (interne Verbindung) LED- Panel (interne Verbindung) USB- Device (Die Spannungsversorgung erfolgt über den USB- Bus) 4. Meine Bitte: Bitte gewähren Sie mir die dringend benötigte Hilfe und Unterstützung bei der Beseitigung des nachfolgend beschriebenen Problems, das ich bisher nicht zu lösen vermag. Was für mögliche Ursachen Fehlerquellen erkennen Sie, was kann ich bzw. sollte ich ändern, überprüfen um den Fehler zu beseitigen. - Störimpulse auf den Leitungen zwischen DIN und Manualen ? - Störimpulse auf der Versorgungsspannung der NG- Applikation (USB- Versorgungsspannung) ? - Verwendung von mehr als 4 DIN- Modulen; erforderliche Maßnahmen ? Hinweis: Die NG verwendet für den DIN- OUT Anschluß einen 74 HCT 541 Treiber. Ist hier ein insbesondere der 100 Ohm Widerstand zwischen den RC1 bzw. RC2 Clock- ausgängen und der DIN- Chain erforderlich ? - Software- Entprellung; prellen die Manualkontakte stärker als vorgesehen, ist die Entprellogik zu langsam, zu kurzes Zeitfenster ? - Abschaltung aller nicht benötigten Funktionen, um Rechenzeit zu sparen ? - Generelle Präventionsmaßnahme: Kann man zB durch Konfiguration die NG dazu bringen ein NoteOff grundsätzlich zweimal senden, und / oder nach jedem erkannten NoteOn individuell für den zugehörigen Eingang mehrmals in kurzen Abständen zu testen ob das Signal aus ist und dann ein NoteOff zu senden ? - Kommt auf dem USB ein Übertragungsprotokoll mit ausreichender Fehlersicherung zum Einsatz ? Nebenbei bemerkt: Der Hänger beim Up- oder Download, wie er im Forum bereits beschrieben wurde, tritt auch bei mir sporadisch auf. 5. Mein Problem, meine Analyse- und Abhilfeversuche: Beim ersten Spielen der Virtuellen Pfeiffenorgel (VPO) blieb in grösseren aber auch kleineren Abständen 1 Ton im Pedal angeschaltet, das NoteOff- Signal bzw. das Loslassen der Taste wurde wohl verschluckt. Das hatte ich in den Tests zuvor nicht bemerkt. Die Midibox- NG- Applikation war über ein USB- Kabel mit ca. 1,5 m Länge angeschlossen und über USB mit Spannung versorgt. Nun dachte ich das könnte insbesondere an dem relativ langen Flachbandkabel nach unten liegen und änderte die Zuordnung so, dass oben die Anschaltung direkt am ersten DIN- Modul (DIN2) liegt (ca. 1,5m Flachbandkabel). Wegen Umpositionierung der Lautsprecheranordnung wurde die Midibox- NG- Applikation über eine aktive USB- Verlängerung von 10m angeschlossen. Beim weiteren Spielen der VPO ergab sich der Fehler nicht mehr im Pedal, sondern im oberen Manual. Es werden bei wiederholten Versuchen die Töne von bis zu 3 verschiedenen Tasten, die alle am selben Schieberegister des DIN5 / demselben Optokoppler hängen, nicht abgeschaltet, aber in jedem Fall nur ein Ton gleichzeitig. Ich kann leider nicht sagen, ob es sich vor und nach der Änderung der Zuordnung um dasselbe Schieberegister handelt, oder denselben Optokoppler- Chip. Die Verwendung eines USB- Adapters mit zwei Steckern zwischen PC und aktiver Verlängerung (falls die NG- App zuwenig Strom bekam) nützte nichts. Bei genaueren Analysen stellte ich nebenbei fest, dass die Registerschalter im Ein- Zustand zum Flackern der Stop- Buttons der VPO führten, Es stellte sich heraus dass die Optokoppler bei 5V nicht stabil schalteten, was ich durch Erhöhung des Schaltstromes erfolgreich beseitigte. 5.2. Detailtests der DIN- Module und der DIN- Funktion Nun untersuchte ich alle Lötsellen des den Problemtasten aktuell zugeordneten DIN5 und des dazugehörenden Optokopplermodules mit der Lupe und reinigte die Platine in verdächtigen Bereichen. Danach machte ich Spannungs- und Widerstandsmessungen, die waren in Ordnung. Test mit speziellem Taster, der 8 Eingange gleichzeitig einschaltet: Nun führte ich die nachfolgend beschriebenen Tests mit dem Testcomputer durch, mit kurzem USB- Kabel, an die NG- App ware neben dem internen DIN1 nur das verdächtige DIN angeschlossen. Ich verwendete zum Test einen Taster, der beim Druck jeweils 8 Eingänge aktiviert, zuerst vor dem Optokoppler, danach direkt am DIN- Modul. Jeweils nach einigen Tastendrücken in unterschiedlich schneller Folge, hörte ich, dass von Grand Orgue nicht alle 8 Töne gespielt wurden. Das war für alle 4 Stecker des DIN- Moduls entsprechend. Analyse der ankommenden Midi- Befehle Nun analysierte ich die am GM- Treiber ankommenden Midi- Signale zunächst mit dem Tool "Midiox", weil man damit einen guten farblich differenzierten Überblick hat. Es ergab sich folgendes: Fall 1: Die meisten Tastenimpulse (Drücken und loselassen) liefern 8x NoteOn und 8x NoteOff. Fall 2: Ab und zu liefert der Tastenimpuls neben den 8x NoteOn 2x hintereinander 8x NoteOff Fall 3: Ab und zu liefert der Tastenimpuls zuerst nur für einige der 8 Eingänge NoteOn, (zwischen 1 und 4 Eingänge), der Rest NoteOff. Nach ca. 10 ms (Midiox- Timestamp) kommt dann 8x NoteOn. Danach 8x NoteOff. Fall 3.2: Ab und zu jedoch werden beim Tastenimpuls im Vergleich zu Fall 3 die fehlenden NoteON- Kommandos verschluckt, es folgt nur 8x NoteOff. Fall 4: Sehr selten liefert der Tastenimpuls auch 8xNoteOn 2 mal hintereinander und danach 8x NoteOff. Nun reduzierte ich in der Definitionsdatei die Zahl der Schieberegister auf 4, worauf die Häufigkeit der Fälle (2-4) abnahm, insbesondere der Fall 3.2 ! Bei drei weiteren Testsequenzen analysierte ich direkt die von MIOS- Studio protokollierten Signale, mit demselben Ergebnis. Das festgestellte „Übersehen" von NoteOn- Kommandos kann in meiner Anwendung toleriert werden, jedoch wäre es wichtig, die Ursache dafür zu kennen. Auch ein selten übersehenes NoteOff muß jedoch unter allen Umständen vermieden werden. Ich konnte in meinen Tests nicht feststellen, dass / ob die NG erforderliche NoteOff Kommandos im Zuge des Loslassens einer Taste nicht sendet. Für Ihre Unterstützung und Mitwirkung vielen Dank im Vorraus. K. F. Mayer dintest-seq2_conf f 8 DIN.doc dintest-seq1_conf f 4 DIN.doc

I'm using my seq V4 (with PIC core) live from quite some time. I think it's time for a core update, and I want some advice for choosing the core. As title says, based on your experience with the cores, what core should I choose ? Thank you for your help.

Hi, just wondering if the I2S DAC module still useful with the new core32 STM32F4?

Another question about the MBHP NG platform: How to connect the Motorfader NG to new core32 without using MIDI (STM32F4)? Wich best way and protocol to use? (as well as MIDI I/OS on new core are already quite "pin-loaded") thanks in advance, Jerome

is there any Driver-code out there - in the MidiboxWorld - to use the onboard Audio DAC for CV? (0-127) i just need it for Velocity Control for the Accent of a TR606 which need a Voltage from ~4V to 15V (a little scale with an OP amp should do the trick hardwareside - i think) In the past i have done Accent with a Shiftregister, 8 Varistors and a Transistor... worked well, but steppy. thx phat

Hi Community, First, the midibox seq was my first DIY project, i'd like to thanks all of you, super project that gave me the fever of building hardware: an addiction is born :-) I read you a lot, and all is thanks to you. I was sequencing using a korg EMX (bad...!!), what a progress with this super Midibox Seq ! Almost all working good : STM32F4, 2x Midi I/O Module & Wilba Frontpanel. I want to add a Quad IIC module but here start the problem.. The IIC ports are not detected (Mios "System" and IICX * in the sequencer). It doesn't seam to be a connection problem (plug on J4A) : - 5V between Vd and Vs of the Quad IIC module - continuity between pin 7 of each PIC16F88 of the Quad IIC module and PB11 of the core (SD) - continuity between pin 10 of each PIC16F88 of the Quad IIC module and PB10 of the core (SC) I verified all solders on each module (Quad & Core), all seam good. The components are the rights ones too. I use the last version of the soft (V4.090), all Midi I/O ports working, no bugs detected. I don't understand why it doesn't work .. remain IIC ports not detected, and no LED working neither. Someone maybe have had the same problem ? Or can tell me what kind of test I can do to find the error ? Big thanks (and big respect) again for Midibox. Kind and warm regards Fanch

So I noticed that despite the STM32F4 having 192k of RAM, I could only have application code (plus MIOS32 of course) allocate up to about 128k. I found this by increasing the heap size until the app wouldn't link, and then checked the size of the larger arrays used in MIOS32 and my application. Since my application uses dynamic memory allocation, having the heap be as big as possible is critical. I found that the stack position is defined in STM32F407VG.ld, explicitly as _estack = 0x20020000, with a comment saying this is the end of the 128k RAM on the AHB bus. What does this mean? Why can't we use the remaining 64k of RAM? I tried changing this to 0x20030000, and (predictably) the application refused to start. So how would it be possible to get access to the remaining RAM? Edit: I found the other 64k of RAM, evidently it's in a separate section at 0x10000000, and I think it can't be accessed by DMA (which significantly limits its usefulness for many applications). I thought switching from LPC17 to STM32F4 would get rid of the memory segmentation issues, but I guess not. In any case, how do I get static/global variables allocated in that segment?

I've been browsing for a STM32F4 board and noticed different boards. Are they all be OK for midibox projects? Is there only one board we should use.? here's some examples. STM32F411 STM32F407, STM32F417 Looks like they use different MCU's and have different voltages. One is cheaper than the other.

Hopefully TK can give a diffinitive answer to this question.... If a MIDI IO module is connected to a STM32F4 core via J11E what is the voltage level of the MIDI out signal on the MIDI IO module? The discription of the jumpers on the PCB on the STM32F4 core page indicates that it's 3v. Is this correct or is the MIDI Out signal 5v?

Thanks, Andy! Just to add a few more informations: all existing SEQ v4 are supported, as the BLM protocol is implemented. And here is a bit more tech detail: 289 (17x17) RGB-backlit and light|shielded mechanical keys with custom keycaps for optimal light dispersion. Full-color 128x128 high-end OLED display running at 60Hz for info and graphical sequence/clip previewing. Extra sliders and buttons for parameter entry and additional functions. Two bidirectional MIDI ports and a dedicated button to switch between them. Dedicated navigation joystick for moving selections, scrolling through clips/sequences and more! High-performance STM32F4 MCU using RTOS as a software base for a responsive and fluid user experience. Full midiphy SEQ v4+ and MIDIbox SEQ v4 support - compatible with existing BLM 16x16+X protocol. Enhanced LoopA support: advanced editor with note color mapping and pan/zoom controls (microtiming), 160 scales (with note quantization), reassignable isomorphic keyboard and performance controls. Here's a direct link to the user manual: midiphy MatriX manual v1.01 Also, here's another close-up photo of the MatriX in LoopA mode - in this mode you can use the x and y sliders to scale the visible sequence area and use the joystick to pan around the area: And yes, you can see new keycaps on here - Andy has done absolutely amazing, outstanding work designing these (of course next to the general hardware design). I think his old BLM 16x16+X design now has a worthy successor. Cheers! Best regards and have a good weekend, Peter

My reply to: Does this have slides, like the original design?

Hi, I just finished building a CORE_STM32F4 with a MIDI_IO Module. It's connected with a MB909 MK-IV board but this is another story. I've noticed that 3V output, VDD output are @ 3V... I'd expect 3.3V ... By the way I'm looking into this because I've having trouble with the LCD: it's unstable. The best way to replicate: hold EDIT button, it makes at lot of message on the SPI, after few seconds the DOGM display becomes full white. The core is supplied with a 2A PSU. The sofwatre doesn't crash, can see SPI messages after LCD "crash". Anyway, the question is: 3V core pin, VDD core pin: are they normal @ 3V or they should be @ 3.3V (at least VDD @3.3V) ? This document is confusing me: http://ucapps.de/mbhp_lcd.html this PDF: mbhp_lcd_dogm128_mios32.pdf it talks about the 3.3V but it's unclear where I can get it on the STM32. Thanks