I just found a post at the Yahoo Giga forum which pointed out a new product from a Russian company which has been doing midi plugins for Sonar and Cubase. They\'re called MusicLab and they\'re home page is here: http://www.musiclab.com/
They have a programme called the MIDI Replicator Driver.
Sounds like they started out designing it to get around the Windows \'Sorry that midi device is in use\' problem by applying a multiclient approach to windows midi devices, but then they expanded it to include sending midi over TCP/IP networks.
The programme appears to allow up to 8 midi ports to operate over your network simultaneously.
Thats 8x16 = 128 midi channels
I know there have been a few \'midi over net\' type programmes, but they\'ve been limited in features.
I\'m also wondering what the jitter would be on a network based midi transmission setup. Would it be worse than sending things across two good hardware midi interfaces, like my Unitor IIs?
Is there a problem with time stamping midi packets over a network??
Any chance of Tascam R&D taking a look at how effective this programme is compared to using a couple of good quality hardware midi interfaces? There\'s no point in using it if it makes latency sloppy.
If it works well, it could be an inexpensive solution.
I\'ve seen a lot of people complain about the cost of adding GSIF audio cards and Multiport hardware midi interfaces in order to run Giga on a separate PC.
I\'m very interested in MIDI over IP. Thank you for posting this. This is perfect for those who use separate Giga and sequencing computers. One Ethernet connection vs. 8 MIDI connections, heck anything more than one! I\'ll need more polyphony on my Giga system. Does anyone know when GST 320 will be developed? :\\? AND it\'s only $29!!
[This message has been edited by pantonality (edited 03-28-2002).]
Here is MIDI flow when you link two computers using MIDI interfaces on Windows 9x (95/98/ME):
A[32-bit sequencer]->B[16-bit part of sequencer engine]->C[16-bit WinMM]->D[16-bit MIDI Driver]->E[MIDI Card out]->F[Midi cable]->G[MIDI Card in]->H[16-bit MIDI driver]->I[16-bit WinMM]->J[receiving app callback]
The main delays are on G->H stage (deliverind events from MIDI card to driver). The overall latency may be in order of 2-5 msecs.
When you are using MIDI Replicator via net interfaces, steps D-H are replaced by
D1[16-bit Replicator Driver]->E1[LAN Interface]->F1[LAN cable]->G1[LAN Interface]->H1[16-bit Replicator]
(To minimize LAN transmit time, we chose UDP datagrams for packet transmission)
In contrast with MIDI Cable, LAN interface can add some delays if there are another communications on the same segment of LAN Cable.Therefore with LAN cable you potentionally can add some latency, but in real life and with spare LAN you can get 0-1 ms extra latency, that will not significantly make worse to 2-5 ms you already have.
1) Scheme with MIDI interfaces can\'t provide time stamping for delay compensation occured on D->H stages.
MIDI Replicator adds time-stamps to each packet and provides these timestamps to receiving part. The receiving part (softsynth or sequencer) can use this time stamps for compansating delays and minimizing jitter. This is especially significant when syncronizing to MIDI clock. Softsynths can also make use of time stamps.
2) MIDI Replicator can quickly transmit large amount of MIDI data. Usual LAN interfaces allows 10 000 Kbps or 100 000 Kbps wich is much quicker than 31.25 Kbps of MIDI. These can make an advantage when transferring system exclusives, dense MIDI stream or even in situations when you have number of simultaneous events to be played.
3) You don\'t have to have extra MIDI ports and MIDI cables.
With MIDI Replicator and spare LAN you can achieve the same of sliglty bigger latency compared to MIDI Interfaces, but MIDI Replicator provides time-stamping that can reduce jitter and can be used to compensate delays. MIDI Replicator can quickly transmit MIDI data and it eliminates necessity of extra MIDI ports and cables.