From alsa-devel-owner@alsa.jcu.cz  Thu May  7 10:38:37 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 KAA01658
	for <alsa-devel@jcu.cz>; Thu, 7 May 1998 10:37:33 +0200
Received: (qmail 18890 invoked from network); 7 May 1998 08:37:30 -0000
Received: from solomon.bath.ac.uk (HELO bath.ac.uk) (mmdf@138.38.32.1)
  by pat.bath.ac.uk with SMTP; 7 May 1998 08:37:30 -0000
Received: from tobi.bath.ac.uk by solomon.bath.ac.uk id aa04340;
          7 May 98 9:37 BST
Message-ID: <355172AA.4DAA@bath.ac.uk>
Date: Thu, 07 May 1998 09:36:58 +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> <354ECDA7.446B@bath.ac.uk> <355001F3.6C0AC16@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:
> 
> P.J.Leonard wrote:
> >
> > Antonio Larrosa wrote:
> > >
> > > 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.
> 
> Yes, but I thought that we were going to allow _inserting_ events, to do so,
> it's better to have time in ms. than ticks, because the driver doesn't have
> to make a substraction and multiplication (as you said), but just compare
> two ms. values . Well, this is not too much in favour of milliseconds, but
> I think it's easier to manage this way.

 Are you talking about attempting to deduce the real time of a future
event
in the queue ? This is a situation in which you need to look at all the
tempo changes and do some yucky stuff ?  In my system this never
happens.

> 
> Another good point at this is the possibility to synchronize midi music
> with wav audio (wav audio doesn't know anything about ticks and even less
> about tempo), or with frames of a movie.
> 
> Think of it as a common unit to make possible to synchronize everything.


 Let me expand what I think it should look like.


 There is a basic scheduler (BaseSched) which has 2 clients a tick based
client (TickQueue) and a real time client (RealQueue).

 As far as the BaseSched is concerned it only needs to know the time of
the next event on each
of these queues (also if a new event is inserted before the next event
it would need to
be informed). 

 TickQueue need not know anything about real time. Tempo changes are
done in the BaseSched
which simply uses it's current tempo to calculate the real time to the
next event in
the tick queue.


 This is how I imagine realTime sysnthesis using /dev/dsp (or whatever):

 The realTime synth uses the tickQueue to schedule the firing of notes
so in this respect it is
like a normal midi device. A note is fired when, the BaseSched executes
the callback on the
tickQueue with a current _realTIme_ stamp. At this point the realTime
sysnth can insert realTIme
control events onto the realTime queue. 


 The major design decision I have made with the above is that the
application is tightly
coupled with the kernel so there is no need feed much information into
the queue. 
I think that this is OK ?

 Comments ?

  cheers Paul.

