From alsa-devel-owner@alsa.jcu.cz  Tue May 12 10:53:43 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 KAA16344
	for <alsa-devel@jcu.cz>; Tue, 12 May 1998 10:53:14 +0200
Received: (qmail 7792 invoked from network); 12 May 1998 08:53:08 -0000
Received: from solomon.bath.ac.uk (HELO bath.ac.uk) (mmdf@138.38.32.1)
  by pat.bath.ac.uk with SMTP; 12 May 1998 08:53:08 -0000
Received: from tobi.bath.ac.uk by solomon.bath.ac.uk id aa27056;
          12 May 98 9:53 BST
Message-ID: <35580DDB.41C6@bath.ac.uk>
Date: Tue, 12 May 1998 09:52:43 +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: Timing
References: <199805112059.WAA24436@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:

> Thanks guys for all the response I got on my proposal. It appears that there
> are some mixed ideas about the timing / timestamping of events. Perhaps this
> will help (or not...).

[snip]

 The snipped stuff looked very nice to me. 


> As the 'clock' can both send and receive timing information, the possibility
> to synchronise multiple computers is still open. <dream-mode> This way we
> can even build whole clusters of music producing Linux computers. :-)
> </dream-mode>

 Excellent :-)

<KERNEL IGNORANCE MODE ON>

 How do the kernel modules talk to each other. 

<KERNEL IGNORANCE MODE OFF>


 I would just like to check that you see no problems with my
current system of doing things.

 The timing software will (somehow) see an object based on the following
absract class
(JBeat can be thought of as a tick).

class JSequencer
{
public:
  virtual ~JSequencer(){;}

  // Time of next event (for peeking);
  virtual JBeat nextBeat()=0;

  // warp drive to when and return time of next event
  virtual JBeat gotoBeat(const JBeat &when)=0;
  
  // execute current event and return time of next event
  virtual JBeat execute()=0;

};


 So in my case I would wrap a sequencer up thus,

class JTimerClient
{
public:
  virtual void callBack(???)=0;
};


an implementation would be

AJTimerClient::AJTimerClient(JSequencer *sequncer,JTimer timer)
:_sequencer(seqeuncer),_timer(timer)
{

   _timer->requestCallBackAt(this,_sequencer->nextBeat());

}

void 
AJTimerClient::callback( ??? ) 
{
   JBeat beat = _seqeuncer->execute();
   _timer->requestCallBackAt(_sequencer->nextBeat());
}


 My timer looks like (this is the subset of functionality I will need).


class JTimer
{
public:
  virtual ~JTimer(){}
  virtual void   setNow(const JBeat &time)=0; 
  virtual void   setTempo(double bpm)=0;
  virtual double tempo() const =0;
  virtual JBeat  beatNow() const =0;
  virtual void   stop()=0;
  virtual void   start()=0;
  virtual bool   isStoped()const =0;
  virtual void   requestCallBackAt(JTimerClient *,JBeat)=0;
};

 
 Since I only ever have one event in my timing queue my Timer is quite
simple.

 I plan to make all this stuff live in kernel land but I am curious
about how the
callback requests and actual callbacks are communicated between modules.


  cheers Paul.

