Subject: Re: [linux-audio-dev] a new application underway
From: David Slomin (dgslomin_AT_CS.Princeton.EDU)
Date: pe loka 08 1999 - 11:21:43 EDT
On Fri, 8 Oct 1999 thudson_AT_cygnus.com wrote:
> One feature I think would make the ALSA sequencer even more useful would
> be to add a "fake" raw midi interface. That is, an interface that behaved
> like the raw midi interface to the client application, but showed up
> in the list of ALSA sequencer clients that could be routed to other
> applications. It would deliver raw midi events from other clients
> at the right time. As far as the app is concerned it would see them
> as coming in from an external port in real time. This would allow
> legacy apps to participate in the routing architecture and perhaps
> benefit from the enhanced timing *without modification*.
This is hitting very close to home with me. I've looked at the way this
is done on Windows (MME) and SGI (libmd) and have implemented my own on
Linux (NetMIDI). If you view the problem in OOP terms, it is easier to
visualize the differences.
On MME and libmd, the "object" on which open, close, read, and write
methods are available is a MIDI port, which can be either an Out or an In.
To call these methods is a trivial operation, but to create the object
is very difficult... it requires driver-level programming, which turns off
many programmers and thus stifles progress.
On NetMIDI, the object is not a port, but rather the "cable", which is
either a socket connection or a pipe. You still have the same open,
close, read, and write methods, but to create a pipe or a socket
connection is a trivial operation, which requires no driver-level
programming; it can even be done via shell scripts. An added benefit is
that there are a practically unlimited number of "cables" that you can
have open at once, which is not something that is guaranteed in either MME
or libmd.
If this happier view of the world is impractical to add to ALSA at this
point, we could write an ALSA midi port driver (once, so we'll not have to
deal with the pain of driver programming again) similar to the "MIDI Thru"
drivers available for Windows MME. These screwy drivers act like fifos
which other MIDI apps (not drivers) can access the way I described for
NetMIDI. Once you had this, you wouldn't write your softsynth as a
driver, but as a regular app that listened on the Thru driver's port. The
drawback here is that you have a strictly limited number of Thru "cables".
Div.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST