jl cooper do midi line amplifiers for doing midi over long distances.
http://www.jlcooper.com/pages/mla.html
midi is a current loop signal- driven through an optical isolator - its not voltage driven.MIDI (Musical Instrument Digital Interface) is an increas- ingly important consideration for schools, recording facilities, stadiums, arenas, hotels, amusement parks, or other facilities where MIDI messages are required to be sent a long distance, or to multiple locations.
The MIDI standard only permits a maximum cable run of less than 50 feet. The innovative MLA Series MIDI Line Amplifiers overcome this limitation.
the capacitance of the line limits the rise time of the signal to a certain cable distance.
Yes, i want to build an apple midi network through ethernet. Catalyst will then be controlling arkaos with midi (50-75m max) and powerpoint/keynote with MSC or midi (2m). I wrote MSC over 100m but it's only midi but that's the same principle in running long ethernet cables.
I know it's perhaps a bit complicated to do it like this but the show has already been made with these programs before i had catalyst. So if i have the time i will try to convert everything to that.
I will experiment a bit and let you know. But i cant do the long runs at home.
There are other options like QLab and DLight to get it all working but for the moment i really into cat.
To keep it as simple as possible i will run on 3 macs, respecitivly 1 cat, 1PP, 1 arkaos :
Master will be cat (Macbookpro) - Ethernethub - line 1 to PP (powerbook G4/1.5) and line2 to Arkaos (powerbook G4/1.5 with fw800 external drive : only 1 movie playing 640/480 photojpeg 75% of higher). All have tiger on them.
I just tried the cat to PP setup with a utility called midipresenter which allows to send midi programs changes or MSC for controlling PP. With MSC, started in catalyst (internal or with internal relative) it worked fine but this was only the macbookpro connected to powerbook PP. The setup was done over a midi netwerk with a 1m ethernetcable.
Richard : what about the collision thing when working with 3 macs : 1 macs transmits 2 signals. I presume this will be ok?
Not the same principles-
if you need ethernet to go further reduce the speed to 10MBt
the limit in ethernet is not electrical but protocol itself.
its the collision detection not the electrical issues-
http://www.geocities.com/SiliconVall.../ethernet.html
with midi signals the limit is electrical determined by rise time of opto isolators used by midi receivers.What is a "collision"?
At any one instance, in an Ethernet network, only one device can transmit. If two devices transmit at the same instance, then the signals from both devices will collide and a "collision" will occur. When a "collision" occurs, the signals will get distorted and the frame will be lost. Collisions are very common in a Ethernet network.
there are no collisions.
http://www.repairfaq.org/filipg/LINK/F_MIDI.htmlThe interface operates at 31.25 (+/- 1%) Kbaud, asynchronous, with a start bit, 8 data bits (D0 to D7), and a stop bit. This makes a total of 10 bits for a period of 320 microseconds per serial byte.
Circuit: 5 mA current loop type. Logical 0 is current ON. One output shall drive one and only one input. The receiver shall be opto-isolated and require less than 5 mA to turn on. Sharp PC-900 and HP 6N138 optoisolators have been found acceptable. Other high-speed optoisolators may be satisfactory. Rise and fall times should be less than 2 microseconds.
I've not had a chance to try this as I'm away from my test setup, but this is what Stage Research had to say about what is happening when they send a MSC command to Catalyst.
I had originally stated the following...
"Showman is exporting this hex string for a GO command on cue 1.5 on Channel 8 - F0 7F 08 02 40 01 31 2E 35 F7. Cue 1.5 is triggered just fine in Catalyst. SFX is exporting this hex string for the same command - F0 7F 08 02 40 01 31 2E 35 00 00 F7. Catalyst does nothing but receives the command and displays "1.5::" in the MSC Last GO window. What are those extra four zeros and how do I get rid of them?"
Their response is...
"Those zeros delimit the cue list and the cue path. According to the MSC
spec, the sending device can optionally omit them (like ShowMan is doing)
but the spec says:
Controlled Devices should be able to accept more than one set of delimiter
bytes, including directly before F7H, and even if no Q_number, Q_list or
Q_path data are sent.
It goes on to say:
Controlled Devices which do not support Q_list (or Q_path) data must detect
the 00H byte immediately after the Q_number (or Q_list) data and then
discard all data until F7H is detected.
That means that it's Catalyst that isn't working properly because it should
be handling those zeros.
The first thing I would try is to put in 1 for the cue list and 1 for the
cue path and see if Catalyst will read that and probably ignore it. I'm
thinking that Catalyst is freaking out because it's finding two delimiters
next to each other (again, which it's supposed to be able to handle)."
Again, I have not been able to try this yet, but do they have a point about Catalyst not handling the MSC command as per the MSC spec? I will give it a go and post results as soon as I have them.
Richard - Show is at Birmingham Rep. Loading in on Monday, tech starting Tuesday afternoon. Will be at PLASA tomorrow, and in London doing another show the following week with DMX triggers (something I am much more familiar and comfortable with).
Thanks for your help,
Kevin
Kevin Carson
Lighting & Video Technician
Royal Shakespeare Company
kevin
you dont have to get rid of them-
just type this on the show cue - you want to trigger exactly how you see it received from the controlling device.
so type '1.5::' as the show cue number.
every single device i have ever seen has handled these things differently - and i try to preserve as much information about what the device is sending - so you can do different things if need.