Re: Re: [linux-audio-dev] midi events in jack callback / ALSA Sequencer

["Martijn Sipkema" <msipkema@sipkema-digital.com>]

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

No, I like the concept of a lot of small applications. And I want those to
be able
to sync (slave) to MIDI clock.

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

For this, the sequencer is master and just sends the MIDI messages including
MIDI clock to a scheduled UST queue. Timing will be as good as is possible
with a MIDI clock slaved external instrument.

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

Isn't that what will eventually happen using a tempo queue also?

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

I don't see how having a MIDI clock scheduled tree will help. When slaving
to MIDI clock you cannot know when a future beat will occur, so a software
synth salved to MIDI clock will behave just like a software synth in real
time,
i.e. it cannot compensate for its own latency. However, if the master sends
the MIDI clock messages ahead of time, and for a sequencer application this
is exactly what it would do, then the software synth can compensate for its
latency and might even interpolate between clocks. This would not be
possible
having a tempo based queue since the UST of the messages in that queue are
not known in advance, right?

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

I'm thinking of handling these out-of-band.

> - (N)RPNs as a 14 bit value instead of 2x 7bit

This I would like to solve by having the posibility of sending a short
sequence
of MIDI messages that are guaranteed to not be interleaved, e.g. 4 messages,
two for setting the current (N)RPN and 2 for setting its value.

> - SMF like meta data

Is it really necessary to support karaoke :)

> - controls for current sequencer queue: tempo, position, etc.

These aren't needed when a tempo queue isn't used.

I think it is important to keep the API as simple as possible.

--martijn





-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390