From alsa-devel-owner@alsa.jcu.cz  Thu Oct 29 15:17:46 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 PAA22077;
	Thu, 29 Oct 1998 15:16:11 +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 PAA08207; Thu, 29 Oct 1998 15:16:09 +0100 (MET)
Received: from ibm02ww3.ww.uni-erlangen.de by ww.uni-erlangen.de with SMTP;
	id AA11591 (1.37.109.4/7.3m-FAU); Thu, 29 Oct 98 15:16:02 +0100
Message-Id: <9810291416.AA11591@servww1.ww.uni-erlangen.de>
Received: by ibm02ww3.ww.uni-erlangen.de (sSMTP sendmail emulation); Thu, 29 Oct 1998 15:10:47 +0100
To: Jaroslav Kysela <perex@jcu.cz>
Subject: Re: ALSA + AWE32 
Cc: alsa-devel@jcu.cz
In-Reply-To: <Pine.LNX.3.96.981029134953.29367A-100000@entry.jcu.cz>
References: <9810291243.AA09300@servww1.ww.uni-erlangen.de>
	<Pine.LNX.3.96.981029134953.29367A-100000@entry.jcu.cz>
From: "Takashi Iwai" <iwai@ww.uni-erlangen.de>
Date: Thu, 29 Oct 1998 15:10:47 +0100
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

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

> OK. I'll try explain what I mean with my above lines...
> There are some problems which are similar for all soundcards which have
> ability downloading of new samples.

I found later that I misunderstood about your mail..

> 1) soundcard memory allocation routines (bottom routines)
>    - allocate block of soundcard memory for one sample (I don't mean
>      instrument!!!)

OK, this is inevitablly necessary.


> 2) instrument / sample allocation routines
>    - routines which will manage instruments and samples stored in
>      soundcard memory (with some dynamic list)

>      int snd_seq_card_instr_clear();
>      int snd_seq_card_instr_alloc( struct instrument **instr,
>                                    int instrno,
> 				   void *private_data );
>      int snd_seq_card_instr_free( struct instrument *instr );
>      struct instrument *snd_seq_card_instr_find( int instrno );

>    We can even discuss about instrno, in this number should be encoded
>    if instrument is MIDI instrument (bank # and program #) or MOD
>    instrument (sample).

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. 

Besides, the data to be found will be a list of patches, since multiple
samples are allowed for identical instrument/note/velocity set
(suppose stereo sounds).  That is, driver must pick up the all patches 
which match to the given condition (inst/note/vel,etc).

Furthermore, different instruments can share a same sample but with
different parameters (envelop, LFO, etc).  Then, in my driver, three
different lists, for files, instruments and samples, are handled
seperately. 

Of course, the problems above never occurs when playing only MOD
sequences, or using GUS-style patches (well, still needs to find the
exact sample with keynote or frequency).
Thus, I think it would be better to replace instro with a generic key
data and to give possibility of key comparison function.  I mean, we
can at least provide the skeleton list management routines.

The handling of drumset is also for discussion.  The OSS-GUS handles
drum instruments by mapping them on preset #128-255.
But in the soundfont files, they are handled as if they're a normal
(monolithic) instrument assigned with bank#128, but distinguished only
by different keynote.


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

