Hi, Stephen!

Good to hear from you. Squeak's general approach is to do as much
as possible at the Squeak level. Thus, I would do the note-off
scheduling at the Squeak level. This makes porting the MIDI
primitives easier and decreases the chance of behavioral
differences between platforms.

The simplest MIDI output primitive is your "put: byte_array length: size".
However, to get tighter real-time scheduling, the driver needs to
have a timestamped buffer of events. The MIDI player in Squeak should
commit events to the drivers buffer as late as possible, just early
enough so that events get sent on time even if an incremental GC
occurs at an awkward moment. Given the current GC performance,
this is probably only 10-20 milliseconds ahead of time. (You
pointed out the need for millisecond precision when doing smooth
drum rolls and the like.) Your "play:at:dur:amp:voice:" primitive
supports this mode. My only suggestion is to generalize the interface
to allow any channel voice message, including noteOff and controller
changes, to be scheduled by the low-level driver. All of these messages
fit into two or three bytes, simplifying the task of storage management
in the C driver code (see note below).

Re:
>The most pressing question is how to handle MIDI note-off commands. One
>option is to have the lowest level code in the MIDI port decide whether to
>schedule a separate note-off event. The note-oriented MIDI port output method
>is [play: key_number at: start_time dur: msec amp: velocity voice: channel].
>The lowest level of MIDI output method is [put: byte_array length: size]. The
>ramifications of passing the duration down to the port level is that we can
>thus support MIDI ports might actually have a note-off scheduler in C (I'm
>not certain if any do, though). This also means that we have to create and
>schedule a new event for the note-off with each note-on. It seems "dirty" to
>me to have a low-level driver doing this, but I can't think of another way to
>accommodate differences between drivers. The alternative would be to disallow
>passing durations to the port altogether.

I agree. It seems like an inflexible design to build the note-off
scheduling policy into the driver where it is hard to change. I'd
prefer to "disallow passing durations to the port altogether" or,
better yet, to have the driver be totally unaware of the semantics
of MIDI events.

Incidentally, Andreas says that the Win32 API supports a scheduled
transmission mode in its MIDI driver.

Hope this helps!

	-- John

Note: I know that some manufactures support a richer note control
protocol embedded in system exclusive messages. We'd want to make
the max size of a scheduled transmission be large enough to
accomodate a noteOn with all the frills plus the system exclusive
command and terminator bytes. Would 16 bytes do it?