From alsa-devel-owner@alsa.jcu.cz  Sun Feb 28 14:18:08 1999
Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id OAA07300
	for <alsa-devel@alsa.jcu.cz>; Sun, 28 Feb 1999 14:16:40 +0100
Received: from [212.238.75.184] (helo=obelix.vande-pol.demon.nl)
	by post.mail.nl.demon.net with esmtp (Exim 2.02 #1)
	id 10H65G-0001EP-00
	for alsa-devel@alsa.jcu.cz; Sun, 28 Feb 1999 13:16:38 +0000
Received: (from frank@localhost)
	by obelix.vande-pol.demon.nl (8.8.7/8.8.7) id XAA16366
	for alsa-devel@alsa.jcu.cz; Sat, 27 Feb 1999 23:02:50 +0100
From: Frank van de Pol <frank@vande-pol.demon.nl>
Message-Id: <199902272202.XAA16366@obelix.vande-pol.demon.nl>
Subject: Re: More stuff about the sequencer [was Re: Instrument abstract layer]
To: alsa-devel@alsa.jcu.cz
Date: Sat, 27 Feb 1999 23:02:49 +0100 (CET)
In-Reply-To: <199902270908.EAA10582@camel8.mindspring.com> from "Data" at Feb 27, 99 03:08:45 am
Content-Type: text
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list


<nice intro about midi's strengths removed>

> 
> Two things primarily bug me about the way the sequencer is set up.  I've 
> mentioned these before.  The first has to do with sync: sync troubles 
> being the thing that led me to terrorise this mailing list to begin with. 
>  I would like the sequencer to talk SMPTE, for starters.  But that's a 
> small matter.

If the timer granularity and jitter is good enough this will indeed be as
you say 'small matter'. As the sequencer works internally with high
resolution time and song position it is fairly trivial to make it speak
SMPTE (or MTC) and listen MIDI Clock at the same time.

[any sync source] -> [seq timer] -> [any sync dest]

To guarantee even bit timing of MTC transmission is a problem however (as
discussed earlier).

> 
> The thing that _really_ bugs me is the event types, and the event 
> structure.  Actually, that's pretty much it.  I think most of the rest of 
> the sequencer is brilliantly done.  But there are way too many kinds of 
> events there, I think.

let's see...
 
> Now, the first rule of computer science is 'never reinvent the wheel'; 
> and since we already have a fine and versatile format for passing events 
> from point to point (MIDI), I think we should use it.  That is to say, I 
> see no reason to define arbitrary constants for note + duration, note on, 
> note off, program change, registered parameter number, ignite explosive, 
> etc. etc. when that sort of thing is covered already by the MIDI spec.
>

The ALSA sequencer was originally designed with the MIDI spec in mind. All
the events are MIDI like (as you noticed), and the sequencer kernel handles
scheduling and routing of these events between multiple tasks - I named
these 'sequencer clients' (client to the sequencer core).

..
 
> Why not instead do away with the redundant event types - e.g. note-on, 
> note-off, program change - and replace them all with one: say, 
> ALSA_SEQ_MIDI_MSG or something.  The event structure would have, say, a 
> sixteen-byte space for storing MIDI bytes.  A driver client would then 
> merely copy the MIDI bytes into the event, stamp it & go.  Much quicker.

There is a little problem with the approach you propose: If you are only
considering one stream (eg. only one sending application) you can use a
simple FIFO for event queue and therefore be sure that all the events are
processed in the same order as they have been submitted. But since the
design goal of ALSA sequencer is to support MULTIPLE clients we are using a
priority queue and we therefore have to take into account that events for
other clients might be processed in between. To prevent problems with this
ALSA supports events which would otherwise consist of multiple "MIDI 1.0
events". The MIDI 1.0 spec does not have this problem because it is only
refering to the data traveling over the serial MIDI line.

In other situations the mixup would not give problems, but an event is
broken down in multiple MIDI 'messages' because the 3 bytes just don't have
enough bits to store the information.

Examples: 
- event for SysEx (variable length), you don't want mixup with other streams!
- controller events that would otherwise consist of multiple events (eg.
  RPN/NRPN)	


But you are right, we do not need to provide unnessesary events. We better
keep it simple, or lean & mean :-).

One event class that might be a good example of one that might be trimmed
down are the note events. There is a note on, note off, and note (with
length) specified. The latter could be removed if we want to. This event
type is only for convenience of the application - it could also write out a
note_on and and note_off event at the same time.


> 
> For sys-ex messages and the like, there are two ways to handle things.  
> There's already a provision for variable-length packets; this would work 
> fine for large sys-ex dumps and such.  Another way (though a bit less 
> efficient) would be to define another message, called maybe 
> ALSA_SEQ_MIDI_RAW.  Where ALSA_SEQ_MIDI_MSG would be guaranteed to have 
> exactly one complete MIDI message in it, ALSA_SEQ_MIDI_RAW would not be 
> guaranteed to have anything meaningful at all.  A driver client could 
> dump incoming bytes into these and mindlessly ship them off.  Fast and 
> dirty - possibly useful too.  To keep them sorted, the timestamp would do 
> nicely.

Not with other streams submitting events at the same time! The use of the
larger high-level events is to group the logical events.

--------- and now over to some instrument discussion ---------

> 
> they are are controller messages and program changes.  Clients could 
> fuddle with the details.  Besides, the sequencer core is not in general 
> supposed to have too much knowledge of what exactly is in those packets 
> it's shovelling in and out.  Its job should be similar to that of an 
> overnight postal service, in my view: move the stuff from here to there, 
> and quickly.

yep, the sequencer only does deliver events at their scheduled time (or song
position), and routes these events between the clients.

> 
> So the 'instrument layer' could be just a sequencer client that has a 
> special friendship with the sound drivers; or some library that can talk 
> program changes, soundfonts, sample dumps _and_ sysex; or what-have-you, 
> but the sequencer core needn't concern itself with it.  Although I 
> suppose that was the idea all along :)

Something along those lines I think. For an instrument we would need a
sequencer client to handle the pgm changes etc. This client needs to know
about the (possibly ugly) details of the specific instrument. It will access
the instrument device though the instrument layer.

> 
> AIFFs are an excellent format - WAVs are MicroSloth's bastardised version 
> of AIFFs - and are quite capable of representing all of the information 
> I've seen discussed.  AIFFs can, in theory, hold multiple samples, loop 
> points, key maps, and all sorts of goodies.  A layer which could 'load' 
> such AIFFs into soundcards would not be short on power.
Agreed, but the wav format has a more intel friendly byte order.


> 
> Anyway I'll be gutting and rewiring fundamental parts of the sequencer 
> this weekend, and will deliver a true and accurate account of my 
> adventures at such time as I can manage to.  And sorry about rambling so 
> much - it's quite late, and I'm _really_ tired :)

Can you update me of your plans? 


Regards,
Frank.


