From alsa-devel-owner@alsa.jcu.cz  Thu May 14 00:01:57 1998
Received: from obelix.fvdpol.inter.nl.net (frank@bd99-11.Breda.NL.net [193.79.246.236])
	by marvin.jcu.cz (8.8.8/8.8.8) with ESMTP id AAA23557
	for <alsa-devel@jcu.cz>; Thu, 14 May 1998 00:00:15 +0200
Received: (from frank@localhost) by obelix.fvdpol.inter.nl.net (8.8.7/8.7.3) id XAA00930 for alsa-devel@jcu.cz; Wed, 13 May 1998 23:55:39 +0200
From: Frank van de Pol <F.K.W.van.de.Pol@Inter.NL.net>
Message-Id: <199805132155.XAA00930@obelix.fvdpol.inter.nl.net>
Subject: Re: Sequencer core draft
To: alsa-devel@jcu.cz
Date: Wed, 13 May 1998 23:55:39 +0200 (MET DST)
In-Reply-To: <Pine.LNX.3.96.980511132819.2283I-100000@entry.jcu.cz> from "Jaroslav Kysela" at May 11, 98 02:58:26 pm
Content-Type: text
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Jaroslav Kysela wrote:
> 
> Hi,
> 
> 	I uploaded modified draft from Frank van de Pol to 
> 
> 		http://alsa.jcu.cz/api/seq.txt
> 
> There are some next ideas and corrections for first draft. Draft should
> contains some bugs - sorry. It would be nice if Frank (and other)
> extends/corrects this document. Please, ideas how to solve instruments

Hi Jaroslav,

I didn't find time to go through the v0.02 document in great detail yet. My
first impression was that it looked quite good. I'm glad you understand the
concept (and possibilities) of the client architecture :-) 

One point I noticed: you removed the ability to support the tick timestamps
(and only use real-time). I think we should put it back in. 

The sequencer core (or a sequencer core) needs to know the clock-time for
syncing with all time based synchronisation methods and fireing events at
specific times or intervals. ==> We should support real-time timestamps.

But the sequencer core should also allow synchronisation between
applications, say a sequencer application and a drum machine (or drum
sequencer). For this it is best to have a sequencer core that supports tempo
and tick timestamps. If there is no such support all the applications will
have to keep their own tempo/tick to real-time conversion, and have to
communicate tempo changes. That will give a mess! Other reason is that for
syncing to MIDI clock, the tempo will have to be adjusted quite
often/continiously. This will result in having to fix (us) timestamps in the
real-time queue. But the sequencer core can't because it has no clue of
tempo, and the applications/clients can't because the events are already
scheduled. Same applies for multiple playback clients that want to use the
same tempo. ==> We should support tick timestamps and tempo.

There is no good reason I can think why we should not support both types (at
the same time).                                               ~~~~~~~~~~

What's your reason why you want to support only the real-time events?


Other issue (quoted from v0.02 proposal):

"Timings should be done with time separators which should contains time
between tick in us (between event blocks) - relative or absolute timestamp. This
will allow to application do some special things like effects inside MIDI tick
etc.. "

Please no. Time should not be stored relative to previous event. That's the
way the OSS works, but when using a priority queue that will be a real pain
in the ass:

	- we can't use standard prioQ algorithm because we don't have a key
          for ordering the events. The key (timestamp) can only be found in
          the _previous_ event is known, (and the event before that one etc.
          etc. etc. ). To get the exact timestamp we'll have to traverse all
          events.

	- If a event with a timestamp 'more recent than the oldest timestamp
          that is already in the queue' is inserted; it will be a very very
          very ugly and time consuming (order n) task to insert the new
          event at the right time.

	- this new event needs to have an absolute timestamp because if it
	  is relatative to, to which other event is it relative?

When using a simple FIFO this delta timestamps are no problem, but for this
architecture I can see no other way than using absolute timestamps.
                                               ~~~~~~~~~~~~~~~~~~~

If there is a need to, we could support delta timestamp to the clients (or
just from within the library) by keeping track of the last event send by
that client but why should be do??? With this delta stuff we loose the
ability to schedule (say volume changes) at timestamp _NOW_ or _SOON_
(supporting negative delta's could help but then we are fighting the delta's
and had better used absolute timestamps in the applicatione.)

I do however see use for two type of timestamps (either real-time or tick of
course):
	- absolute time (since start of sequencer (should support
          start/stop!))
	- timestamps relative to current time. (eg. execute over 100 ms,
          very usefull for making periodic callbacks.)

Regards,

Frank.

========================---------------->
#define NAME    "Frank van de Pol"     
#define ADDRESS "mgr. Nelislaan 10"  
#define CITY    "4741 AB Hoeven"    
#define COUNTRY "The Netherlands"  
#define EMAIL   "F.K.W.van.de.Pol@inter.NL.net     -o)
                                                   /\\
Linux - Why use Windows, since there is a door?   _\_v

