John Maloney and Andreas Raab had a few questions about the MIDI interface
code, and I thought it'd clear up a few misunderstandings to clarify these
issues for other users...

John asked:

> 1. Should we provide a way to specify which hardware ports to
>    open for MIDI? For example, on a Mac I might want to open
>    a MIDI port on the Printer Port but leave the Modem Port
>    available for some other application...

This is an OS (OMS) issue. OMS can be set up to talk to one or the other
port. By default, the Squeak prims open all devices on the configured port.
If you can think of a platform-independent way of distinguishing among ports,
tell me.

> 2. Shouldn't the "ReadMIDI" functions take a device index?
>    Or is your intent to merge the input streams from all open
>    devices?

Input is merged from all sources in the simple version. (Hey, that's MIDI)

> 3. Shouldn't ReadMIDIPacket take a buffer length as well as
>    a pointer to the buffer? Can it be used to read long system
>    exclusive messages?

Gee, you're right! I'll change this today and post a new version...

> If MIDIControllerCache is not supported,
>    or turned off then will all data be reported through this
>    primitive?

Yes, if controller caching is off, then every controller change message will
trigger a semaphore and be delivered through the readPacket interface.

> 4. In the ioctl list, I think MIDIHasBuffer implies MIDIHasClock,
>    doesn't it?

MIDIHasClock means that there's a separate settable clock in the driver,
which may not be the case for all drivers, even some that have a timestamped
output buffer.

> The MIDIInstalled query may be superfluous; one
>    can detect that there is no MIDI support because the ioctl
>    primitive will result in a primitive failure, say, on a
>    query of the version number.

This tests not only that the VM is OK, but also that the MIDI device driver
is present. (You can certainly run the MIDI VM on a Mac that's missing the
OMS extensions.)

> It looks as though this interface trucks in MIDI "events"
> rather than in raw bytestreams. 

The output prims take "raw" ByteArrays. The MIDIPacket object that's passed
to the read prim. is typeless; it's just a holder for a ByteArray and a
timestamp (and possibly some flags). I don't assume a MIDI parser in the driver.

> Here are my thoughts on your questions:
> Re: How to handle socket output? Do we need a call for setting
>     up connections for output to a specific machine/port? Should
>     MIDI over sockets be removed from the 'minimal' standard?
> I'd prefer to drop this from the minimal interface, although you
> can leave the parameter there as a placeholder.

This is done.

Andreas wrote,

> 1) If I understand your implementation correctly, you open *all* available
>    MIDI devices. Do you really think that this is a good idea?! On Win32
>    it would mean that no other app can access the MIDI ports after
>    sqOpenMIDI has been issued. This might be a problem if people want to
>    use one of the ports from Squeak and another one from a different app.

The driver opens all devices that are known to the OS. I assume that the
OS-level driver can merge streams. Is this impossible on Windows?
On the MAc and SGI, it's normal to log in to the MIDI driver and open all devices.

> 2) How would a time-stamped output buffer be used if there is one?

There's another output primitive (sqMIDIPlaySizeOnAt) that takes a timestamp
in msec.

> 1) The sqGetMIDIDeviceName() function should be modified to pass a maximum
>    length of the name pointer.

Fix coming.

> 2) Are you dropping incoming long commands?! I've not seen any place where
>    long commands are recorded. The OMS callback gets only the short
>    messages (which is ok since they're time critical) but what happens to
>    any long commands?!

See above--you're right. The Smalltalk side of the code re-tries the read
call with a larger packet if we receive a packet with > 3 bytes of data, but
the driver can't handle it (yet).

Thanks to you both for the questions...

stp

_ Stephen Travis Pope
_ Center for Research in Electronic Art Technology (CREATE)
_ Dept. of Music, Univ. of California, Santa Barbara (UCSB)
_ stp at create.ucsb.edu,  http://www.create.ucsb.edu/~stp/