MIDIbox Link

Created in December 2002

I finally found a simple and effective method against the feedback loop issue which appears when multiple MIDIboxes are chained and are running with an enabled MIDI merger. First idea was to create a special hardware interface (a physical "MIDIbox Link") which acts as a second MIDI connection between the MIDIboxes. But this hardware extension could be unstable against outside influences (EMC) and could lead to crashes at every little noise on the wires between the core modules. Only solution against this problem are additional hardware components, slower transfers and an error correction.

However, today I tried out something different. I used the common MIDI chain and inserted "Begin" and "End" bytes in order to mark events which should leave the MIDI chain, and events which should be filtered out by the last node of the chain. In other words: all MIDI events which are generated by the core modules itself, will be tunnled to the "exit".

Thats all - and it's working fine without any additional hardware.

Here some pictures which make it more clear:

Picture one shows the potential feedback problem when all mergers are enabled. This is sometimes necessary if (for example) 3 modules with motorfaders are connected together and the host software has to send the motorposition to all cores, and the MIDI events which are generated by the MIDIboxes have to be forwarded to the host. If the host software cannot filter out the selfmade events, it will forward them again and again until it gives up (and mostly until windows crashes :-/)

The solution: every event which should be forwarded to the host software will be framed with a start and stop byte. The frame will be notified by the last core with disabled MIDI merger. Only the framed events will be forwarded by the last core (-> tunnled), all others will be filtered out.

Here the MIDI wiring - note that there is only one path from core1 to core3 *through* the cores.

And now the best: on this way, not only common MIDI events, but also other informations can be transmitted without reaching the host software at the end of the chain - for example LCD characters (only one LCD at core 3 for all core modules) or bankchange triggers. A nice new feature which can be realized very easily. :-)

PIC16F: MIDIbox Link has been integrated into following firmwares: MIDIbox64, MIDIbox16e, MIDIbox MF.

PIC18F (MIOS): MIDIbox Link is part of the operating system. See also the functional description of MIOS_MIDI_MergerSet.

It can be enabled in the MIDI config menu, with the Editor GUI or with the mk_syx script. All boxes before the last box have to be configured as "MIDIbox Link Forwarding Point", and the last box as "MIDIbox Link Endpoint".

If a big MIDI system with a complete menu navigation for multiple cores should be realized, the use of MIOS is highly recommended, since this operating system is much more flexible compared to the old PIC16F firmwares. Here a possible solution:

The first core provides the menu navigation interface. It sends control messages to the last core which handles with the output elements like LCD, LEDs, LED digits. Other core modules between the first and the last one can insert additional output messages into the MIDI stream if necessary.
Optionally, the first core could convert incoming MIDI events to control messages and send them to the other cores in order to access the soft-overtake function of pots, to move motorfaders, to change the patterns of LED rings directly. It could also send messages which assign MIDI events to pots/faders/encoders. In this manner, several setups (banks...) can be managed by a single core to reduce the programming effort.

Copyright © 1998-2023, Thorsten Klose. All rights reserved.