MIDIbox KB

[2wice]

I would strongly recommend you to try it out with one or three 78-TCUT1350X01 (double sensors) before buying the complete set for your piano. I can help you with the software extension (because it's easy to test at my side, and could also be useful for other projects)

 

Best Regards, Thorsten.

 

Thank you Thorsten, I'll give this a try.

[FantomXR]

Thank you very much duggle! I'm happy now :)

[kmuldrew]

I am trying to get a midibox kb board running for the first time and everything seemed to be going well until I tried typing a command to the MIOS terminal. After loading MIOS32 and then midibox_kb, in response to the Query button I get:

 

Operating System: MIOS32

Board: MBHP_CORE_LPC17

Core Family: LPC17xx

Chip ID: 0x26113f37

Serial: #C1...[lots of numbers and letters]

Flash Memory Size: 524288 bytes

RAM Size: 65536 bytes

MIOS32 Bootloader

© 2012 T. Klose

 

If I try entering the command 'help', I get

 

[1614116:921] help

[1614116:924] [MIOS32_MIDI_SYSEX_Cmd_Debug] command handler not implemented by application

 

I am running MIOS Studio on an older macbook pro running OS X 10.7.5.

 

Am I missing something simple here? Thanks for any help.

 

Ken Muldrew.

[Duggle]

Yes, there is an additional step. You need to upload the midibox application itself, in this case midibox KB. When you've done this it will no longer say "MIOS32 bootloader" in the message but the name of the application.

[kmuldrew]

Thanks for the quick response Duggle. I am uploading a file called "project.hex" that comes from the "midibox_kb_v1_012" zip file. I thought that was the application, but after uploading it, I still get the "MIOS32 bootloader" message. I just tried unzipping it again and reloading the file, but with the same result. I wonder what I am doing wrong.

 

Ken Muldrew.

[TK.]

Could it be, that the BSL Hold Jumper (J27) is stuffed? Please remove it, because it prevents that the application will be started.

 

Best Regards, Thorsten.

[kmuldrew]

Yes, that was it. Thank you Thorsten, all is well now.

 

Ken Muldrew.

[kmuldrew]

I connected a Fatar TP 20/21 keyboard to my midibox kb, using the wiring diagram shown here  midibox_kb_fatar_df_88_interconnections.pdf to connect the keybed to an MBHP_DIO_MATRIX board and then on to the midibox. I used the settings for a Fatar DF type with 88 keys and then started pressing some keys. Almost all of the midi messages shown in MIOS Studio are note off (with the occasional note on with velocity=127) and give the wrong note. For example, pressing C1 gives "Chn #1  note off  D-2  (optimized)". Pressing C1 again does nothing, but pressing C#1 gives "Chn #1  note off  C#-2 (optimized)". Then C1 can be pressed and gives the same message as before. The right side of the keyboard does not generate any messages.

 

The most likely culprit would seem to be wiring but I can't find a problem through visual inspection. I have an analog scope and some decent meters. Can anyone suggest a good place to begin troubleshooting?

 

Ken Muldrew.

[TK.]

Hi Ken,

 

first please doublecheck the firmware configuration by entering "kb 1" into the MIOS Terminal.

 

These are the most important settings for your keyboard:

set kb 1 note_offset 21
set kb 1 rows 12
set kb 1 velocity on

If this doesn't already help, you could check if all DOUT outputs are toggling frequently.

For this test, disable the scan optimisation with:

set kb 1 optimized off

(you can enable it later once the scan is working)

 

Next check would be to compare the DOUT pulses with the incoming DIN pulses when a key is pressed (requires the usage of two scope channels)

You should especially see a pulse at the Break *and* Make line if the corresponding key is fully pressed.

And you should only see the pulse at the Break line if the corresponding key is not fully pressed.

 

Best Regards, Thorsten.

[kmuldrew]

Hi Thorsten,

The 3 settings that you mentioned are set properly. When I turn off optimization I am able to get more reproducible results (hitting the same key gives the same midi code, and I can hit the same key more than once and get a midi code). Now I only get "note off" messages when the keys are released. There are no "note on" messages and nothing happens until a key is released.

 

It looks like I have my wiring mixed up somehow. I am now getting note off a-1 (90 15 00) when I press key E-2 (but only when the key is released, nothing happens when the key is fully pressed (as an aside, isn't midi status byte "90" note on for channel 1?)). From there, descending chromatically I get the sequence leading up to E-2 when I press a-1 (i.e. pressing D#-2 gives "90 16 00", pressing D-2 gives "90 17 00", and so on until I press a-1 and get "90 34 00".

 

I have a schematic for the keyboard and the two connectors for the left and right sides are labelled identically to those shown on the Fatar DF 88 diagram on the midibox site, so the wiring should be straightforward. I think I am going to have to trace some wires from the keys back to the DIO_MATRIX board to figure out where I have gone wrong.

[kmuldrew]

Well, this is pretty embarrassing. I switched the ends of the ribbon cable from the micromatch connectors that GEM uses to dual inline connectors (because you can buy them locally) but I didn't notice that the rows are opposite (e.g. the far left wire comes out in the front of the micromatch but in the back with the inline connectors). Somehow I also put a twist in the ribbons going from my wire-rearranging board to the DIO_MATRIX board (a momentary act of desparation, no doubt, that was quickly forgotten once data started appearing on my screen). The end result was note off commands with a reversed keyboard. Having re-done the wire-rearranging board, I now have the proper note-on messages (with correct velocity) followed by the correct note-off messages for all 88 keys.

 

This is very exciting, so far. What I don't have yet, is communications coming out of the midi ports of the midibox-kb. The command "set kb 1 midi_ports 0x0011" is accepted but nothing comes out of midi out 1. Similarly, the command "set kb 1 midi_ports 0x0021" should put data out of midi out 2 but nothing is there. Does anyone have any ideas for this problem?

 

Ken Muldrew.

[TK.]

Thanks for the input! I added a note to the schematic, that the pinning is not 1:1 compatible.

 

MIDI OUTs: very strange!

 

Following configuration allows you to doublecheck, if the MIDI OUT port is working regardless of the keyboard configuration:

just enter following command into the MIOS terminal:

set router 1 USB1 all OUT1 all

thereafter play some notes on the virtual keyboard of MIOS Studio.

They should be forwarded to the OUT1 port.

 

If not, you know that the problem is related to the hardware.

Check the MIDI circuitry on the MBHP_CORE_LPC17 module, and also check your MIDI cable (maybe it's defective?)

 

Best Regards, Thorsten.

[kmuldrew]

It turns out that the midi out was working, it just won't work with the Roland XV-2020. I can use the keyboard within MIOS studio to output midi to a usb-midi cord attached to a PC, and then play that midi back to the XV-2020, but the output from the midibox just isn't recognized by the XV-2020. My Yamaha NP-31 will also recognize midi from the midibox so it must be something peculiar to the Roland synth. I wonder if anyone else has tried sending midi from a midibox to Roland gear and with what result?

 

Ken Muldrew.

[Duggle]

Did you set the midi receive channel on the XV-2020?

[kmuldrew]

Yes, all of the devices are sending and receiving on channel 1.

 

Ken Muldrew.

[kmuldrew]

Just to follow-up with this peculiar problem, I put the midi out from the midibox kb through a 6N138 optocoupler and on into an Arduino that was programmed to just forward midi bytes (the whole program is just reading a byte when it's there and then writing it back out). That output successfully triggers the Roland XV2020 to play. Not a very elegant solution, but it works.

 

As an aside, when I first built the midi repeater, I used a 4N25 optocoupler (because it was handy and I couldn't find a 6N138 in my parts drawer). With this setup, I could not get midi into the arduino from the midibox but I could get it from a Yamaha NP31. Once I found a 6N138 and put it into the circuit, then I could receive midi signals from the midibox. Perhaps Roland did the same thing with the XV2020.

 

Ken Muldrew.

[ilmenator]

Yes, Roland might have saved a few cents on this...

[kmuldrew]

The arduino isn't actually necessary for this kludge; just connecting midi in line to midi out and bypassing the arduino entirely is sufficient to trigger the Roland XV2020. Maybe it just needs the midi signal to come off of a 5V rail instead of 3.3V. I wonder if someone who is more familiar with the midibox than I am can comment on the advisability of simply lifting the back of R22 from the midibox board and connecting it to 5V (maybe from J2). Would that have any adverse consequences?

[TK.]

I wonder if someone who is more familiar with the midibox than I am can comment on the advisability of simply lifting the back of R22 from the midibox board and connecting it to 5V (maybe from J2). Would that have any adverse consequences?

 

Unfortunately this isn't possible with the LPC1769 due to a hardware bug in the chip.

 

As you can read at the MBHP_CORE_LPC17 page: -> http://www.ucapps.de/mbhp_core_lpc17.html

• output pins can't be used in open drain mode if a peripheral function like SPI or UART is assigned to it. This seems to be a design bug, because it isn't mentioned in the user manual (in distance: the description of the IO configuration implies that it should work, but it doesn't) - NXP support contacted, no reply yet!

 

The consequence is, that the MIDI OUT pin can only switch between 0V and 3.3V, because works in push-pull mode.

 

A workaround would be to level-shift the output to 5V, e.g. with a 74HCT541.

This chip is already used for level-shifting, see also http://www.ucapps.de/mbhp/mbhp_core_lpc17.pdf

You would need another one for the MIDI OUT port.

 

Best Regards, Thorsten.

[PhilipC]

Hi everyone,
I wanted to ask if there are any plans to bring the Midibox KB application to STM32F4, since I have a spare board and I would like to do something with it...

Thanks,
Philip

[TK.]

The only missing piece is an EEPROM emulation for STM32F4.

I will implement this sooner or later, but it won't be available in the next 2..3 weeks.

 

If it's ok for you to start with a MBKB which can't store the parameters, I could give you a preliminary version.

 

Best Regards, Thorsten.

[PhilipC]

Thanks a lot!
That's interesting... I'm in the process of starting a  project, and gathering some details. In case I'll start with the STM32F4 I'd be very glad if you could share the preliminary version.

By the way, may I also ask what's the scan rate Midibox KB achieves?

I'll let you know,
Philip

Edited January 27, 2014 by PhilipC

[TK.]

Ok, then this preliminary version should be sufficient for the first tests: http://www.ucapps.de/mios32/midibox_kb_v1_013_pre1.zip

 

 

By the way, may I also ask what's the scan rate Midibox KB achieves?

 

It depends on the number of scanned rows; with the "optimized" flag enabled, ca. 130 uS for a typical keyboard

 

Best Regards, Thorsten.

[Acul]

Hello

Use MB-NG

The midibox kb is a Part of MBNG

[FantomXR]

nIs there any sense in transmitting the midi signal in a OSC bundle via ethernet to my mac? I read through the OSC-page of ucapps and it says, that OSC is faster then MIDI... but to do this, first a MIDI signal has to be created to be packed into a OSC bundle. Is that correct?
If yes, there is no advantage in speed, right?