Hawkeye

Hey Lars, Thx! Yes, it should be down-scalable with some adjustment of the panel configuration files... Currently, it is "just" a base MBNG, the only thing that was added is a bitmap loader for the OLED label screens... But planning to do graphical envelope rendering on the bottom screens sooner or later, with some additional code... Many greets, Peter

Thx, guys! :-) Latigid On: Yes, your BLM would look soo nice next to it! FantomXR: Yes, an external PSU is necessary, plus a 3V3 Regulator, as the STM32F4 has a too weak onboard regulator, that will get overloaded after about 8 displays or so... Apart from that, I ran into stability problems after about 16 displays... some of the displays on the lower line would "glitch out". With 24 displays installed, the effect was permanent and occured right after boot up... well, an old oscilloscope to the rescue, and i saw... nothing on the scope... :-). But the problem was gone... a bit of head scratching and investigation revealed the probe/sensor to have a capacitance of a few Picofarads and a high resistance (a megaohm or so) between GND and the probe tip... More research revealed, that it acted just like an "ac terminator", a concept that has been explained by TK. (see the thread with long DIN/DOUT lines), and has been used by Seppoman and others :-). To cut the talk, a cap of around 20pF in series with a 100R resistor at the end of the data lines (especially SCLK) solved the problem for now. The problem was caused by the long wires acting as RF anteannas and the RF signal bouncing back from unterminated data line ends wreaked havoc on the poor SSD microcontrollers :-) J: really looking forward to the visit! The project is far from finished :-). After reading a bit into the FS1r documentation today (multiple different SysEx streams to be created/decoded, checksums to be calculated), methinks we should start with the Waldorf Q panel... much easier only with CCs and we want to chill and enjoy a few beers and not work that hard after all! :-) Many greets, Peter

Some time later, after a few more hours of wiring ;-) ... all 24 OLEDs up and running. Now waiting for jojjelito to review this unit in person :-) Maybe we will make some progress on a more advanced synth panel than the current Moog Slim/Little Phatty panel. But after reviewing the MIDI implementation of the K5000/FS1r (both are on the agenda sooner or later in this decade), i am getting cold feet in the middle of summer ;-). Hehe, many greets and have a great time, Peter

Hmm... it is a quite uncommon thing... maybe something wrong on the core board? I'd suspect maybe some misplaced component somewhere or an unwanted solder bridge, that drops USB voltage, so the flash fails... but... fishing in the dark ;-). Can you measure USB voltage and 3V3 voltage with a voltmeter? Maybe someone else has a better idea! :-) Many greets and good luck! Peter

Thanks a lot, TK.! :smile:

Hola, Some time ago, I managed to sync the SEQ to an old version of Cubase (V2) on the Atari ST :-). Methinks in the BPM menu, you can configure the SEQ to listen to external MIDI clock events, also the "Start/Play" command should be honored, so the SEQ is in sync with your DAW. You could then change patterns, mute/unmute tracks and stay in sync... it is good enough for a live performance... It is also possible to work the other way around, to sync the DAW to the SEQ, which i liked a bit more. MIDI timecode syncing is not supported yet, afaik. What is really interesting is, how flaky the MIDI timing is on modern machines in comparsion to a "hardware" implementation on the Atari ST without USB-bus, multitasking events and all those interrupts... On Cubase 7 on a 3GHz - Windows 7 PC, my SEQ BPM jumps around 119.2 - 120.8, when syncing the SEQ to the Windows PC. When syncing to that 30-year old Atari ST, it stays around 119.8 - 120.2... :-) Many greets, Peter

Thanks, man! :-)

Thanks, j! :-) See you laters in good old Bavaria, you need to do some coptering, too! :-) Many greets, Peter

Thanks! :-) It's the prop downwash :-) Six motors (about 1800 watts together) with 14 inch props create enough wind to dust off all your synths in a few seconds :-) Have a great weekend! Many greets, Peter

