From alsa-devel-owner@alsa.jcu.cz  Tue May  5 10:29:26 1998
Received: from pat.bath.ac.uk (qmailr@pat.bath.ac.uk [138.38.32.2])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id KAA16764
	for <alsa-devel@jcu.cz>; Tue, 5 May 1998 10:28:59 +0200
Received: (qmail 12166 invoked from network); 5 May 1998 08:28:57 -0000
Received: from solomon.bath.ac.uk (HELO bath.ac.uk) (mmdf@138.38.32.1)
  by pat.bath.ac.uk with SMTP; 5 May 1998 08:28:57 -0000
Received: from tobi.bath.ac.uk by solomon.bath.ac.uk id aa20341;
          5 May 98 9:28 BST
Message-ID: <354ECDA7.446B@bath.ac.uk>
Date: Tue, 05 May 1998 09:28:23 +0100
From: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>
MIME-Version: 1.0
To: alsa-devel@jcu.cz
Subject: Re: New Sequencer core
References: <199804301605.SAA14889@obelix.fvdpol.inter.nl.net> <354CB5B9.53DA6144@arrakis.es>
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

Antonio Larrosa wrote:
> 
> 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.

 I am getting a bit confused, I thought the idea was to implement a
queue with event times expressed in ticks. The queue simply orders
events.
You calculate the (real) time of the next event from the tick difference
between the event
just played and the next event multiplied by the current
tempo. The only recalculation for a tempo change is the time to the next
event. 
This is how I do it in my sequencer and it works fine.


 cheers Paul.

