From alsa-devel-owner@alsa.jcu.cz  Sun May 10 10:05:18 1998
Received: from mx1.landsraad.net (chusuk.arrakis.es [195.5.65.35])
	by marvin.jcu.cz (8.8.8/8.8.8) with ESMTP id KAA28528
	for <alsa-devel@jcu.cz>; Sun, 10 May 1998 10:05:04 +0200
Received: from arrakis.es (antonio@ia-157.arrakis.es [195.5.70.157]) by mx1.landsraad.net (8.8.6/8.7.3) with ESMTP id KAA32227 for <alsa-devel@jcu.cz>; Sun, 10 May 1998 10:03:53 +0200 (MET DST)
Message-ID: <35555F2E.50CCD9EE@arrakis.es>
Date: Sun, 10 May 1998 08:02:54 +0000
From: Antonio Larrosa <antlarr@arrakis.es>
MIME-Version: 1.0
To: alsa-devel@jcu.cz
Subject: Re: New Sequencer core
References: <199805042150.XAA26909@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:
> 
> Antonio Larrosa wrote:
> >
> 
> When using the songposition notation, a tick is and keeps being a fraction a
> a bar; changing the tempo while playing, will just result in a different
> number of ticks per second. Events (eg. hihat pattern) that is queued with
> the 'old' tempo will then follow the new tempo while staying in groove. The
> tick->second calculation has only to be performed for the event that is to
> be dequeued. If a time notation (in seconds) was used instead, we indeed
> should have to run over the list of queued events.
> 
> If multiple tempo changes are queued, like in your example, that will work
> out fine as I'll illustate later.

Well, yes it would work, I know that ticks are well defined and all that, 
but I think that ms. are more ... "intuitive" :-)

In fact, you are right that there are not many difference between using
one or other unit (and we all be probably using ticks finally), but as I
said in another posting, ms. is a more general time unit that can be used
to synchronize many things that don't have a 'tempo' (like animations, or
audio output). Anyway we can always convert one unit to another, but
why using a conversion when we can always use the same unit ?

> Both methods have their advantages and disadvantages. For note events the
> tempo method is really the best (less trouble for tempo changes). But for
> events that we want to fire at an exact time stamp (eg. synced to sample
> playback!), we better have time stamps in seconds (or ms, or us). If there
> are no (zero, 0) tempo changes, it even doesn't matter wich method to use!

Yes you are right.

> 
> To overcome this compromise, we can use two parallel queues, one for the
> real-time (seconds), and one for the song position (ticks).

I don't think this is the solution, we should only have one queue, (with
the preferred unit) allowing the programmer to use ms and ticks and just
convert (internally) the input unit to the one used in the queue.

Well, in fact perhaps we should have one queue for each output client (with
output client I refer to any client which is waiting to receive data, as are
device drivers, or softmixers like timidity). This would allow us to have
different tempo in each of them. (with ms. we don't have this problem, and
would be fine just one queue :-)


> 
> Regarding tempo calculations:
> 
[Some nice and interesting explanations cut]
> 
> Is there perhaps some subtile issue I overlooked or misunderstood from your
> posting?
No :-)

I'm not against using ticks, just thought that ms. are a better approach to
this task, but as it seems that ticks are more accepted, then 
let's use ticks !

> > However I have to note something. In the initial message  (sorry, not quoted),
> > you told something about multiple clients being able to open the same
> > device r/w, so that many applications can use midi output at the same time.
> 
> Perhaps some more explanation is needed to clarify my idea (which is
> completely different from OSS's model):

The "completely different from OSS's model" is a good argument :-), you 
have convinced me :-)

> 
> "Client" in my proposal is just _anything_ that communicates with the
> sequencer core. The sequencer core is nothing more than a foundation that
> does nothing but _queueing_ and _routing messages_ between clients. These
> clients can either reside in userland or kernel land, and can be
> applications like sequencers, midi players etc., or can be device drivers
> that play sounds (MIDI, synths, soft synths) or have inputs (MIDI keyboards,
> drums etc.), or simply 'massage' the data and act as filters, mappers.

That is very good, it seems that I messed up some things, in fact it is
similar to something which I thought of doing in a midi server I was
going to do (before knowing of the ALSA project).

I thought of virtual midi input and output devices, so a program can send
midi events with the same API to a device, or doing the role of a virtual
midi input device, so that another program can connect to it and receive
the events, just as they connect to a midi input port to receive the
events of an external keyboard.

A virtual midi output device could then be used to simulate a midi device
(timidity in mind :-)). The API would be the same as of a program that
receives data from a midi input port.

But your idea is something that allows the same things and even more.

> 
> In the above simple example for a MIDI player, one can add a additional
> client that allows for instance to change the pitch of certain note events
> (only specific channels). All this imaginary client does is simply shift the
> pitch of the received data by 2 semi-tones, and send it to the MIDI output.
> If now the MIDI player does not send it's events directly to the MIDI outpu,
> but sends it to this 'pitchshift' client; we get to hear the same song, now
> with a different pitch. Okay you'll think; whats the use for this pitch
> shifter? Not much I think, but it illustates one big strenght of this

Not much ?, that is the basic of a midi mapper !
Have you seen KMid ?, I developed it because I needed a midi player
with a midi mapper in Linux (kmid is the only I know that can do it) with
your proposed design, every program can use the same midi mapper (which
could be put in a client) without changing the source code.

The concept of adding clients would be great, but I think it can be difficult
to pass these events to clients which are in fact other applications.
Do you know of any method of doing this ?
Should we use shared memory, or sockets to communicate the clients
with the server (driver) ? I would preffer sockets, but then, does
anyone know if it's possible to sleep while waiting for data and
awake the process when data is available ?

> 
> The presencee of a priority queue instead of a FIFO allow us to add new
> events to be played now or shortly to an queue with events that are already
> queued for the future. No need to mess with the out-of-band ioctl's.

So it's (will be) far better than OSS, I like specially the priority queue
(curious name) much more than the FIFO


> >
> > Another argument on this is that the driver should be kept the simpler we
> > (Jaroslav) can make it :-)
> 
> Fully agreed!!! That's why the sequencer core only has a few queue's and a
> event router.
> 
> - All the ugly hardware specific details that make life complicated can go
>   into the parts where they belong: the device specific drivers.
> 
> - No need to keep adding new functionality (like midi thru etc.) to the
>   sequencer because the sequencer won't do more than sequencing and routing
>   events from one client to another. All the bells and whistles ("I want to
>   have it make coffee") can put in clients.
> 
> - OSS compatibility can be guaranteed by creating a client with /dev/music
>   and /dev/sequencer interface that simply maps the OSS events to ALSA events.
>   And perhaps even a client that calls the OSS to perform/play ALSA events
>   (use OSS as low-level I/O).
No please !, we have enough with having to make an OSS-compatible layer to the
driver, why should we also do the OSS driver ALSA-compatible ?
(even if it could be done ? :-))

> 
> - The concept can be quite clean and easy so that is would not be a problem
>   to implement it. (Done by me or other volunteers, then Jaroslav and others
>   can keep concentrating on the low-level hardware driver where the ALSA
>   still needs a bunch off.)
> 
> Thanks for you response, this means that at least some people take the
> trouble to go though that long story of me. I can understand that it's hard

Yes, it takes time, but we do read your stories ;-)

> to understand my ideas because they are not in the line of the OSS approach
> to sequencing all Linux developers are used to, and have some fundamentally
> different approach. My story is also not complete, I have more 'blurry
> ideas' on this subject, and could talk for hours on this idea (I did!), but
> putting it down in a way that understands is not without trouble (not an
> easy task, to translate Brain->Email :-) Perhaps reading other (recent)
> postings on this subject might help.
> 
> Let me know what you think, and what parts are not clear.

As I've said, I didn't understood your "clients" mechanism at first, but
they are now well explained (and I think now I understand :-))

I think that the design is now more or less done, with as many
queues as output devices to allow having different tempos, each queue
measured in ticks and allowing the programmer to insert events by giving
the time of the event in ticks or in ms. 
Anyway I would like to know how to implement the clients communications.

> BTW: for your kmid application (your posting 2 weeks ago whas for me the
> trigger to put my idea down; I have this in my head for a long time) you
> said you wanted to have real-time volume changes.
> 
> That's very easy with this new architecture (ALSA = Advanced Linux Sequencing
> Architecture):
> 
> - You can simply enqueue volume change events (controller data) with a
>   timestamp of _now_.
This is exactly what I have always dreamt of :-)

Best wishes,

-- 
Antonio Larrosa Jimenez
antlarr@arrakis.es
Personal Homepage : http://www.arrakis.es/~rlarrosa
Klein bottles for rent -- inquire within.


