[LAD] making sense of Jack MIDI; or, is this an appropriate use for Jack?

Paul Davis paul at linuxaudiosystems.com
Fri Feb 15 20:22:20 UTC 2013


On Fri, Feb 15, 2013 at 3:19 PM, M Donalies <ingeniousnebbish at cox.net>wrote:

>
> [insert rant: If html email is for children, shouldn't serious
> documentation
> refrain from flash, javascript,


although flash is on its way out (thanks largely to apple, but also html5 +
<canvas>), javascript is at the core of a lot serious website
functionality. it actually makes a number of web-centric user experiences
much more pleasant.


> and other gimmicks? Why is it that I can find
> entire books on programming the linux kernel, but so little about either
> Alsa
> or Jack?]
>

follow the money ... who do you propose would write such documentation?
why?

the JACK API is fully documented. tutorials on basic use of the audio API
exist. the big difference here is that there are several example blobs of
source, ranging from the explicitly "example" clients within the JACK
source code package itself, to the utility clients, and onward up to full
scale MIDI sequencers such as ardour.

But they also use Jack for audio. This is my frustration. If I want to
> support
> both audio and midi, then I have to learn 2 completely different and
> conflicting
> api's.


which is, of course, another reason why JACK MIDI exists.


> Perhaps this should go in the "what sucks about linux audio" thread.
> What I could do 15+ years ago under Window still mystifies me in how to do
> it
> under linux. (And, no, I'm not a shill for MS. I use linux for everything
> other than audio, and I really, really want it for audio as well.)
>

look, the ALSA sequencer emerged at a time (1998 or so) when it was sort-of
correctly believed that you couldn't do "realtime-y" stuff from user space
on linux.

although the functionality it offers is incredibly useful for quite a few
purposes, the basic design assumption that this sort of thing must be done
by handing data to the kernel and allowing it to be scheduled there is just
wrong (or at best, unnecessary).

nobody has ever stepped up to write a library based on JACK MIDI that would
do "MIDI sequencing" in the sense of your "deliver this event at time T
where T is arbitrary". nothing is stopping anyone from doing that.

but ... i would point out that if you look carefully at the insides of the
linux based sequencers you mentioned, you will find that they do not
actually use this functionality of the ALSA sequencer either. they ask for
"immediate" delivery and use their own sequencing mechanisms to get the
timing right (mostly).

the only effort i have seen in the open source world to implement a general
purpose MIDI sequencing library that did "future" sequencing was something
called (something like) TME3. it was a complete failure in terms of getting
other apps to use it.


>
> [insert rambling conspiracy or other rant of your choice here]
>
> If Jack is used for audio, then shouldn't there be a kind-of
> general-purpose
> Jack midi sequencer? (... and the crowd muttered, "Idiot. You have no idea
> what you're talking about.")
>

"shouldn't there be a kind of general purpose JACK audio sequencer" makes
about as much sense ...

what could make quite a bit of sense would be a utility JACK client that
played an SMF file via JACK MIDI. this would be *relatively* simple to do
(once you figure out what godawful lump of code you plan to use to parse
SMF) and would be quite instructional for future questions such as yours.

however, this tool does not exist at this time.

--p
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20130215/6216f3ac/attachment.html>


More information about the Linux-audio-dev mailing list