From alsa-devel-owner@alsa.jcu.cz  Sun Feb  7 12:02:36 1999
Received: from entry.jcu.cz (IDENT:perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id MAA27707;
	Sun, 7 Feb 1999 12:00:54 +0100
Date: Sun, 7 Feb 1999 12:00:54 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Thomas Hudson <thudson@cygnus.com>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: Writing Article Re: Linux audio;  also have new hardware support
In-Reply-To: <36BCDB9C.E9CAE0EF@cygnus.com>
Message-ID: <Pine.LNX.3.96.990207102251.1211A-100000@entry.jcu.cz>
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

On Sun, 7 Feb 1999, Thomas Hudson wrote:

> Frank van de Pol wrote:
> > The channel / device management like on Apple Macs you mentioned in your
> > example is indeed very important for pro work, especially if one has a
> > complex or big MIDI configuration. This is application specific work, but
> > some kind of standard or a library might help here. Unfortunate these kind
> > of stuff is almost nonexisting for other platforms than Apple... For the
> > time being a end-user application (like a sequencer app) wil have to provide
> > facilities for that. Simply 'Naming" individual channels might already be
> > enough for most users.
> > 
> I've been giving this a lot of thought lately. I think the ALSA sequencer 
> is the right foundation for something more. I know that on Windows, sequencers
> like Cakewalk let you define each channel in terms of what is listening on that
> channel, let you define patch names, and even let you define note names for
> drum patches. This IMHO is a bad approach, since I have to do it for every
> app. My setup further complicates this in that I have a MIDI-controlled
> patch bay w/ eight inputs and outputs. I plan to soon port software I've 
> written that multiplexes two outputs from my computer to the eight outs
> on the patch bay. Thus, my software has to "lie" about eight devices
> connected, receive the events for the devices, and set up routing before
> sending the message on to the appropriate device.
> 
> I've thought of writing a facility on top of ALSA similar to Opcode's 
> OMS (Open MIDI System, what a misnomer). A facility to allow a user
> to describe his setup. This can be automated somewhat for newer devices
> using the Universal Non-realtime SysEx Device Inquiry. 
> 
> For a high level interface, I want to direct apps and applets to named
> devices and other apps. I also want a facility for obtaining patch names.
> Perhaps this naming facility runs as a port listener and when a request
> for patch names is received it invokes the patch manager for that device.
> This could also hide differences in bank switching. For example my
> Ultraproteus has 4 banks of 128 programs. This should simply appear
> as 512 available patches to another program. Requests would be made
> for a patch name and not by sending program change requests. Older
> devices don't always use the standard for bank switching.
> 
> All this of course could be user space. All easily done with the 
> current sequencer design (which I find excellent, BTW).
> 
> Has anyone given these issues any thought? Could we get some ideas
> and possibly start working toward a design. I had considered using
> Orbit/Gnome (a CORBA orb), but I realize this may not be on every 
> users machine and it may be overkill (and slow).

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

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

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.

							Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic


