From alsa-devel-owner@alsa.jcu.cz  Thu Oct 29 18:06:05 1998
Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id SAA01775;
	Thu, 29 Oct 1998 18:04:46 +0100
Received: from servww1.ww.uni-erlangen.de (servww1.ww.uni-erlangen.de [131.188.142.2])
	by faui45.informatik.uni-erlangen.de (8.9.1/8.1.49-FAU) with SMTP id SAA22819; Thu, 29 Oct 1998 18:04:43 +0100 (MET)
Received: from ibm02ww3.ww.uni-erlangen.de by ww.uni-erlangen.de with SMTP;
	id AA15593 (1.37.109.4/7.3m-FAU); Thu, 29 Oct 98 18:04:36 +0100
Message-Id: <9810291704.AA15593@servww1.ww.uni-erlangen.de>
Received: by ibm02ww3.ww.uni-erlangen.de (sSMTP sendmail emulation); Thu, 29 Oct 1998 17:59:21 +0100
To: Jaroslav Kysela <perex@jcu.cz>
Subject: Re: ALSA + AWE32 
Cc: alsa-devel@jcu.cz
In-Reply-To: <Pine.LNX.3.96.981029152945.29367E-100000@entry.jcu.cz>
References: <9810291416.AA11591@servww1.ww.uni-erlangen.de>
	<Pine.LNX.3.96.981029152945.29367E-100000@entry.jcu.cz>
From: "Takashi Iwai" <iwai@ww.uni-erlangen.de>
Date: Thu, 29 Oct 1998 17:59:21 +0100
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

>>>>> On Thu, 29 Oct 1998 16:00:26 +0100 (CET), Jaroslav Kysela
<perex@jcu.cz> said: 

>> I guess this part is dependent on implementation.
>> In the case using soundfont samples, the search key must include
>> keynote and velocity numbers, because soundfont can handle different
>> samples assigned with own keynote and velocitry ranges even in an
>> instrument.  Also, if these platforms are supported, the type of MIDI
>> (GM/GS/XG) and map number should be embedded in the key. 

> Yep, this is true. Maybe we can assign something like instrument type
> to instrument structure.

> There should be six instrument types:

> 1. ALIAS (pointer to another instrument, handled by abstract layer)
> 2. SAMPLE (very simple format for MOD players)
> 3. GM-MIDI
> 4. GS-MIDI
> 5. XG-MIDI
> 6. MT32-MIDI

OK, let me rewrite the flow of data processing to clarify the
situation.

The abstract routine allocates, releases and searches an "instrument"
structure record for clients for a certain key.
The instrument search key contains:
1. instrument type (listed above)
2. instrument number

The instrument number can contain the following information in the
case of MIDI instruments:
1. MIDI program number
2. bank number (for MIDI)
3. map number (for GS & XG MIDI)
Since one byte is enough for each, this may be combined as an
integer. 

In the other types, for example SAMPLE, the instrument number should
be handled as a simple integer index.

Now here I write some details to support for soundfont format.
In the case of soundfonts, the returned data is a list of matched
instruments (not the actual voice parameter records).
The actual played instruments are determined by further
pattern-matching of keynote and velocity from this list.
The lowlevel driver allocates the memory block for real voice
parameter record differently, and these records are managed by 
linked-list in the lowlevel driver.  Thus, the instrument structure 
contains only a starting pointer to this linked-list.

Also, the samples are handled independently from the voice parameter
list above.  The sample record contains the address of a sample and
the assigned sample id.  Since the voice parameter record searches the 
corresponding sample record from this id, it would be useful if the
abstract functions can handle not only the instrument list but also
the sample list.


BTW,

> Why you have list for files? I think that file management should be in
> application level, not driver...

Well, the file list doesn't mean the actual file, but it contains a
linked-list of instruments and samples.  Each file list is
independent, and is never affected by other file lists.
One reason to use this list is that the driver needs to manage the
file id to tell the same sample ids in different soundfont files.
Another reason is the capability of multiple instruments.
Suppose that you already loaded full MIDI instruments, but want to
load only a piano additionally.  The new piano is appended on RAM
(without removing the old piano from RAM), and the instrument list is
rebuilt.  Then, you want to remove only this piano.  The driver needs
to rebuild the instrument list from the file list, then the old piano
appears again in it.

-- 
Takashi Iwai / iwai@ww.uni-erlangen.de
Department of Materials Science
Friedrich-Alexander-University Erlangen-Nuernberg

