From alsa-devel-owner@alsa.jcu.cz  Thu May 14 10:20:40 1998
Received: from entry.jcu.cz (perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id KAA31269;
	Thu, 14 May 1998 10:20:37 +0200
Date: Thu, 14 May 1998 10:20:37 +0200 (MET DST)
From: Jaroslav Kysela <perex@jcu.cz>
To: Frank van de Pol <F.K.W.van.de.Pol@inter.nl.net>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: Sequencer core draft
In-Reply-To: <199805132155.XAA00930@obelix.fvdpol.inter.nl.net>
Message-ID: <Pine.LNX.3.96.980514101555.27690C-100000@entry.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Wed, 13 May 1998, Frank van de Pol wrote:

> 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. 

It's true. If you look to end of document (interface proposal):

  union {
    unsigned int tick;          /* 0 - 2^32 */
    struct {
      unsigned int sec;         /* seconds */
      unsigned short usec10;    /* microseconds / 10 */
    } t;
    /* maybe add MTC? */
  } timestamp;

Please, correct this...

> "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.
>                                                ~~~~~~~~~~~~~~~~~~~

OK. I agree... Next correction...

					Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic


