From alsa-devel-owner@alsa.jcu.cz  Fri Feb 26 17:31:43 1999
Received: from druid.inprise.com (druid.inprise.com [143.186.11.70])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id RAA17947
	for <alsa-devel@alsa.jcu.cz>; Fri, 26 Feb 1999 17:31:35 +0100
Received: from godzilla.inprise.com (mail.inprise.com [10.186.1.4])
	by druid.inprise.com (8.8.8+Sun/8.8.7) with ESMTP id IAA09249
	for <alsa-devel@alsa.jcu.cz>; Fri, 26 Feb 1999 08:28:08 -0800 (PST)
Received: from kduffey ([10.143.1.75]) by godzilla.inprise.com
          (Netscape Messaging Server 3.6)  with SMTP id AAA4DB4
          for <alsa-devel@alsa.jcu.cz>; Fri, 26 Feb 1999 08:28:05 -0800
Message-Id: <3.0.32.19990226082835.009604b0@mail.inprise.com>
Date: Fri, 26 Feb 1999 08:28:36 -0800
To: alsa-devel@alsa.jcu.cz
From: "Kevin Duffey" <kduffey@inprise.com>
Subject: Re: Instrument abstract layer
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

At 12:10 26.02.99 +0100, you wrote:
>On Thu, 25 Feb 1999, P.J.Leonard wrote:
>
>> Jaroslav Kysela wrote:
>> > 
>> > On Wed, 24 Feb 1999, Paul Barton-Davis wrote:
>> > 
>> > > is there a good reason for not using the same kind of model that
>> > > several synths do ? Components:
>> > >
>> > >       SAMPLES - take up memory
>> > >       PATCHES - modulations of samples
>> > >       INSTRUMENTS - 1 or more patches combined
>> > >       PROGRAMS - instruments selected based on:
>> > >                      (1) note number and/or
>> > >                      (2) on velocity and/or
>> > >                      (3) other
>> > >
>> > > another model:
>> > >
>> > >       SAMPLES - take up memory,
>> > >       MULTISAMPLES - aliases for samples accessed via note number
>> > >       PATCHES - modulations of multisamples
>> > >       INSTRUMENTS - as above
>> > >       PROGRAMS as above
>> > >
>> > > I'm not sure I've explained this clearly, but the idea works well for
>> > > both my WaveFront card, my Kawai K5000S and several other devices I
>> > > have or have written.
>> > 
>> > The instrument abstraction layer will cover only a basic access to
>> > instruments (in you example to PROGRAMS). I don't want design some
>> > universal instrument format. This isn't possible.
>> > 
>> > I only need to design some unique identifiers for these instruments.
>> > These identifiers must be accessible over standard MIDI events (program
>> > change, bank change and note-key for the drum channel).
>> > 
>> > Other information (groups of patches and samples) will be specific for
>> > the lowlevel driver (or hardware). I don't know if the sequencer must
>> > cover with some universal way to control of these things. For
>> > example things like sample (wave) sharing must be done in the lowlevel
>> > driver.
>> > 
>> > I want basicaly from ALSA instrument interface:
>> > 
>> >         1) unique instrument identification
>> >                 (MIDI: cluster, emulation, bank, program, note-key)
>> >                 (Otherwise: cluster, bank, program)
>> >         2) instrument download to the synthesizer
>> >         3) instrument download from the synthesizer
>> >         4) access to list of instruments in the synthesizer
>> 
>> 
>>  The problem with this is that it does not address the problem of how
>> music
>> written for one sound card can be played on another sound card. I think
>> that
>> a standard description of sampled type synthesis is essential otherwise
>> it will
>> be impossible/difficult write generic high level applications. 
>> 
>>  Look at it from my point of view. Say I have constructed a nice layered
>> sample
>> that plays different samples depending on note and velocity (this is
>> essential
>> for a decent piano sound). I can store this information in a file that I
>> can use
>> for my AWE32 but this is useless for some one else and they will not be
>> able to
>> reconstruct the piece of music. 
>>  
>> 
>>  If I am wrong please tell me to shut up :-)
>
>The UNIVERSAL INSTRUMENT FORMAT is my dream, too. We can discuss about
>this issue in the future, but at this time we aren't talking about
>instrument formats, but about layer which will manage these instrument
>formats.
>
>OK. I tried add the introduction section to my proposal. I hope that
>people will understand for which purposes we need the instrument
>abstraction layer. Please, check again: http://alsa.jcu.cz/proposals

To be honest..the BEST support you can do right now is for the SoundFont 2
banks. It supports a wide variety of multi-split, multi-samples patches,
each bank having as many instruments as desired. Rather than re-invent the
wheel, why not just use that format? Or at least one that can easily work
with that format? I dont want to copy someone elses stuff, but SF2s are
very popular now, and there are quite a few of them out there. Along with
the Vienna editor for Windows, which I don't think would be too hard to
port to Linux, a complete patch librarian is ready as well. 

Maybe I say this because I "hope" the SB Live will be supported some day on
the Linux side of the world. Until then, my someday completed music program
will have to do! :)



Kevin Duffey
kduffey@inprise.com

