Subject: Re: [Alsa-devel] Re: [linux-audio-dev] midi events in jack callback / ALSA Sequencer
From: Frank van de Pol (fvdpol_AT_home.nl)
Date: Thu Aug 22 2002 - 02:48:11 EEST
On Wed, Aug 21, 2002 at 02:10:35AM +0100, Martijn Sipkema wrote:
> [...]
> > Within ALSA we have two priority queues, one for tick (bar,beat) scheduled
> > events, and one for clock (ns) scheduled events.
>
> As MIDI uses MIDI tick messages for time based sync and MIDI clock messages
> for tempo based sync I kind of feel the ALSA sequencer naming is a little
> confusing :)
I understand. OTOH the problem might also be introduced back in the 80's
when MIDI 1.0 spec was introduced. The "MIDI Clock" (0xf8) message was
introduced with only beat sync in mind. I believe the phrase 'tick' to
specify song position came from the standard midi file (SMF 1.0)
specification.
In fact the definitions in seq_event.h are less confusing:
/** Real-time data record */
typedef struct snd_seq_real_time {
unsigned int tv_sec; /**< seconds */
unsigned int tv_nsec; /**< nanoseconds */
} snd_seq_real_time_t;
/** (MIDI) Tick-time data record */
typedef unsigned int snd_seq_tick_time_t;
/** unioned time stamp */
typedef union snd_seq_timestamp {
snd_seq_tick_time_t tick; /**< tick-time */
struct snd_seq_real_time time; /**< real-time */
} snd_seq_timestamp_t;
>
> I don't want to support tempo (MIDI clock) scheduling in my MIDI API. This
> could be better handled in the application itself. Also, when slaved to MIDI
> clock
> it is no longer possible to send messages ahead of time, and not supporting
> this
> in the API makes that clear to the application programmer.
The concept of the public available alsa timing queues allow outboard
applications to schedule events in a tempo locked fashion. Think of
applications like drum machines, appegiators, tempo delay etc. Of course you
might be using one big monolithic (cubase?) sequencer application which does
do everything you need....
Compare it to an external (outboard) drum machine you're using since
programming a pattern in it so user friendly (hence you end up being more
creative), and sync that from your favorite sequencer which has the tempo
map for your song.
Of course all of this could be done without a queue which supports tempo
scheduling, but then you'll need to emit MIDI Clock events and rely on
immediate processing. In case a soft synth (or other potentially high
latency device) is triggered from the MIDI Clock you loose the ability to
correct for this.
[...]
> > Since especially for soft synths (but also for some -undocumented!- USB
> midi
> > interfaces, like Emagic AMT)
>
> Yes, I've repeatedly asked Emagic for documentation on their AMT protocol
> without success. :(
let them burn in peace....
[...]
> > When using events instead of midi bytes the merging is a no brainer
>
> I was planning on doing that, but even then there are issues with for
> example
> (N)RPNs.
>
> > leaves room for events not defined in midi spec).
>
> ...I'm not sure that is a good idea. What kind of events?
eg.
- system events like announcements of topology changes
- (N)RPNs as a 14 bit value instead of 2x 7bit
- SMF like meta data
- controls for current sequencer queue: tempo, position, etc.
to name a few
Cheers,
Frank.
-- +---- --- -- - - - - | Frank van de Pol -o) A-L-S-A | FvdPol_AT_home.nl /\\ Sounds good! | http://www.alsa-project.org _\_v | Linux - Why use Windows if we have doors available?
This archive was generated by hypermail 2b28 : Thu Aug 22 2002 - 02:45:53 EEST