From alsa-devel-owner@alsa.jcu.cz  Thu Oct 29 10:36:37 1998
Received: from pat.bath.ac.uk (pat.bath.ac.uk [138.38.32.2])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id KAA31619
	for <alsa-devel@jcu.cz>; Thu, 29 Oct 1998 10:36:28 +0100
Received: (qmail 27529 invoked from network); 29 Oct 1998 09:36:26 -0000
Received: from mary.bath.ac.uk (HELO bath.ac.uk) (138.38.32.14)
  by pat.bath.ac.uk with SMTP; 29 Oct 1998 09:36:26 -0000
Received: from tobi.bath.ac.uk by mary.bath.ac.uk id aa11646; 29 Oct 98 9:36 GMT
Message-ID: <363836FF.6201@bath.ac.uk>
Date: Thu, 29 Oct 1998 09:35:59 +0000
From: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>
MIME-Version: 1.0
To: alsa-devel@jcu.cz
Subject: Re: ALSA + AWE32
References: <199810290302.WAA22562@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Paul Barton-Davis wrote:

> 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.

 How about if I replace should with could ? The point here is
if something changes a sound then you want to be able to sequence it.
So you can use it as an effect in a piece of music. 

> 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 ?

 If changing patches during playing a song is possible with the hardware
then the sequencer might want to do this. 

> 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.

 But what if you would like a composition that uses the WavePanel
functionality
from the sequencer ? That is -- how do you save a composition and replay
it ?

 The problem with this modular approach is getting all together into a 
useful piece of software that is quite and easy to use. The main reason
I started writing my software was that under WINDOWS loading a
instrument
from a sound font file so CAKEWALK could play it was a complete mess.
You needed AWETOY and it was quite a few changes of window and key
strokes
to get the new patch in place. Under my present system I can simply
click
on the soundfont preset name and it is loaded automatically into the
current
voice of my application. This is while I am actually playing the song
( OK there is a bit
of a glitch but for auditioning presets it is about as cool as you would
want). 

[snip]

> 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.

Aggreed OSS is not the best design :-) But I repeat that running it
through
the sequencer should be an option if you want it (I do). 

> 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".

 As long as you can hook all the controls up to the sequencer via events
then I am happy. 

  cheers Paul.

