From alsa-devel-owner@alsa.jcu.cz  Mon May  4 07:34:08 1998
Received: from mx1.landsraad.net (chusuk.arrakis.es [195.5.65.35])
	by marvin.jcu.cz (8.8.8/8.8.8) with ESMTP id HAA19486
	for <alsa-devel@jcu.cz>; Mon, 4 May 1998 07:34:01 +0200
Received: from arrakis.es (antonio@ig-178.arrakis.es [195.5.76.178]) by mx1.landsraad.net (8.8.6/8.7.3) with ESMTP id HAA01946 for <alsa-devel@jcu.cz>; Mon, 4 May 1998 07:32:54 +0200 (MET DST)
Message-ID: <354CB5B9.53DA6144@arrakis.es>
Date: Sun, 03 May 1998 18:21:46 +0000
From: Antonio Larrosa <antlarr@arrakis.es>
MIME-Version: 1.0
To: alsa-devel@jcu.cz
Subject: Re: New Sequencer core
References: <199804301605.SAA14889@obelix.fvdpol.inter.nl.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

Frank van de Pol wrote:
> 
> I also had some thoughts in this issue. When implementing a priority queue,
> we need to be able to compare time stamps of events. If there is a constant
> tempo, that can easily be done. But when a tempo is changed, the number of
> clock ticks (ppq) per second changes, and events in the queue will not have
> correct ordering anymore. To avoid this problem, only one type of timestamp
> is needed. We have basicly two options to choose from:
> 
> 1) real/clock-time, expressed in seconds (or fractions of it of course,
>    eg. ms or us.
> 
> 2) songposition, expressed in clock ticks, which are related to the tempo
>   the song is playing. for an internal resolution of eg. 1920 PPQ (parts per
>   quarter noter), and a tempo of 135 BPM, there are 1920*135=259200 clock ticks
>   per minute = 4320 ticks per second.
> 
> Because of the specific character of music (ie. it has tempo, groove etc.)
> the second one is prefered. Conversion between these two types is trivial
> once the currently active tempo and timestamp (in both units!) of last tempo
> change is known.

I'm not too sure of this being a good solution . A ms. is a time unit that
never changes (not aplying theorical physics :-)), but controlling clock ticks
is very tricky when there are several time changes . 
Suppose this situation :

Music starts playing, you place a change tempo event at tick 5000 . Before it
is processed, you place another change tempo event at tick 10000 .
Now, what is tick 10000 ? , is the 10000 ticks ms. calculated using the
current tempo ?, or you are going to run over the list of queued events to
take care of that tempo change that is at tick 5000 ?

That's why I think that time should be expressed in ms. or us. 

[cut]

> To make life a little more easy, we can try to standardize the internal
> synths to GM and perhaps extend it with some of the XG features.
[cut] 
> I think a AWE32 can be seen as: "generic + AWE32 specials". The GUS can be
> seend as "generic + GUS specials". A standalone XG module (eg. Yamaha MU90R)
> is "generic + MU90R specials". If a AWE32 specific song is played to another
> device, eg. GUS, the latter will not understand the specials and just
> discard the extra data; the generic events will be played though

I agree completely in both points.

However I have to note something. In the initial message  (sorry, not quoted),
you told something about multiple clients being able to open the same
device r/w, so that many applications can use midi output at the same time.

I think this is not desirable. No, don't get me wrong, of course many
applications should be able to open midi devices, but I think that it would
be better done with a midi server than in kernel mode .
Everything that could be outside the kernel is better out than in . Perhaps
we could distribute the midi server with the driver, but not inside it .

Another argument on this is that the driver should be kept the simpler we
(Jaroslav) can make it :-)

Greetings,

-- 
Antonio Larrosa Jimenez
antlarr@arrakis.es
Personal Homepage : http://www.arrakis.es/~rlarrosa
Klein bottles for rent -- inquire within.



