latigid on

I think you would upload the MSD hex, reset, take the files you need, then connect again to MIOS Studio and upload the SEQ hex. Or am I missing something? SD card access isn't required to upload hex files. Best, Andy

On the MIOS download page there's hex files for a "mass storage device" that you could try. Looks like these are not yet built for STM32F4? What Core are you using?

J10B.D8: serial data (was J28.SDA on a MBHP_CORE_LPC17 module) J10B.D9: serial clock (was J28.SC on a MBHP_CORE_LPC17 module) J10B.D10: SR strobe (was J28.WS on a MBHP_CORE_LPC17 module Well, this is the pinning to use the Disp Driver breakout board (595 chip side/CS lines). But J10B should give 8 CSs I think.

From TK.: "512k should be acceptable. Currently 400k are allocated, but in the past always RAM was the limitation, and not the flash." This is referring to the SEQ app. I imagine that the chips will also move to the VGT6 at some point. I have spares, just PM if you need.

All good! Sorry, been busy! Will answer PMs/orders as soon as I can.

Cool cool, still have to catch up on the doku... I have at least the parts guide for the 'ELO board.

I think with two separate wires it won't hurt, but it won't make a difference either. It's just the nature of how the MIDIbox boards are set up. They share a power rail (+5V) without any filters (excluding a few capacitors on the DAC, but no RF choke etc.) so they already share common-mode noise. Thankfully we're not switching huge amounts of current... Use the thickest gauge wire possible. On a DB-25 connector this means putting many of the thin wires together in parallel for 0V.

MBHP makes no distinction betwen 0V for analogue and digital; the AOUT_NG boards are routed with separate planes that join at one place. The input impedance for analogue is typically 100k or so, thus very little return current. I've had an 8 channel AOUT/DOUT system on a DB-25 cable for several years now with all spare wires and the cable screen tied to 0V, +/-12V power coming in through the same cable.

Those look correct!

Awesome work, looks great!

Yes! It's a SOIC 165 chip on one side and a MSOIC on the other, just like in the BLM16x16+X

Sure, it was designed as a MBCV v2 setup working with the ENC/PAD/SR boards (the DIN6DOUT4 can stack on the rear). Other priorities for the moment, so it's on hold. TK. has even developed a HWCFG for it; it's just been on the backburner for a while...

It's never too early!

Doing a bit of spring cleaning, maybe these might be of interest. Prices in euro plus shipping Pads WS2812 LEDs and Sparkfun silcone buttons/matrix Availability: 10 Price: 8 Encs WS2812 LEDs and illuminated encoders Availability: 10 Price: 10 encoders: 1.5 each ELO WS2812 LEDs, illuminated encoders, optional touch sensors, OLED displays mounted at 45 degrees Availability: 13 Price: 20 (it's a four-layer board...) encoders: 1.5 each 0.96" white OLED: 5 each CS1 button matrix, encoders (some illuminated), LCD/OLED mounting Availability: 8 Price: 12 DIN6DOUT4 SRIO, works well with Pads, Encs and CS1. Level shifter for 16 outputs (e.g. higher-voltage gates etc.) Availability: 9 Price: 6 MiniCore PIC, designed for BLM but could be useful elsewhere Availability: 3 Price: 5 Disp. driver buffers and CS lines for OLED displays (32 per PCB). Works, but J15 connector is mirrored... Availability: 8 Price: 5 or 2 with any other purchase SCS OLED many configurations possible (1-4 OLEDs, encoder and/or buttons) Availability: 7 Price: 6 populated with 4xOLED: 25 (1 available). Looks a bit dusty, but screen protection still on AOUT4 MAX525-based AOUT, four channels Availability: 6 Price: 5 AIN4 protection/scaling circuit interfacing to a 3V MCU, four channels Availability: 8 Price: 5

Nice LEDs! What will their functions be? Done for the next PCB batch

Of course! I have some PCBs arranged like this and displays in white if you need, let me know.

There's a two-pin header, so you can stuff a jumper or else wire some pins to a panel-mounted connector. There are a few resistors on the bottom.

Okay, so the Nixie takes normal 5V logic signals and is powered separately with higher voltage? If it is just a binary coded decimal, MB_NG can do that: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fleddig1.ngc led_matrix_pattern=<pattern-number> LED patterns can be specified if an event should forward its value to a LED_MATRIX element: 1: the first LED pattern specified with LED_MATRIX_PATTERN n=1 commands 2: the second LED pattern specified with LED_MATRIX_PATTERN n=2 commands 3: the third LED pattern specified with LED_MATRIX_PATTERN n=3 commands 4: the fourth LED pattern specified with LED_MATRIX_PATTERN n=4 commands Digit1: outputs the first (rightmost) BCD digit of the value. See also cfg/test/leddig1.ngc Digit2: outputs the second BCD digit of the value: (value / 10) % 10 Digit3: outputs the third BCD digit of the value: (value / 100) % 10 Digit4: outputs the fourth BCD digit of the value: (value / 1000) % 10 Digit5: outputs the fith BCD digit of the value: (value / 10000) % 10 LcDigit: converts the value directly into a BCD digit as used for the Logic Control protocol. See also cfg/test/leddig2.ngc LcAuto: to handle the Logic Control protocol correctly, this pattern type will set the pattern number (1..4) according bit 5..4 of the received MIDI event value. Bit 3..0 will select the pattern position, and the 6th bit will set the "Center LED". See also cfg/test/logictrl.ngc for the usage

Looks ace, thanks for your work Bruno.

What is the pinout of a Nixie tube adaptor? It would depend on the interface: SPI, I2C, parallel etc. as how you might connect everything. I think Nixies use voltage that can kill you, so it's not for the light-hearted.

Perfect, even easier then! Good choice on the buttons. It does take a while to understand the coding, but just go through the many examples. Notice in the "RGB hue sweep" thread, TK. has basically what you need. He uses a map to define the LED colour based on an incoming CC, so change that to notes over the range you require. The velocity should change the dim level, at least this is one way to work with "smart" LEDs.

For common anode, wire the anode to +5V or your supply voltage (possibly through a resistor) and connect your cathodes to DOUT pins. If the light output is different for each die, you may want three resistors on the cathode side instead. E.g. red has a lower Vf, so may end up brighter, often green is too bright etc., so control the current with the resistors. 595s can sink current, meaning they "can provide ground/0V." So the output is "inverted" for common anode parts. This can be specified in MB_NG. When the 595 output is high, the LED is off. When it's low, the LED is on. You shouldn't need any transistors if the current is nominally around 20mA or so. I haven't tried with the dim levels of normal RGB LEDs, but TK. has in your second link above.

Ah the fun of early release designs! That would be something to discuss with Adrian H. I believe that he's working on including a panel to blank out the unused holes. It should be cheaper (from the supplier end) to keep track of just one design, and I think the price will be more than acceptable for end users.

The aim is for spring, I can't promise anything definite though.