From alsa-devel-owner@alsa.jcu.cz  Sat Oct 31 15:08:53 1998
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id PAA28012
	for <alsa-devel@jcu.cz>; Sat, 31 Oct 1998 15:07:27 +0100
Received: from someip.ppp.op.net (d-bm3-13.ppp.op.net [209.152.194.83]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id JAA08613 for <alsa-devel@jcu.cz>; Sat, 31 Oct 1998 09:07:17 -0500 (EST)
Message-Id: <199810311407.JAA08613@renoir.op.net>
To: alsa-devel@jcu.cz
Subject: Re: ALSA sequencer and synth control (Was Re: ALSA + AWE32) 
In-reply-to: Your message of "Fri, 30 Oct 1998 20:17:34 +0100."
             <Pine.LNX.3.96.981030195743.30707C-100000@entry.jcu.cz> 
Date: Sat, 31 Oct 1998 09:05:50 -0500
From: Paul Barton-Davis <pbd@op.net>
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Jaroslav writes:

>Maybe I didn't write about this instrument downloading before, but I'm
>thinking that ALSA sequencer must be able to do both methods:
>
>  - application requests some MIDI sample, this application doesn't
>    know anything about instrument downloading, it is written for
>    standard MIDI interface, thus downloading of MIDI instruments must
>    be handled in sequencer in two ways: preload complete instrument set
>    or load on demand
>  - application knowns about instrument interface and uses it for
>    instrument requests (good for MOD players and MIDI players and
>    for all situations where instruments should be downloaded before
>    playing - including live playback)

I'm sorry if I'm going over old ground again, but could you please
explain why a "sequencer" has a role to play in this kind of operation?
My understanding of the term "sequencer" suggests a role in providing
accurate timing of events, and not "a general purpose interface for
manipulating a synthesizer". 

>No, please, we can do effective caching of instruments if possible. In
>driver MUST be some kind of list of instruments to handle MIDI program
>change and other instrument change requests...

Well, now I'm beginning to understand why we see things so
differently. I suspect you've worked mostly with soundcards that don't
support MIDI control of their synth in hardware, and require driver
support to convert MIDI requests into some h/w specific operations.

By contrast, I've worked mostly with soundcards (the TB WaveFront
series, the TB Pinnacle, etc) that do support MIDI control of the
synth in hardware (or firmware), and thus the whole idea of having to
handle program change requests just doesn't exist: the synth does this
all by itself. The device drivers for these cards don't need to manage
instrument lists or anything like that. They do, however, need to
provide a mechanism for sending down new patches "on demand" as you
put it.

Put it this way: if you look at a standard MIDI file, and discover
that it uses programs 3, 56, and 99, then on a MIDI-controlled synth,
you need to do nothing at all. The synth already (if its been booted
correctly) has the relevant programs set up, and if it doesn't, there
is no way you can infer what you should do (except maybe "reset to
General MIDI").

By contrast, as I understand it, with the GUS, or the OPL FM synths or
similar non-MIDI devices, you get to look at the required program
changes, and say "oh, we're going to need to load instruments for
these programs, and we know which instruments they are since we
provide the MIDI interface layer". With such a device, the instrument
lists and so forth all make sense.

This is a pretty big difference, I think, that leads to quite
different approaches.

--p