It looks awesome! And sorry for not jumping on the list. I'd really like one, but still have no studio space! :-) The colors appear different probably due to cam shutter effects in conjunction with pulsed/matrix driven LEDs. The middle section (darker) may have been in a different duty cycle than the others :-) I have the same problem when filming the Programma and a few synths ;-). If taking still photos, it helps to use a long exposure time (a second or two) and to use a small aperture/low iso setting. Many greets! Peter

Hola, it has been a while, but now: Full throttle! Made with a MBSEQ and a MB6582, a few other synths and a gimbal-stabilized-cam DIY hexacopter ;-) Thanks for listening and watching and have a great time! Peter

Oh yes, you are right! :-) Somehow my test line was probably eliminated by the optimizer. Compiling your code, i got the same error. But it is easy to be solved :-) Replace LIBS = with LIBS = -lm in your Makefile and it should work. We need to link with the math library, and all will be fine :-) Have a great evening! Peter

Rowan, thanks for the confirmation, and sorry for being picky today (too hot here :-)), but the SSD above has all 4 lines necessary for 4-wire SPI named (DC, CS, MOSI, CLK) on the PCB. Methinks, it has a proper startup reset mechanism onboard and thus does not need the 7th (Reset) line. The display in the ebay link on the other hand has the "RST" line on one of the six pins and thus might be missing one of the four serial lines. Many greets and have a great evening, Peter

Very interesting - do you have the lastest compiler toolchain in use? I just tried injecting a pow() statement in the source code of "Tutorial 1" and it compiles and links without a problem for either LPC1769 or STM32F4... Omitting the #include <math.h> only produced a warning, but no linker error. But of course, it makes sense to include math.h! :-) Can you update the toolchain? Many greets, Peter

Rowan, have you tried them? Again, these seem to have only 6 pins easily solderable, but we need 7 for the 4-wire serial protocol: http://ucapps.de/mbhp/mbhp_lcd_ssd1306_single_mios32.pdf Here, the CS (display) /D0 (MIDIbox core) line seems missing (they might only support 3-wire spi). Many greets, Peter

You're welcome! Recommendation: read this page: http://ucapps.de/midibox_fm.html Under "Hardware costs" you have links to the necessary modules to build (there are links to the modules and how to build them). You will need to build a MBHP_CORE, a MBHP_OPL3, a DINx4, a DOUTx4 module and need a special bipolar PSU. It is not a super-easy newbie project, but well doable. The modules and their hardware requirements are all explained and linked from the given page. You will have to do some reading on ucapps.de! :-) If you want to continue with the 32bit platform, contact Sauraen (forum message) and ask him what you need. In any case, I don't think it makes sense to continue with your microcontroller, unless it is packed on a LPC1769 or STM32F4 devboard - these are natively supported. Many greets, Peter

Welcome! :) MIDIbox is married to two microcontroller controller categories - 8bit PIC controllers, and 32bit ARM controllers, forget Arduino! :) You'll find everything documented on TK.s site: http://www.ucapps.de Fortunately, all of those platforms are not really expensive. There have been porting efforts to different platforms, but it is usually not worth the effort, when you can assemble a MIDIbox core for ~ 30-40 Euros. The original MIDIbox FM runs on the old 8-bit PIC platform, but there has been a user project porting it to the new 32bit systems, search for MIDIbox FM or MIDIbox FM 2.0. Many greets and enjoy! :-) Peter

Well, this works only, if all pins and connection points (more data lines are necessary) are available in "wide" pitch on the breakout PCB. Soldering to that multipin plastic flat display wire is next to impossible.. i tried to fix a broken SSD1306 a time ago, no go for mere mortals. If you have Jeri Ellsworth powers, on the other hand, forget what I just said! ;-)

Hm, lemme say the calculation seems at least a bit dubious :-) (notecount-69) / 12 this is a note offset, divided by 12 (octave), which kind of shifts the input note around the origin (69), than scales it by octaves. Good thinking, so far... But it performs on an s32, which is a signed 32 bit integer. The C compiler will not use floating point math here (source variable datatype defines the division method), so it is very lossy after the division by 12. Then, the "^" operator - the original author probably wanted a "2 to the power of x" operation, but in C, the "^" operator is executed as a bitwise XOR calculation. So, this seems very strange. Why not try it with this line: midi[notecount] = tuning * pow(2, (float)(notecount - 69)/12); Many greets, Peter

Nice find! But it seems, it might only offer an I2C interface, not 4-wire SPI, which is necessary for the current MIDIbox SSD1306 driver :-). I did not research thorougly... maybe it is possible to attach it nevertheless, but the schem on the website says there are only VDD, GND, SCL and SDA pins, which is I2C... Many greets, Peter

Hi TK., thanks a lot! It was only possible because of the awesome MIDIbox framework, but it also still needs some work done (e.g. to send "midi note-offs", when a clip is muted during playback :smile:), but it is very enjoyable work! :smile: Currently, the loopa probably also does not exactly behave like you would expect it to work :smile:. Each track/clip is currently recorded independently from the lengths of the others and has no pre-configured clip or loop-length, once recording is started. So you can record a minutes-long live-jam to a clip, just as the guitarist does in the above video and not lose it in time :smile: (which might happen, if there was a pre-configured loop-recording length, the jam duration is not known beforehand). Once a clip is recorded, it has a defined length and will then loop around it. One important item on the to-do-list is the option to loop around a per-clip-configurabe loop start and endpoint (counted in MBSEQ-compatible steps). The advantage is, that you can "post process" your recording, e.g. if you needed a few times to play a passage correctly without errors, you just leave the recorder on, and once you managed to play it correctly, you stop recording and just "cut out" the take you liked best and loop around that section. I know, this workflow is a bit different to a classic audio looper... but it is quite straightforward for me - just record, until you like a segment, then afterwards adjust the loop points around it and forget the rest. Great idea with parallel-wiring the arm/record switch onto a footswitch, this will make recording even easier, thanks for the tip, i will soon have to adapt this! :smile: Many greets for now, enjoy the summer! :smile: Bye, Peter

Fully agreed, J! :smile: Altitude, I've attached the connection diagram for the SSD1322 display :-) To see the correct mapping, this link will also help (the wiring is very similar to the ssd1306): http://ucapps.de/mbhp/mbhp_lcd_ssd1306_single_mios32.pdf Here is the connection table in verbal form: SSD1322 256x64px Connection Pins ================================ GND: Pins 1, 5, 6, 10, 11, 12, 13, 14, 19, 20 +3V3: Pin 2 NC: Pins 3, 9, 15, 18 DC (=RS Pin on MIDIbox Core): Pin 4 SCLK (=E Pin on MIDIbox Core): Pin 7 SDA (=RW Pin on MIDIbox Core): Pin 8 Reset (Active low, slow pulled high on powerup with 10uF cap/1K resistor, see schem): Pin 16 CS (=D0 Pin on MIDIbox Core): Pin 17 Regarding the voltage supply: a LF33 or any other low-drop 3 or 3.3V vreg is nice (no switcher recommended, the OLED is very sensitive regarding stable voltage, but the standard-size linear vregs will do without additional passive cooling) and a 47uF/100nF pair to stabilize pins 1/2 is recommended (not in the diagram, probably not necessary, when the vreg and the vreg output cap is nearby). The STM32F4 Core should be jumpered to 3.3V (display lines), but the display seems to be able to tolerate 5V on the datalines (made a mistake first, but nuthin' burned ;-)). It probably does not withstand 5V on pins 1/2, so be careful :-). I'd recommend to build a test wiring first before finalizing the PCB, i can send you the .hex to get some output, if needed :-) Many greets and have a great weekend, Peter --- EDIT: Phatine: yes, recording is in real-time, but it displays steps for orientation, just as the MBSEQ does. It would be no problem to play in any other timesignatures, as it is realtime, it plays back whatever you recorded. Currently, the clip length is forced to be a multiple of 16 steps (16th notes), to allow for nice looping with other clips, but this is easily configurable to any other value and might be a UI setting later on (and the beat leds can be rewritten for 3-parts based counting, if you like, it is just some simple c-modulo logic :smile:).