Re: [AD] Non-FM OSS MIDI driver

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Mon, May 27, 2002 at 10:22:55AM +0200, Eric Botcazou wrote:
> > I've always disliked Allegro's treatment of MIDI files, it seems to
> > do far too much fiddling; this driver might work better (at least
> > for wavetable and external MIDI, I don't know about FM) as a
> > raw MIDI device, since that's the way OSS seems to work itself.
> 
> Could you elaborate on that ? Do you think Allegro's treatment of MIDI
> files is too low-level ? Would you like to see a more high-level framework ?

My main complaint is that it's too high level, it interprets the
events too much. :)  Here's a summary of how (IIRC) Allegro's
MIDI handling works:

Allegro has two modes of operation for its MIDI drivers -- raw
and not raw (say cooked, though Allegro never calls it that).
Raw mode was only really used for output to generic MIDI devices
through the SB MIDI out port; Allegro just sends each event to
the MIDI driver's raw midi method, as MIDI data, and the raw
midi method passes it out the port.  In cooked mode, Allegro cuts up
the MIDI events, and calls different driver methods depending on
what the event was (e.g. note-on, note-off).  The idea is to
have the MIDI stream interpreting code in one place only, rather
than duplicated in all the drivers.  But it's not quite this
neat, because Allegro doesn't tell the note-on method which MIDI
channel the note belongs to.  So it actually discards some
information from the source events too.

The reason it may work better for this driver to use the raw
approach is that OSS itself takes raw MIDI events as input
(which is why it's also inconvenient that Allegro discards the
channel number).  My main reason for not changing the driver at
that stage was the FM synthesis -- maybe that works better by
using Allegro's voice allocation routines.  Peter?

Another interesting aspect is that OSS seems able to handle the
timing of notes itself too.  I don't know whether that's usable
in rewrites of the API, but it could mean less dependence on
getting accurately timed interrupts.

George




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/