On Wed, 2011-12-28 at 10:46 -0800, Iain Duncan wrote: Alsa ports will show up in jack if you use the -X option to the alsa driver, or the separate application a2jmidid. I recommend using the Jack API entirely. -dr

On Wed, Dec 28, 2011 at 11:35 AM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote: Thanks for that explanation. In my case, I believe I will have two kinds of midi input, one that would be best served by the first set of tradeoffs and the other the second, namely, the user may be playing a synth, or the midi input may be used to control the app. Is it reasonable to use both jack midi and a non-jack midi api in the same app with different midi input devices? thanks Iain

On Wed, Dec 28, 2011 at 1:46 PM, Iain Duncan &lt;iainduncanlists(a)gmail.com&gt; wrote: Dave mentioned that you want to use the Jack API entirely, I think he probably meant that on Linux you can safely rely in having an access method that just takes MIDI from Jack - then converts to whatever messaging you want within your app. I may be wrong. The issue is that you put in that extremely awkward caveat which was "easy to port to other systems". I would not really want to have my whole source code having a line like #include <jack/midiport.h> to work. Even if that line is in a private, global header file it implies the code is dependent and that reduces portability. If you want maximum portability you probably need to create your own internal event messaging format and have raw MIDI, ALSA MIDI, Jack MIDI (or OSC, or Portmidi, etc) map into it using libraries. It is a bit more work but fortunately there is a reasonable amount of commonality in the external formats so your library will mostly be concerned with what is the access method to those data formats rather than the format itself. Not sure if that answers your question. You asked what was the easiest way. The easiest way is get somebody else do to it but I think your own your own here? The main thing you want to avoid is that when you pass these 'musical event' messages around your application that you are relying on a format from somebody else' library since if you try and port that over to another system you will have a dependency on what might be a non-native interface on that other system. If you are going to support lots of different interfaces then you get into some really enjoyable special cases. For example, when MIDI is not delivered into the RT audio thread you need a ringbuffer to send at least some of the messages to that thread. Conversely when you use Jack you have to decide which messages are not really for the RT thread and throw them the other way on another such ringbuffer. When you talk about having multiple MIDI interfaces you will be directly affect by these issues at the same time. Hm, there might not actually be an answer to this question since you put in that damn caveat - you don't actually seem to want a Jack application. Have fun. Or, if you can, get somebody else to have that 'fun' for you. Kind regards, nick. "we have to make sure the old choice [Windows] doesn't disappear”. Jim Wong, president of IT products, Acer Date: Wed, 28 Dec 2011 10:46:29 -0800 From: iainduncanlists(a)gmail.com To: linux-audio-dev(a)lists.linuxaudio.org Subject: [LAD] handling midi input in a jack app? Hey folks, what is the easiest way to deal with midi input in a jack app? I'm confused by the difference in jack midi and alsa midi, because I have two midi inputs, one is a usb input, so it appears at a low level as an alsa device, but the other is the midi input on a firewire unit, and it appears as a jack midi device. I'd like to make sure that whatever I do is easy to port to other systems. Does it make sense to use portmidi or rtmidi to get input or should I stick to the jack api entirely? thanksIain _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev

On Wed, Dec 28, 2011 at 12:04 PM, David Robillard &lt;d(a)drobilla.net&gt; wrote: 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