From alsa-devel-owner@alsa.jcu.cz  Thu Feb 25 22:26:33 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 WAA03065;
	Thu, 25 Feb 1999 22:25:54 +0100
Date: Thu, 25 Feb 1999 22:25:54 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Steve Ratcliffe <steve@parabola.demon.co.uk>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: Instrument abstract layer
In-Reply-To: <199902251932.TAA14346@ariel.sr.home>
Message-ID: <Pine.LNX.3.96.990225220259.9788B-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 Thu, 25 Feb 1999, Steve Ratcliffe wrote:

> 
> I've looked over the proposal and have some comments.  I like the idea
> of having the DIRECT priority to avoid copying of large events, while
> still being able to use queuing when appropriate.
> 
> First some general comments.
> 
> 1. I was going to suggest that a much stronger separation should be made
> between messages that would be used to communicate from an app to a
> patch manager and from a patch manager to a lowlevel driver.
> A low level driver would seldom want to know the patch
> name for example.
> 
> Of course, a separate patch manager would not be necessary, but the
> distinction should still be made, especially as I thought that it was
> a design goal of the sequencer that this could be done.
> 
> Conceptually there are two operations here (1) selecting the instrument,
> (2) doing whatever is needed to load that instrument (sysex, load
> patch/samples or whatever) The current ALLOC is a bit of a mixture of
> the two, and by separating them out, we could achieve one interface
> at the app level that maps on to different but standard interfaces to
> different kinds of equipment.
> 
> I've just seen the mail from Michael Ashton and I need
> to ask him some questions about this before saying any more.

Yes, I need more details, too.

> 2. I believe that the events should be separated out into request and
> reply events with their own argument types.  At present the arguments
> have input and output parameters mixed together.  Code would be clearer
> to have this separated. For example BEGIN:
> 
> SND_SEQ_EVENT_INSTR_BEGIN
>  typedef struct {
>  	long timeout;		/* zero = forever, otherwise timeout in ms */
>  } snd_seq_instrument_begin_t;
> 
> SND_SEQ_EVENT_INSTR_REPLY
>  /* Generic reply for when command has no data to return. */
>  typedef struct {
>  	int  result;
>  } snd_seq_instrument_reply_t;
> 
> For more complex cases you would have pairs such as
> 	SND_SEQ_EVENT_INSTR_LIST / SND_SEQ_EVENT_INSTR_LIST_REPLY.
> 	snd_seq_instrument_xxx_t and snd_seq_instrument_xxx_reply_t

This isn't bad idea. I updated the proposal. Could you and maybe others
look to it?

							Jaroslav

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


