16 Feb
2013
16 Feb
'13
9:58 a.m.
----- Mail original -----
De : M Donalies <ingeniousnebbish(a)cox.net>
À : linux-audio-dev(a)lists.linuxaudio.org
Cc :
Envoyé le : Vendredi 15 février 2013 17h23
Objet : [LAD] making sense of Jack MIDI; or, is this an appropriate use for Jack?
Using Alsa sequencer, I put events on a queue with a
time and Alsa takes care
of the rest. If I just use the Jack midi api, how much of this process can
Jack do? I'm assuming "not much," since all the apps that I've
looked at the
source of use the Alsa sequencer.
I've tried to do that move from an ALSA backend to a JACK MIDI one in QMidiArp, and
used vectors as a queue for event timings. It doesn't support tempo changes on the fly
and I even didn't think about how to implement this.
The ALSA sequencer queue has a very convenient features called 'echo events', that
is you can tell the sequencer to call back your program at a distinct time in the future,
do calculations and place back notes into the queue at that time.
JACK calls the processing thread regularly and it is up to you to watch when it's time
to respond with events. So in QMidiArp I tried to reproduce this echo event mechanism
using an additional 'echo queue' vector.
I don't pretend that this is a good solution (neither its implementation) but for the
purposes of QMidiArp as a rather simple sequencer it does the job quite well.
And I agree with Pedro that the need to be careful about what
functions you call within the JACK process (rt) thread was quite a
challenge, and it required some substantial changes to the whole
program, gui etc...So if you set up the entire program for JACK (which admittedly should
be the case for MIDI+AUDIO apps) right
from the beginning this is already more straight forward, but moving a
program from ALSA to JACK MIDI is not.
It would be really nice if some future JACK version had a built-in sequencer queue, and
some rumors say there are or have been plans?
Regards
Frank