Re: That MIDI stuff again

[Xav <MBGE4MDC@fs1.ee.man.ac.uk>]

Bluffers guide to MIDI, Pt II


I've been thinking about this MIDI based networking a bit. It'd be 
damned impressive if it ever gets going - not only could we network, 
but a "normal" MIDI system could work at the same time (ish).

Anyway, thinking about the topologies involved, I figure we would 
need a couple of things to happen:-

1)  Each node (computer) passes data from its IN, to its OUT - unless 
it is network traffic which originated on that node.

2)  Each node should also optionally filter non-network traffic (i.e. 
normal MIDI). This would stop notes circulating forever, but would 
ideally be selectable in real time, rather than at boot up or compile 
time! Only one node _needs_ to be set up like this, but on a large 
system, setting more than one to do this would effectively allow 
independent MIDI music systems on different parts of the ring.

This only strictly applies if things need to be recorded. For a 
playback only system, a spur topology overcome the problem.

4)  Ideally it should be possible to prioritise between music data 
and network data. For example, if there is a musician at work, music 
packets should be passed through as fast as possible on his machine 
(and any others between that and the sound source). On the other 
machines on the loop, however, network data takes priority, since the 
music will only get filtered out at some point anyway.

I don't know how this would be done - I'm not much of a programmer. 
Perhaps different queues for network and non-network stuff? The 
software THRU would send packets to the relevent queue, and depending 
on priorities, one queue is always serviced first. There should also 
be a non-priority mode where things get send according to how long 
they've been waiting, etc.

Ideally the choice of priority would be set on the fly.


Anyway, onto something I _do_ know about: The MIDI codes themselves:-

Sysex takes the following form:


F0, MFR_ID, DEVICE_ID, ... DATA ... , F7

The data is 8 bits, but with the MSBit as 0 (7 usable bits). F0 is 
the sysex header, F7 is eox (end of sysex). MFR_ID is the 
manufacturers ID, which in our case would be (usually) the universal 
test ID. It would be very nice to have the choice of ID as a user 
option, though, in case anyone complains. It's 8 bits, MSBit = 0. 
I'll dig out the number of the test ID and post it when I can be 
bothered (I think it's E7). Device ID, in our case, would be the IP 
address.

Finally, most other MIDI messages are of fixed lengths. Our software 
THRU should just look for F0, ID ..... F7 - anything else should be 
considered non-network stuff. This includes anything starting F0, 
SOME_OTHER_ID - so that normal sysex could still be used.

Anything I've missed???

Cheers,

Xav




--
Xav
E-mail: mbge4mdc@fs1.ee.man.ac.uk                                      
Web: http://cerebus.lamp.ac.uk/~xav/xav.html
"It's who I am, it's what I do - I can't change" - Sledge Hammer