[LAD] handling midi input in a jack app?

[Iain Duncan]

On Wed, Dec 28, 2011 at 12:04 PM, David Robillard <d at drobilla.net> wrote:

> On Wed, 2011-12-28 at 14:35 -0500, Paul Davis wrote:
> [...]
> > None of the other APIs that you've mentioned have this property, and
> > nor do any of the Windows MIDI APIs or CoreMIDI.
> >
> > this means that you face opposing issues depending on which API you
> > choose to use:
> >
> >   * if you use JACK:
> >         - MIDI data is trivially available to alter synthesis done
> > during process()
> >         - MIDI data needs to be moved across thread boundaries to be
> > useful outside of process()
> >
> >   * if you use ALSA, portmidi, rtmidi, CoreMIDI or anything else
> >        - MIDI data to be used for synthesis has to be moved across
> > thread boundaries
> >        - MIDI data used for other purposes can often be used in the
> > same thread it was received in,
> >                  though not always.
>
> Also, in both cases, there is a strong and precise correlation between
> MIDI time stamps and audio time for Jack MIDI, and not for the other
> APIs (which may be useful even if you do your processing in another
> thread).
>

Thanks for all the input everyone. It sounds like my best plan is for the
jack build to use jack midi in the audio process callback and send it to
the rest of the app over a ringbuffer. A few things I hope to achieve:

- keep all jack dependencies, with the exception of the jackringbuffer, in
one file, so far so good, the only use of jack right now is in main.cpp and
my wrapper class for the ring buffer. Everybody else communicates using an
internal message format, that is non-midi (on purpose, I want to make no
assumptions about anyone using midi).
- keep my porting task to a minimum in case I want to get this to run on an
non-jack platform ( Raspberry Pi for instance, no idea if jack runs on ARM?
)
- allow handing off input data to python processes so that users can easily
write algorithmic transforms. These *could* receive midi input directly, or
they could get midi input from jack:
  jack_midi_in -> passed to engine -> ringbuffered to nrt-controller -
controller maps to correct child process - socket/pipes/?? to python
processes

Basically, I want power/users to be able to write input plugins with a
really simple api in python, for cases where latency is not an issue
(step-sequencing). So I need to make sure that getting messages to Python
is as quick as possible, but also as reliable and manageable as possible.

Appreciate all the input everyone.
Iain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20111228/686858dc/attachment.html>