From alsa-devel-owner@alsa.jcu.cz  Mon Feb  8 01:00:37 1999
Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id AAA17969
	for <alsa-devel@alsa.jcu.cz>; Mon, 8 Feb 1999 00:58:42 +0100
Received: from [212.238.75.184] (helo=obelix.vande-pol.demon.nl)
	by post.mail.nl.demon.net with esmtp (Exim 2.02 #1)
	id 109e5z-0001Xa-00
	for alsa-devel@alsa.jcu.cz; Sun, 7 Feb 1999 23:58:36 +0000
Received: (from frank@localhost)
	by obelix.vande-pol.demon.nl (8.8.7/8.8.7) id AAA31264
	for alsa-devel@alsa.jcu.cz; Mon, 8 Feb 1999 00:29:40 +0100
From: Frank van de Pol <frank@vande-pol.demon.nl>
Message-Id: <199902072329.AAA31264@obelix.vande-pol.demon.nl>
Subject: Re: Writing Article Re: Linux audio;  also have new hardware support
To: alsa-devel@alsa.jcu.cz
Date: Mon, 8 Feb 1999 00:28:25 +0100 (MET)
In-Reply-To: <Pine.LNX.3.96.990207102251.1211A-100000@entry.jcu.cz> from "Jaroslav Kysela" at Feb 7, 99 12:00:54 pm
Content-Type: text
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Jaroslav Kysela wrote:
>
<SNIP>
> 
> I would like to see instrument (or patch - the instrument word seems better
> word for me) management in the alsa-lib API. I'm thinking about these
> extensions in the alsa-lib sequencer interface:
> 
> - instrument management
>   - a list of instruments available (assigned to the sequencer's client,
>     port and channel)
>   - names of instruments available

This is indeed a "must have" functionality as the client/port numbers have
currently to be assign manually. The client numbers are (if not should be)
assigned dynamicly, so a driver can never guarantee that it will always get
the same client ID. Doing some sort of lookup (eg. 
snd_seq_get_client_id_by_name() or something in the spirit of that) might do
the trick.

Getting a list of ports that have certain capabilities might also be very
usefull for (interactive) applications. I guess we will have to add a new
entry to the sequencer CAPABILITY stuff to identify ports that can act as
some sort of an instrument (eg. MIDI ports, synths). 

Imagine this: A user can pick his/her device from this list of
CAP_INSTRUMENT ports. The application can store the name of the ports in
some config file, and the next time the app is stated it can retrieve the
port names, perform a name to ID lookup, and keep using devices as
previously selected by the user.

Naming individual ports will be enough for most applications - the current
ALSA sequencer already has capability to store the name of a port. Trick
will be to set these names to usefull values during startup; perhaps
something a user can do with the alsactl tool? 

In my config this could look like:

physical port		name
~~~~~~~~~~~~~		~~~~
ext.midi 0	 	Yamaha XG
ext.midi 1		Bassstation + Kawai K1
onboard synth 		Soundblaster AWE64
onboard synth		Gravis Ultrasound MAX


A more fine grained view of available instruments might be handy but is also
much more complicated to do it good for all kind of devices: info / name for
each channel, inquire patch info - current loaded / active patches etc. This
stuff is "not for now" [tm] I think, but good idea for the future. Perhaps
already provide stubs for this?


> - enhanced event routing / rewritting + channel management
>   - there may be some global configuration file which will describe
>     default configuration for the sequencer which can be overrided
>     for each application
>   - it should simplify building of new applications
>

Just some quick brain fart:

Current event routing is always from some port to some other port; either
directly or through the subscription mechanism.

If we want to add some more enhanced routing (and even event rewriting) we
can implement this as a client that has a similar function as an advanced
MIDI patchbay/processor:
	- perform filtering on incoming data (eg. kill sysex from port X)
	- manipulate data (eg. transpose, remap controllers)
	- reroute events (eg. port V, channel W to client X, port Y, ch. Z)
		perhaps even depending on the message content (ie. create
		layers & splits)

To make use of such a event processor an application will have to send it's
data to the processor's input port which is configured to be routed to the
desired output. This is very much the same as seen with outboard studio
gear (eg. effect processors etc.): some "box" is placed in the signal chain
to perform some processing.

Point is that such a "processor" can be made very simple/easy (both for user
and programmer) or very complicated... For the latter some event filter
concept (ie. programming language!) like Opcode MAX might be used. If such a
processor is usefull I think it is best to provide a fairly simple processor
as (standard available) kernel client (low latency!) and let the complex
stuff be handled by some userland client.

Any comments?


> 
> Both of these features should use external code (dlopen()/dlclose())
> for special / custom handling. For example network code can be placed
> there.

Sounds good! 
 
> 
> I welcome any ideas for these interfaces now. I'm not sure if it's best
> create one big virtual synthesizer with many described MIDI channels or if
> applications have got another requirements.

I think it is best to present applications a whole bunch of PORTS
(addressable using client.port, as is currently with alsa seq.), with each
port supporting up to 16 channels (compatible with MIDI) instead of one port
with many channels. 

The "one one big virtual synth with many MIDI channels" could have been a
good idea if all those channels are fairly comparable, but these aren't: one
might have a some channels driving an external MIDI synth, some channels for
sample playback on a AWE/GUS, and even a few channels with an OPL3 FM synth.
Having these kind of "instruments" on distinct ports helps the user
differenciate between them. This is also more like the approach seen on other
equipment: musicians are more familiar to this scheme.


Frank.

+---- --- -- -  -   -    - 
|Frank van de Pol                  -o)
|Frank@vande-pol.demon.nl          /\\
|                                 _\_v
|Linux - Why use Windows, since there is a door?
|
|ALSA Sequencer: http://www.vande-pol.demon.nl/alsa/

