From alsa-devel-owner@alsa.jcu.cz  Thu Oct 29 04:02:42 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 EAA01330
	for <alsa-devel@jcu.cz>; Thu, 29 Oct 1998 04:02:22 +0100
Received: from someip.ppp.op.net (d-bm2-1a.ppp.op.net [209.152.194.58]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA22562; Wed, 28 Oct 1998 22:02:17 -0500 (EST)
Message-Id: <199810290302.WAA22562@renoir.op.net>
To: alsa-devel@jcu.cz
cc: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>, iwai@ww.uni-erlangen.de
Subject: Re: ALSA + AWE32 
In-reply-to: Your message of "Wed, 28 Oct 1998 18:51:11 +0100."
             <Pine.LNX.3.96.981028184816.28810C-100000@entry.jcu.cz> 
Date: Wed, 28 Oct 1998 22:00:53 -0500
From: Paul Barton-Davis <pbd@op.net>
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Two related issues:

Jaroslav writes:

>It would be also nice separate abstract instrument handling from hardware.
>For example - GUS soundcards (and maybe soundcards with Dream chip) have
>same problems, too.. I think that instrument handling library should be in
>separate module which will call lowlevel code..

I don't think instrument handling should be abstracted this far. Once
you start messing with some very different soundcards (such as the
WaveFront series from TB), you'll get the sense that there isn't much
of an abstraction there at all to be encapsulated in a library.

For example, on the WaveFront synth, a "program" actually corresponds
to up to 4 different "patches" each of which can use a distinct
sample, or a "multisample" (different samples for each MIDI
note). This is so different from the GUS model that when I did my
2.1.XXX series driver for the WaveFront (which I will port to ALSA
real soon now), I completely abandoned any attempt of keeping a
similar patch-loading interface as the OSS GUS support.

P.J. Leonard writes:

>All the controls that could be meaningful to the sound of a voice
>should go through the sequencer so they can be used for real time
>modulation.

I think that Paul's suggestion is completely wrong. The OSS sequencer
shows how bad this ends up being. The crux of my objection is that if
the sequencer is the only way to access the synth, both for the
purposes of sending it MIDI *and* for programming it (e.g. patch
editing, sample downloads etc.), *and* the sequencer prevents multiple
applications from simultaneously holding the relevant synth device
open, then truly flexible software applications are screwed. Why ?

I often run my SoftWerk MIDI sequencer as the engine for my
soundcard's MIDI synth. However, I simultaneously run a custom
application called WavePanel which lets me edit the patches and do
other configuration of the synth in real time. Currently, under
2.1.119+ (Alan Cox's OSS-based modular sound), Softwerk accesses
/dev/midi* directly, and WavePanel access /dev/synth0, which is a new
minor device that Alan and I added precisely for this purpose (minor
device #9).

Under ALSA, SoftWerk would presumably be better off talking to the
ALSA sequencer to access the MIDI ports, but WavePanel should have a
way of running concurrently with SoftWerk so that I can tweak the
synth while the sequencer is still driving it.

The current OSS "route everything through the sequencer" approach
requires the application that opens the relevant device via the
sequencer to be smart enough to do everything. In my case, for
example, I would have to run one application that could do the MIDI
sequencing aspect *and* control the WaveFront synthesizer. This is a
huge mistake, IMHO, and my biggest gripe with the OSS sequencer.

I would like to encourage Jaroslav to adopt something like the
/dev/synth* interface, which is intended to be used for
hardware-specific raw access to a soundcard's synthesizer devices, and
can be open concurrently with any access via real or simulated MIDI
devices. Its not meant to be an abstraction: the operations you can
perform via this interface are 100% completely dependent on the
hardware on the "other side".

--pbd




