MIDIbox-Link: tunnled events

[TK.]

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. I already have integrated the basics into the MB16E and MBMF firmware :)

Best Regards, Thorsten.

[TK.]

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. I already have integrated the basics into the MB16E and MBMF firmware :)

Best Regards, Thorsten.

[d2k]

My gosh...!!

What a week for MBHP and Logic...;)

And it's only wednesday!!

Thorsten: I'm gonna update that diagram i posted b4 once again with this new way of chaining added and the midimon 8 digit LED option for the MTC display (i know your planning another update for the midimon, but i'm guessin thats a firmware thing rather than hardware...right ???). If you could have a gander to see if everything checks out - it'd b appreciated....

Got most me parts in now! Should be doin the pcbs next week...

It begins.!!!

Peace...

Dan

[d2k]

My gosh...!!

What a week for MBHP and Logic...;)

And it's only wednesday!!

Thorsten: I'm gonna update that diagram i posted b4 once again with this new way of chaining added and the midimon 8 digit LED option for the MTC display (i know your planning another update for the midimon, but i'm guessin thats a firmware thing rather than hardware...right ???). If you could have a gander to see if everything checks out - it'd b appreciated....

Got most me parts in now! Should be doin the pcbs next week...

It begins.!!!

Peace...

Dan

[TK.]

Hi Dan,

yes, no hardware update is necessary for the MIDImon. :)

Best Regards, Thorsten.

[TK.]

Hi Dan,

yes, no hardware update is necessary for the MIDImon. :)

Best Regards, Thorsten.