Re: Serial Midi Interfaces
Re: Serial Midi Interfaces
- Subject: Re: Serial Midi Interfaces
- From: "James Chandler Jr." <email@hidden>
- Date: Thu, 3 Oct 2002 14:25:15 -0400
>
Good topic. There has been a lot of clamoring on some other music
>
lists (daw-mac) about whether serial MIDI interfaces will be
>
supported over things like the Griffin gPort and various USB serial
>
interfaces. A lot of people are going to be disappointed if the
>
serial port MIDI driver doesn't learn how to support such things...
>
Along with multi-cable interfaces... (that's been mentioned before).
>
If the source is available in the Darwin tree, maybe we can get a
>
co-operative effort going to add some of this to it. [Unless, Apple
>
is planning on doing it.]
I have a cheap USB interface for OSX testing, but am loathe to buy a new USB
multi-port interface because the old MIDI Time Piece II still works
perfectly with the G4Port. There are probably tens of thousands of MTPII,
MTP AV, MIDI Express, Studio 4 and Studio 5 owners in the same situation.
A humble suggestion--
If a serial driver is just smart enough to use FAST mode (1X multiplier in
the SCC), and can route input/output to all the available ports-- This alone
would be sufficient to make most users kiss the ground in gratitude.
One could "safely ignore" device-specific sync and MIDI processing features
in these old interfaces. If somebody still needs those device-specific
features, he can probably afford to cough up a few hundred bucks to buy a
new USB interface. But most folks nowadays do all the audio and midi in the
computer, so the device-specific hardware communication features are not
absolutely essential for the average modern user.
Since the Studio 4 and Studio 5 can be operated in a MidiTimePiece
compatible mode, you could support all the above interfaces with just a thin
MTP support layer in the serial midi driver.
The MTP method accesses the different MIDI cable pairs with a non-standard
use of the MIDI status byte 0xF5, a two byte message. When the MIDI needs to
go out a new cable (or is received on a new cable), the message '0xF5,
PortNum' is sent. PortNum of zero sends to all ports, and 1 - 8 or 1 - 16
sends to a specific port (depending on the number of available i/o ports).
Doug Wyatt said that CoreMIDI blocks 'illegal' 0xF5 messages, so I suppose
one would write an OSX serial driver that exposes 8 or 16 input/output ports
to OSX. The 0xF5 messages would be low-level parsed (input) or inserted
(output) on the serial stream very low
in the driver, so the 0xF5 messages would never need to be filtered out by
OSX.
If nobody else does this in the next year or two, will be forced to do it
myself (GRIN). Of course Doug Wyatt is the most eminent expert in the world,
on both Serial MIDI interfaces and CoreMIDI. He could probably do the work
in a couple of hours, as if he didn't have anything better to do (GRIN).
>
I took a quick look at termios.h (and ttycom.h) and now I'm curious.
>
MIDI needs an external clock, but there doesn't appear to be any way
>
to set up an external clock in the headers. How is the serial MIDI
>
driver doing this?
In the ancient dim Mac past, you had to poke numbers into the SCC
memory-mapped registers. That is still the crude state of my classic mac app
"built-in-serial" drivers option, since the technique stubbornly continued
to work for years after Apple advised against it, even up to OS 9.2.2 with a
Griffin G4Port.
Maybe 6 or 8 years ago, Apple added additional serial setup constants in
Communications Toolbox or some related section, where you could turn on
external clocking from a high-level serial driver open command. But since
the old stone-age method continued to work, I never fiddled with that. Dunno
if this part of the code made its way into Carbon.
James Chandler Jr.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.