From alsa-devel-owner@alsa.jcu.cz  Sat Oct 31 15:31:50 1998
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 PAA29681;
	Sat, 31 Oct 1998 15:31:32 +0100
Date: Sat, 31 Oct 1998 15:31:32 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Paul Barton-Davis <pbd@op.net>
cc: alsa-devel@jcu.cz
Subject: Re: ALSA sequencer and synth control (Was Re: ALSA + AWE32) 
In-Reply-To: <199810311407.JAA08613@renoir.op.net>
Message-ID: <Pine.LNX.3.96.981031151930.30998B-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 Sat, 31 Oct 1998, Paul Barton-Davis wrote:

> Jaroslav writes:
> 
> >Maybe I didn't write about this instrument downloading before, but I'm
> >thinking that ALSA sequencer must be able to do both methods:
> >
> >  - application requests some MIDI sample, this application doesn't
> >    know anything about instrument downloading, it is written for
> >    standard MIDI interface, thus downloading of MIDI instruments must
> >    be handled in sequencer in two ways: preload complete instrument set
> >    or load on demand
> >  - application knowns about instrument interface and uses it for
> >    instrument requests (good for MOD players and MIDI players and
> >    for all situations where instruments should be downloaded before
> >    playing - including live playback)
> 
> I'm sorry if I'm going over old ground again, but could you please
> explain why a "sequencer" has a role to play in this kind of operation?
> My understanding of the term "sequencer" suggests a role in providing
> accurate timing of events, and not "a general purpose interface for
> manipulating a synthesizer". 

OK. My fault. In my text I mean by word "sequencer" interface which is
visible from application... Load on demand or instrumet set preloading
should be done from sequencer client, of course.. Sequencer client should
use only sequencer events and sequencer router for deliver information
between lowlevel driver to music application or instrument manager... This
type of information shouldn't touch real-time queue of events. I didn't
still see any reason why we need create next interface between kernel /
user boundary. Frank designed very good event router for this...

> >No, please, we can do effective caching of instruments if possible. In
> >driver MUST be some kind of list of instruments to handle MIDI program
> >change and other instrument change requests...
> 
> Well, now I'm beginning to understand why we see things so
> differently. I suspect you've worked mostly with soundcards that don't
> support MIDI control of their synth in hardware, and require driver
> support to convert MIDI requests into some h/w specific operations.
> 
> By contrast, I've worked mostly with soundcards (the TB WaveFront
> series, the TB Pinnacle, etc) that do support MIDI control of the
> synth in hardware (or firmware), and thus the whole idea of having to
> handle program change requests just doesn't exist: the synth does this
> all by itself. The device drivers for these cards don't need to manage
> instrument lists or anything like that. They do, however, need to
> provide a mechanism for sending down new patches "on demand" as you
> put it.
> 
> Put it this way: if you look at a standard MIDI file, and discover
> that it uses programs 3, 56, and 99, then on a MIDI-controlled synth,
> you need to do nothing at all. The synth already (if its been booted
> correctly) has the relevant programs set up, and if it doesn't, there
> is no way you can infer what you should do (except maybe "reset to
> General MIDI").
> 
> By contrast, as I understand it, with the GUS, or the OPL FM synths or
> similar non-MIDI devices, you get to look at the required program
> changes, and say "oh, we're going to need to load instruments for
> these programs, and we know which instruments they are since we
> provide the MIDI interface layer". With such a device, the instrument
> lists and so forth all make sense.

Yes, I'm working mainly with GUSes, thus I'm solving trouble with these
instrument issues.

> This is a pretty big difference, I think, that leads to quite
> different approaches.

Yes, but these things will be handled in sequencer client (lowlevel
driver for synthesizer). This driver should know what could be done with
hardware. Programmers with intelligent hardware (like you mentioned TB
soundcards), shouldn't implement any load on demand interface, why if
hardware does this job?

OK. Looks we are on same frequency now ;-))

						Jaroslav

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


