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