Subject: Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
From: Juan Linietsky (coding_AT_reduz.com.ar)
Date: Sat Aug 17 2002 - 00:44:27 EEST
On Fri, 16 Aug 2002 14:14:02 -0400
Paul Davis <pbd_AT_op.net> wrote:
>
> >We know that the ideal way of doing this is having both the
> >sequencer and the softsynth access to the same exact clock for
> >reference, then having the audio app a predefined "delay in time"
> >consisting of the fragment size. After that it's a simple matter of
> >taking the current time before mixing a block, and mix internally
> >in smaller blocks while retrieving the event.
>
> this is how you handle incoming MIDI data,yes. but outgoing data
> is not a "simple matter" if you want to pre-queue the data and/or
> have a resolution that matches the MIDI data rate.
Well, outgoing is basically the same, you just send the timecode in
which you
want the event to be played (if future), or the actual time if you
want to play
it as soon as possible. Personally i think the incoming data is the
harder
thing to implement in code. ALSA sequencer seems to take care of
rearranging the order
of the events, but wont give you propert timing info/
>
> > I see this as something JACK could do
> >really well (take the timing before mixing a block and give it to
> >the processes, so even if one has to wait for the other according
> >to the graph, the sync with midi would be fine. I guess basically
> >this alone may justify giving jack midi superpowers, since we know
> >how important a good midi sync is.
>
> yes, but "MIDI sync" isn't defined. as i've explained before, there
> are two kinds:
>
> MIDI clock: a low resolution "tick"
> MIDI timecode: a low resolution positional reference
Yeah, midi clock and tick, but isnt that 10 milliseconds? That's
basically just 100mhz timing.
I was talking about something api-specific (which can become one of
the other two when going outside
the lib) which can work with UST.
>
> different kinds of devices use one or the other these, but rarely
> both. most drum machines and analog-ish sequencers use MIDI
> clock. most HDR systems and other digital audio systems use MTC.
>
> syncing to these two things is a very different task depending on
> which one you pick. MIDI clock tells you how fast you are moving,
> but doesn't necessarily contain any positional information. Of
> course, many systems may also generate MIDI song position data along
> with MIDI clock, just to confuse matters :)
>
Well, basically what i mean is having the high resolution clock as api
internal,
that doesnt necesarily mean ignoring other midi input/output sources,
but i dont think any of those really fullfill the task needed. This is
basically
because when managing external stuff (hardware) the devices can keep
up fine with
with realtime data, because there is no latency problems,
thing you do have with a softsynth/soundcard.
Well, personally I'd like to contribute to MIDI support for jack, i
think would
be great if it can handle midi, since it's already nice and
consistent.
How are you planning to do this? adding midi in/out ports besides the
audio ones?
I think if going that far, it would be nice at future, if it could
also add some sort of control
streams, such as start/stop/pause/set position,etc.
Cheers.
Juan Linietsky
This archive was generated by hypermail 2b28 : Sat Aug 17 2002 - 00:51:18 EEST